Parallel Networks, LLC v. Abercrombie & Fitch Co.

*962 BRYSON, Circuit Judge. I Plaintiff Parallel Networks, LLC, is the owner of U.S. Patent No. 6,446,111 (“the '111 patent”), entitled “Method and Apparatus for Client-Server Communication Using a Limited Capability Client Over a Low-Speed Communications Link.” The application for the patent was filed in 1999. As the title suggests, it was addressed to perceived problems in using generic software applications on what the patent referred to as “handheld and credit-card-sized” computers, which often operated over low-speed or wireless networks. According to the patent, there were two problems with using generic applications in that environment: (1) they occupied a considerable amount of storage space on the host computer (because they had to include capabilities for adapting to many different settings) and (2) they required multiple, data-intensive transfers of information between the server and the computer (because they were not designed with the limitations of low-speed networks in mind). See '111 patent, cols. 1-2. The patent’s solution to those problems was what it referred to as a “dynamically generated, transient applet.” 'Ill patent, col. 1, 11. 9-10. An applet is a small program that typically performs one specific task. Examples include standalone programs, such as Microsoft Paint, or web-based programs that operate within an Internet browser and change the graphic content of a website in response to user input. For instance, a single applet could perform the limited function of responding to a web user’s request to a website featuring clothing by displaying an image of a medium-size red shirt. Applets and a related technology, known as plug-ins, predated the '111 patent, and both could be used to provide “dynamic” capabilities to web pages. Id., cols. 5-6. The '111 patent claimed a new type of applet that is better suited to the needs of “limited capability clients.” See, e.g., id., col. 7,11. 63-65 (prior art applets, once transferred, “typically must go back out over the wireless network two or more times”). Figures 2 and 3 illustrate the function described in the patent: *963 [[Image here]] *964 [[Image here]] As those figures show, the patent teaches an applet that couples particularized data with a data manipulation system that “enables the applet 26 to handle the various characteristics associated with the data included in the applet....” 'Ill patent, col. 11, 11. 18-19; see also Fig. 2 (displaying the data manipulation system and the data as the two parts of the applet). The applet is generated in response to a request representing the user’s desires (e.g., the display of a shirt in medium size and red color). “By combining the functionality in the data manipulation system 30 with the data of the data storage system 32 the design methodology behind the applet 26 can be shifted from the traditional focus on writing a generic program one time and using that program with a variety of different data types, to writing a program specifically for particular data.” Id., col. 11, 11. 56-61. That individualized feature, according to the patent, reduces the size of the applet and reduces the number of times the client computer needs to communicate with the server. E.g., id., col. 11, line 64, through col. 12, line 5. The patent also makes clear that the claimed applet must work prior to its initial transmission from the server to the client. See, e.g., 'Ill patent, col. 17,11. 64-65 (applet must be “operable to be transferred over the communications link to the client device”); id., col. 2, 11. 45-46 (same, described in the Summary of the Invention). For that reason, the patent describes an “executable applet” that is “generated” before it is transmitted to the client. E.g., id., col. 17, line 54; Fig. 3. Generating the applet, in turn, requires that both the particularized data and the data manipulation system reside in the transmitted applet. E.g., id., col. 3,11. 13- *965 15 (noting that “the appropriate data and associated data handling capabilities” are transmitted “as a group”); col. 12,11. 8-10 (“the needed functionality and the required data are bundled together in the applet”); col. 17, 11. 54-65 (describing two “constituent” systems in the “executable” or “operable” applet). Thus, while some embodiments of the claimed applet may call for a subset of data to be “updatable” through subsequent communications with the server, e.g., id., Fig. 3; col. 15, 11. 47-49, the applet must be operable before it is transmitted, e.g., col. 16,11. 20-31 (describing an example in which the client “executes the applet” before “indicating] that the applet 26 requires new or updated data which may require updating the updateable elements”). In March 2010, Parallel filed the first of four cases against 120 different defendants in the United States District Court for the Eastern District of Texas. The defendants span a variety of industries but have in common that their websites provide applets in response to user requests in a manner that, according to Parallel, infringes the '111 patent. Responding to the number of defendants and to Parallel’s stated strategy of trying to extract an early settlement from as many defendants as possible, the district court implemented a creative procedure designed to streamline the ease. The court ordered an initial Markman hearing to construe three terms in two claims that defendants had contended “affect all Defendants [and], if construed, would be case dispositive.” The court ordered accompanying summary judgment briefing on the same claims. The three chosen terms, which the parties agree are substantively identical in independent claims 1 and 17, are underlined in the text of claim 1, below: 1. A data processing system comprising: a server coupled to a communications link and operable to receive a request from a client device and to collect a plurality of data items, wherein the data items comprise specific information collected as a function of the request; an executable applet [that is] dynamically generated by the server in response to the request, a constituent system associated with the applet comprising a subset of the data items, each data item in the subset used as at leas[t] one pre-loaded value in the applet; a further constituent system associated with the applet comprising a data interface capability configured to provide a plurality of operations on the pre-loaded values, the operations comprising operations associated with the subset of the data items; and the applet operable to be transferred over the communications link to the client device. 'Ill patent, col. 17,11. 47-65. The district court retained a technical adviser and, following a hearing and briefing, construed each of the three terms. First, it held that “executable applet” means a “program code that can be used by a client device.” The court rejected the defendants’ argument that the term should be construed to mean “a small, substantially self-sufficient application, containing the requisite functionality and the necessary data to operate, that depends on substantially no services (e.g., web browser or plug-in) on a client device.” That construction, the court found, was “based on an underlying and erroneous premise that claims 1 and 17 are limited to web browsing.” The court also modified Parallel’s proposed construction of the term “executable applet”—i.e., “program code that interacts locally with a client and can be *966 discarded”—because the discarding term concerned “a limitation from the preferred embodiment that is not required by the claims” and because “the user and the client are not necessarily synonymous.” The court adopted the defendants’ construction of the second term, holding that an applet that is “dynamically generated by the server in response to the request” is one “constructed at the server, by combining the requisite functionality with the necessary data, at the time of and in response to the client request.” The court described that construction as consistent with the prosecution history, in which the patentee distinguished prior art based on the fact that the applet in the patented system was generated in response to the client’s request. The court also found support in the specification’s repeated assertions that “the data and functionality are sent together to the client to reduce the number of transmissions.” The court rejected Parallel’s contention that the term means “generated by the server to have particular services and data for the client based on the request.” That construction, the court explained, “read[s] out the limitation ‘in response to the data request’ [because, for] the applet to be generated in response to the request, the request must come first and the applet cannot predate [it].” Finally, the court adopted Parallel’s definition of “data interface capability” to mean “program code that allows the client to access and use the data,” finding that Parallel’s construction was “consistent with the specification as a whole.” The court found that the defendants’ proposal was based on the same “erroneous assumption that the claims are limited to a web-based environment.” Moving to the merits of Parallel’s infringement claim, the district court granted summary judgment of non-infringement for most defendants based on its construction of the “dynamically generated” term. In each of the accused instrumentalities, the district court found, “at least one of the functional code or necessary data is contained ... as only a link.” Rejecting Parallel’s argument that “an applet can be constructed with the functionality and data sent as separate files to be assembled and executed on the client device,” the court held that the applet, “as transferred,” “requires [that] both the data and functional code exist as operative components of the applet.” Because Parallel claimed only literal infringement, and because the accused sites all included a link that necessitated a subsequent transmission between the client and the server in order to assemble the data and functionality required for the applet to operate, the court ruled that most of the defendants were entitled to summary judgment. The following month, Parallel filed a motion pursuant to Federal Rule of Civil Procedure 59(e) seeking leave to amend its infringement contentions in order to allege infringement against 45 defendants based on the district court’s claim constructions. Parallel principally argued that the court had imposed a “single transmission” requirement on the invention and that the court’s construction was an unexpected and intervening change in the law to which Parallel deserved a chance to respond. The court denied the motion, ruling that it never imposed a “single transmission” requirement in its claim construction and that, in any event, Parallel had had ample opportunity to respond, and had in fact responded, to the court’s construction of the “dynamically generated” term. For that reason, the court held that there was no basis for granting Parallel another bite at the apple. The district court then severed the defendants for which the summary judgment *967 had disposed of all of Parallel’s claims. The court dismissed those defendants’ counterclaims without prejudice and entered final judgment in favor of those defendants. Parallel now appeals the district court’s claim constructions, its non-infringement rulings, and its denial of the Rule 59(e) motion, with respect to the severed defendants. II A Despite the many issues raised on appeal, this case reduces, as the district court ruled, to a fairly simple analysis. First, as to claim construction, we agree with the district court that the data manipulation service (or functionality) and the particularized data are both necessary components of the applet as it is initially generated and before it is transferred to the client. Asserted claim 1 describes an “executable applet” that is both “dynamically generated by the server in response to the request” and “operable to be transferred over the communications link to the client device.” See '111 patent, col. 17,11. 54-65. The claim further describes the applet’s two “constituent” systems as the data and the functionality. Id. In other words, the claim teaches that the applet is “generated” in response to a user request, is “executable” and “operable,” is “associated with” the two “constituent” systems of particularized data and functionality, and is thereafter “to be transferred.” Such a reading comports with the ordinary meaning of the patent’s key terms. In order of appearance, the word “executable” means “capable of being executed,” i.e., being “put into effect [and] carried] out fully and completely.” Webster’s Third New International Dictionary 794 (1968). 1 The word “generate” similarly denotes completion, i.e., “to cause to be: bring into existence.” Id. at 945. And the word “constituent” means “serving to form, compose, or make up ...: component.” Id. at 486. Taken together, these terms describe a natural progression in the asserted claims: Upon receipt of a user request, the server generates (i.e., brings into existence) an applet with two constituent (i.e., component) parts (particularized data and functionality); that applet is executable (i.e., capable of being executed and carried out fully and completely). The applet is then transferred to the client device, where it will be executed. Figure 3 depicts this chronology. What Figure 3 does not describe, however, is a scenario in which, in response to a request, only part of the applet is generated (with a placeholder for the rest) and is transmitted to the client, which then tries to execute it and, finding it non-executable and inoperable, follows a link back over the network to retrieve the additional data and/or functionality that is needed for the applet to run. The specification substantiates this construction. The Summary of the Invention reiterates the claim language describing “constituent” systems of the “executable,” “operable” applet. 'Ill patent, col. 2, 11. 33-49. Then, even more explicitly, it explains that, in the “present invention,” “the appropriate data and associated data handling capabilities” are transmitted “as a group.” Id., col. 2, line 55, through col. 3, line 15; see also id., col. 12, 11. 8-10 (“the needed functionality and the required data are bundled together in the applet”). The specification also makes clear that the patent’s executable applet, as generated, con *968 tains data and functionality: “According to the teachings of the present invention, when the applet 26 is generated, the applet 26 does not merely contain an executable program as with typical applets. In contrast, the applet 26 also comprises particular services and data for the client 12 based on the request.” Id., col. 9, 11. 39-43. Indeed, combining the data and functionality at the outset and transmitting them “as a group” facilitates the invention’s key goal of “greatly reducing]” the number of communications over low-speed networks. Id., col. 3,11.13-17. A finding of non-infringement follows directly from this analysis. Parallel concedes that, for each of the accused websites, “[i]t is undisputed that the client device must receive both the associated functional code and data to execute the applet.” And Parallel also concedes that each of the accused instrumentalities is missing at least one portion of the functional code or data when the applet is transferred to the client because the applet includes only a link. Those admissions doom Parallel’s claims because we construe the asserted claims of the '111 patent to require that the applet be executable or operable when it is generated and before it is first transmitted to the client, which means it must include both the particularized data and the functionality. Because the accused websites do not contain every claim limitation, they do not literally infringe. B Parallel’s challenges to the district court’s claim construction ruling and, in particular, to its finding that the term “dynamically generated” means “constructed at the server, by combining the requisite functionality with the necessary data, at the time of and in response to the client request,” are unpersuasive. Parallel’s central complaint is that the district court erred in construing “generated by the server” to mean “constructed at the server, by combining” because (1) “generate” is broader than “combine” and (2) the asserted claims require only that the data and the functionality be “ ‘associated with’ the applet, not ‘combinfed]’ into a single file with the applet.” We disagree. If Parallel’s position were adopted, it would permit the broad term “associated with” to effectively rewrite the patent. Notwithstanding the potential breadth of the phrase “associated with,” it is clear that the patent teaches an applet containing both the data and the functionality when the applet is generated. In addition to reciting that data and functionality are “associated with” the applet, the claims characterize the applets as consisting of two “constituent systems,” comprising data and functionality. As explained above, the term “constituent” means “serving to form, compose, or make up.” The specification similarly refers to the applet as “comprising] particular services and data.” 'Ill patent, col. 9,11. 39-43. Moreover, the specification confirms that the meaning Parallel urges for the term “associated with” is overly expansive. Parallel’s position would, for instance, improperly bring distinguished prior art within the scope of the claims, because Java applets or plug-ins can easily be described as “associated with” data and functionality. See, e.g., 'Ill patent, col. 7, line 63, through col. 8, line 8. And, as the defendants point out, an applet that need not include the two constituent systems could “be empty and not even include the embodiments described in the specification.” Nor are we persuaded by Parallel’s effort to contrast the use of “associated with” in asserted claims 1 and 17 with other parts of the patent that refer to the data and functionality as “portion[s]” of *969 the applet. Parallel focuses, for example, on the following passage describing Figure 2: “[B]ecause of the unique construction of the applet, the applet 26 comprises both a data manipulation system 30 and a data storage system 32 which are each constituent systems associated with the applet 26. The data manipulation system 30 may also comprise a portion of the applet 26, similarly, the data storage system 32 may also comprise a portion of the applet 26.” 'Ill patent, col. 11,11. 8-15. We agree with the district court that, if anything, this characterization of the applet as “compris[ing] both” data and functionality supports the defendants, particularly in the context of Figure 2’s depiction of an applet containing both systems. In short, the district court’s construction properly accounts for the meaning of “associated with” in the context of the '111 patent. 2 Parallel’s remaining arguments all take issue with narrow aspects of the district court’s construction that do not bear on the dispositive claim construction provided above. First, Parallel claims that construing the term “generated by the server” to mean “generated at the server” was wrong because the specification states that the applet “ ‘may be generated either directly by the web server application 20 or by an external program utilized by the web server application.’ ” Parallel’s basic point is a fair one—“by” does not necessarily mean “at.” But Parallel does not say where the applet is generated if it is not at the server and thus points to nothing to indicate why the difference between the two prepositions matters in this context. In any event, the critical point for purposes of this case is that the applet cannot be finalized at the client, whether by an “external program,” a “web server application,” or some other mechanism. Parallel next attacks the district court’s ruling that “dynamically ... in response to the request” means “at the time of and in response to the request.” Parallel notes that the specification defines “ ‘dynamic’ information” to be information that “may be different for different clients and different users of clients,” with no temporal element. See '111 patent, col. 5, 11. 1-3. While that may be true, it does not change the analysis in any way. Although an applet could, for example, be generated “in response to” a request even if it were generated at some later point rather than at the exact time of the request, that does not affect the critical requirement that the applet be generated and executable before it is transferred to the client. Parallel’s argument on this issue is irrelevant to that determination. 3 Finally, Parallel argues that the district court was wrong to construe the term “dynamically generated” to require that the data and functionality be transferred to the client in a single transmission. Parallel relies on the district court’s subse *970 quent statement that its claim construction contained no “single transmission” requirement and points to numerous examples in which the specification references more than one transmission over the communications link. As the defendants explain, however, Parallel “conflate[s] two very different concepts: (1) the generation of the applet at the server and its transmission to the client; and (2) the operation of the applet after it has been fully transferred to the client.” Claims 1 and 17 deal with the former; the specification passages that Parallel cites to show that the invention anticipates multiple transfers between client and server deal only with the latter. That is why, for example, the district court found that “the data and functionality are sent together to the client to reduce the number of transmissions” but that “[t]his does not ... exclude additional communications between the server and client once the applet is in place.” C Based on its critique of the district court’s claim construction, Parallel argues that the district court’s infringement analysis was necessarily erroneous. Again, however, Parallel’s argument hinges on an impermissibly broad interpretation of the phrase “associated with” in claims 1 and 17. In order to overcome the fact that one or both of the functionality and data in the accused devices are represented by a link when the applet is first transferred from the server to the client device, Parallel asserts that it is irrelevant whether the data and functional code are actually listed within the HTML or whether they are listed by a link to a file. In other words, Parallel argues that it does not matter “whether the client device needs to make a separate ‘request’ to receive the associated data or functionality” because, in both instances, the constituent system is sufficiently “associated with” the applet. Parallel admits that the executable applet must consist of both data and functionality, and the patent emphasizes that feature repeatedly. What purportedly made the '111 patent unique and inventive was combining and transmitting the particularized data and functionality “as a group” in order to transfer an “executable applet” and reduce the number of transmissions over the communications link. Parallel cannot now claim that a limitation that featured so critically in the patent was not, in fact, a part of the invention. Indeed, the analysis of Parallel’s expert, Dr. Richard Cooper, highlights the fundamental problem with Parallel’s position. Dr. Cooper explained that, in each of the accused systems, the client device is instructed that “the combined data and the functional code are needed for the applet to execute and how to obtain that needed information.” The fact that the client needs to “obtain” information in order to execute, however, confirms that no “executable” or “operable” applet is generated and then transferred from the server to the client, as the patent requires. Dr. Cooper’s ipse dixit statements that, in his opinion, “it is irrelevant on this ‘combining’ issue whether the data and functional code are actually listed within the HTML or whether the data and functional code are listed by a link in the HTML,” are not sufficient to avoid summary judgment. See, e.g., Arthur A. Collins, Inc. v. N. Telecom Ltd., 216 F.3d 1042, 1046-48 (Fed. Cir.2000). Ill Parallel argues that the district court erred in denying its Rule 59(e) motion because the court failed to address all the pertinent factors that bear on whether a motion to alter a judgment should be granted. In an effort to portray its argu *971 ment as a purely legal one, Parallel contends that the district court never addressed one of three factors that the Fifth Circuit considers under Rule 59(e)—the need to prevent a “manifest injustice”— and failed to consider four “good cause” factors for allowing amendments to infringement contentions under Local Patent Rule 3—6(b). Parallel’s argument is unpersuasive. We agree with the district court that Parallel is seeking to amend its infringement contentions in order to make arguments that could have been made before the entry of summary judgment, a tactic that the district court correctly held to be improper. See, e.g., Templet v. HydroChem Inc., 367 F.3d 473, 478-79 (5th Cir.2004). As Parallel concedes, it “reanalyzed” the defendants’ accused instrumentalities and identified allegedly infringing activities by a subset of defendants based on the fact that a single file is transmitted in a single transmission. Because the patent makes clear that the applet must be transferred with data and functionality initially, and because the parties briefed that very issue before the district court, Parallel’s newly claimed infringement allegations do not rely on anything new that gives rise to a valid Rule 59(e) motion. In particular, the district court’s claim construction was not an intervening change in the law. Parallel chose to pursue a theory that allowed it to accuse a larger number of defendants. Having lost, Parallel may not now initiate what would amount to a completely new infringement proceeding. Nor is there any merit to Parallel’s effort to characterize the district court’s ruling as a legal error based on the court’s failure to consider all the relevant factors. The need to prevent “manifest injustice” is a catch-all factor, the court’s resolution of which is implicit in its consideration, and rejection, of Parallel’s Rule 59 motion as a whole. The district court made that point clear when it characterized Parallel’s motion as seeking to “prevent a manifest injustice” by “amending] its infringement contentions.... ” Requiring the formality of an additional sentence to that effect is unnecessary, and Parallel cites no Rule 59 cases in support of its argument. That is unsurprising, as courts frequently deny Rule 59(e) motions without discussion, and such dispositions are not treated as legally erroneous because they are summary in nature. See, e.g., Boone v. Citigroup, Inc., 416 F.3d 382, 387 n. 6 (5th Cir.2005) (“The district court also summarily denied a rule 59(e) motion to reconsider the denial of remand.”); Hinojosa v. Brown, 129 Fed. Appx. 915, 916 (5th Cir.2005) (same). For the same reasons, we reject Parallel’s contention that the court erred by failing to consider the proper factors bearing on whether there was “good cause” to amend the infringement contentions under Local Patent Rule 3-6(b). Parallel sought to amend its contentions pursuant to Local Patent Rule 3-6(a), which the district court held was “inapplicable,” again because the “claim construction was hardly unanticipated.” Nor does Local Patent Rule 3-6(b) provide Parallel any basis for relief. The factors set forth in that subsection of the rule go to the party’s explanation for its failure to make the allegations sooner and the potential prejudice resulting from what is to be excluded. Parallel has no good explanation for its failure to bring its new infringement contentions earlier and thus has brought any perceived prejudice on itself. AFFIRMED Footnotes [1] Parallel's contention on appeal that an executable applet "can be used by a client device” likewise implies that such an applet is capable of being used without further modification. [2] We also reject Parallel’s related argument that the district court’s use of "combine” rather than “generate” was error because the specification notes that the applet can be generated in "a variety of ways,” including "by combining various predefined units.” Parallel’s argument is a non-sequitur, as it does not address the fact that generating the applet requires combining data and functionality, even if the generation may use predefined units of data or templates customized based on the data. [3] Parallel is clearly wrong to maintain that an applet can predate the client request. As the district court held, an applet cannot predate the request if it is to be generated "in response to” that request. Parallel’s attempt to sidestep that problem by arguing that the applet may be generated using templates or prewritten- procedures does not change the fact that the applet itself must be generated at the time of or after the client request, even if some of its elements existed before the request was made. Figure 3 forecloses any argument to the contrary.