TARANTO, Circuit Judge.

Papst Licensing GmbH & Co. KG owns U.S. Patent Nos. 6,470,399 and 6,895,449. The written descriptions are largely the same, the '449 patent having issued on a divisional application carved out of the application that became the '399 patent. The focus of both patents is an interface device for transferring data between an input/output data device and a host computer. The current appeal involves whether certain digital-camera manufacturers infringe Papst's patents. The district court, applying and elaborating on its constructions of various claim terms, entered summary judgment of non-infringement, concluding that none of the manufacturers' accused products at issue here come within any of the asserted claims. Papst appeals five claim constructions. We agree with Papst that the district court erred in the identified respects. We therefore vacate the summary judgment of non-infringement.

BACKGROUND

The '399 and '449 patents, both entitled "Flexible Interface for Communication Between a Host and an Analog I/O Device Connected to the Interface Regardless the Type of the I/O Device," disclose a device designed to facilitate the transfer of data between a host computer and another device on which data can be placed or from which data can be acquired. '399 patent, Title and Abstract.1 The written description states that, while interface devices were known at the time of the invention, the existing devices had limitations, including that they tended to require disadvantageous sacrifices of data-transfer speed or of flexibility as to what host computers and data devices they would work with. '399 patent, col. 1, line 15, to col. 2, line 13. Thus, "standard interfaces" — those "which, with specific driver software, can be used with a variety of host systems" — "generally require very sophisticated drivers" to be downloaded onto the host computer, but such drivers "are prone to malfunction and... limit data transfer rates." Id. at col. 1, lines 22-28. On the other hand, with interface devices that "specifically match the interface very closely to individual host systems or computer systems," "high data transfer rates are possible," but such interface devices "generally cannot be used with other host systems or their use is very ineffective." Id. at col. 1, line 67, to col. 2, line 7. The fast, host-tailored interface also "must be installed inside the computer casing to achieve maximum data transfer rates," which is a problem for laptops and other space-constrained host systems. Id. at col. 2, lines 8-13.

The patents describe an interface device intended to overcome those limitations. It is common ground between the parties that, when a host computer detects that a new device has been connected to it, a normal course of action is this: the host asks the new device what type of device it is; the connected device responds; the host determines whether it already possesses drivers for (instructions for communicating with) the identified type of device; and if it does not, the host must obtain device-specific drivers (from somewhere) before it can engage in the full intended communication with the new device. In the patents at issue, when the interface device of the invention is connected to a host, it responds to the host's request for identification by stating that it is a type of device, such as a hard drive, for which the host system already has a working driver. By answering in that manner, the interface device induces the host to treat it — and, indirectly, data devices on the other side of the interface device, no matter what type of devices they are — like the device that is already familiar to the host. Thereafter, when the host communicates with the interface device to request data from or control the operation of the data device, the host uses its native device driver, and the interface device translates the communications into a form understandable by the connected data device. See id. at col. 3, line 25, to col. 5, line 32.

The interface device of the invention thus does not require that a "specially designed driver" for the interface device be loaded into a host computer — neither a "standard" one to be used for a variety of hosts nor one customized for a particular host. Id. at col. 5, line 15. Instead, it uses a host's own familiar driver, which (as for a hard drive) often will have been designed (by the computer system's manufacturer) to work fast and reliably. The result, says the written description, is to allow data transfer at high speed without needing a new set of instructions for every host — "to provide an interface device for communication between a host device and a data transmit/receive device whose use is host device-independent and which delivers a high data transfer rate." Id. col. 3, lines 25-28.

Claim 1 of the '399 patent sets forth the specifics of the claimed interface device:

Id. col. 12, line 42, to col. 13, line 13 (emphases added to highlight language of particular significance to the issues on appeal). Claim 1 of the '449 patent is similar, but it does not require the data device to be an analog device, and it requires the interface device to respond to the host that it is a storage device. '449 patent, col. 11, line 46, to col. 12, line 6. A few other differences between the claims are discussed infra.

Beginning in 2006, Papst sent letters to major digital-camera manufacturers, accusing them of infringing its patents and requesting that they enter into negotiations to license its inventions. One of the manufacturers sued Papst in the United States District Court for the District of Columbia, seeking a declaratory judgment of non-infringement. In 2008, Papst filed infringement suits against the camera manufacturers in multiple district courts across the country. A multi-district litigation panel then consolidated all cases and transferred them to the D.C. district court.

In preparation for claim construction, the district court received a "tutorial" from the parties' experts, whom the court asked to be "neutral" and who addressed the background of the technology, how the claimed inventions work, and other technical understandings, but not whether any particular term in the patent or the prior art has a particular meaning in the relevant field. J.A. 1596-97; see In re Papst Licensing GmbH & Co. KG Litig., No. 07mc-00493 (D.D.C. June 6, 2008) (order specifying scope of tutorial). The court then heard extensive argument from counsel, but it declined to admit expert testimony or to rely on an expert declaration from Papst, stating that "the intrinsic evidence — the claims, the specification, and the prosecution history — provide the full record necessary for claims construction." J.A. 1597.

The court issued its initial claim-construction order in 2009. It issued a modified claim-construction order after additional briefing. The district court then ruled on eight summary-judgment motions filed by the camera manufacturers, treating the manufacturers as two distinct groups — one group consisting of Hewlett-Packard Co. ("HP"), the other of all other accused manufacturers ("Camera Manufacturers"). As detailed in our discussion infra, the court's rulings on summary judgment clarified what it understood some of its claim constructions to mean. With respect to the accused products now at issue, the combined effect of the court's summary-judgment rulings was a determination of non-infringement by the Camera Manufacturers and HP. The court ultimately entered a final judgment of non-infringement under Federal Rule of Civil Procedure 54(b) for both HP and the Camera Manufacturers, In re Papst Licensing GmbH & Co. KG Litig., 987 F.Supp.2d 58, 62 (D.D.C.2013), having severed certain other claims, In re Papst Licensing GmbH & Co. KG Litig., 967 F.Supp.2d 63, 65 n. 2, 71 (D.D.C.2013).

Papst appeals, arguing that the court's summary-judgment orders should be reversed because they rely on incorrect constructions of five different terms from the '399 and '449 patents. We have jurisdiction under 28 U.S.C. § 1295(a)(1).

DISCUSSION

We review the grant of summary judgment of non-infringement de novo, applying the same standard used by the district court. See Bender v. Dudas, 490 F.3d 1361, 1366 (Fed.Cir.2007). The infringement inquiry, which asks if an accused device contains every claim limitation or its equivalent, Warner-Jenkinson Co. v. Hilton Davis Chem. Co., 520 U.S. 17, 29, 117 S.Ct. 1040, 137 L.Ed.2d 146 (1997), depends on the proper construction of the claims. See Cybor Corp. v. FAS Techs., Inc., 138 F.3d 1448, 1454 (Fed.Cir. 1998) (en banc). In this case, we review the district court's claim constructions de novo, because intrinsic evidence fully determines the proper constructions. See Teva Pharm. U.S.A., Inc. v. Sandoz, Inc., ___ U.S. ___, 135 S.Ct. 831, 840-42, ___ L.Ed.2d ___ (2015). As we have noted, the district court relied only on the intrinsic record, not on any testimony about skilled artisans' understandings of claim terms in the relevant field, and neither party challenges that approach.

Two clarifications simplify our analysis so that it is enough for us to address the correctness of the district court's constructions. First, the parties have not presented developed arguments other than arguments about the choice, on each issue, between the district court's construction and the alternative construction by Papst that the district court rejected. Specifically, for none of the issues have the parties identified a third possibility and both elaborated an argument for such a possibility and explained the importance to the case of considering it. Second, it is appropriate, if we reject all five of the challenged constructions, to vacate the summary-judgment orders and remand.2

We reject the five constructions at issue. We do so following our familiar approach to claim construction. "We generally give words of a claim their ordinary meaning in the context of the claim and the whole patent document; the specification particularly, but also the prosecution history, informs the determination of claim meaning in context, including by resolving ambiguities; and even if the meaning is plain on the face of the claim language, the patentee can, by acting with sufficient clarity, disclaim such a plain meaning or prescribe a special definition." World Class Tech. Corp. v. Ormco Corp., 769 F.3d 1120, 1123 (Fed.Cir.2014); see Phillips v. AWH Corp., 415 F.3d 1303, 1312-17 (Fed.Cir. 2005) (en banc); Thorner v. Sony Computer Entm't Am. LLC, 669 F.3d 1362, 1365 (Fed.Cir.2012). We apply, in particular, the principle that "[t]he construction that stays true to the claim language and most naturally aligns with the patent's description of the invention will be, in the end, the correct construction." Renishaw PLC v. Marposs Societa' per Azioni, 158 F.3d 1243, 1250 (Fed.Cir.1998), adopted by Phillips, 415 F.3d at 1316.

On remand, this case will proceed in light of our claim-construction reversals. For that reason, it is worth reiterating that a district court may (and sometimes must) revisit, alter, or supplement its claim constructions (subject to controlling appellate mandates) to the extent necessary to ensure that final constructions serve their purpose of genuinely clarifying the scope of claims for the finder of fact. See O2 Micro Int'l Ltd. v. Beyond Innovation Tech. Co., 521 F.3d 1351, 1359 (Fed.Cir. 2008); Pfizer, Inc. v. Teva Pharm., USA, Inc., 429 F.3d 1364, 1377 (Fed.Cir.2005). That determination is to be made as the case moves forward.

A

Papst first challenges the district court's "memory card" summary judgment as relying on an improper construction of the term "interface device" found in the preamble of claims in both patents. The district court construed the term as limiting the claims' coverage to "stand-alone device[s]." In re Papst Licensing GmbH & Co. KG Litig., 670 F.Supp.2d 16, 31-35 (D.D.C.2009) ("Claim Constr. Op."). In particular, the court held that "the data transmit/receive device must be a separate device from the" claimed "interface device." Id. at 33. Subsequently, in granting summary judgment, the court explained that what it meant by this requirement is that the interface device may not be "a permanent part of either the data transmit/receive device or the host device/computer," by which it meant that it may not be located permanently inside the housing of either of those two devices. In re Papst Licensing GmbH & Co. KG Litig., 932 F.Supp.2d 14, 18, 21-22 (D.D.C.2013).

1

As a threshold matter, the Camera Manufacturers argue that we should not reach this issue because the district court's summary-judgment rulings do not depend on the construction of "interface device." They invoke principles stated in SanDisk Corp. v. Kingston Technology Co., 695 F.3d 1348, 1354 (Fed.Cir.2012) ("[W]here, as here, a party's claim construction arguments do not affect the final judgment entered by the court, they are not reviewable."), and Mangosoft, Inc. v. Oracle Corp., 525 F.3d 1327, 1330 (Fed.Cir.2008) ("we review judgments, not opinions"). We conclude, however, that the premise for invoking the cited principles is missing here.

The district court's summary-judgment order regarding memory-card devices shows that its final judgment did turn on the construction of "interface device." The primary reason the court gave for rejecting Papst's infringement contentions was that "[t]he Court made clear in its claims construction opinion that the interface device is separate and distinct from the data transmit/receive device." Papst, 932 F.Supp.2d at 21. The court cited repeatedly to the portion of its claim-construction opinion addressing "interface device." E.g., id. at 18 (citing Claim Constr. Op. at 32-35); id. at 21 (citing Claim Constr. Op. at 34-35); id. at 23 (citing Claim Constr. Op. at 31-35). And in its opening paragraphs, the court summarized the Camera Manufacturers' position on summary judgment as relying on that same construction. Id. at 16 ("Because the invented `interface device' is a stand-alone device that is separate and apart from any data transmit/receive device, the Camera Manufacturers contend that a memory card cannot be both part of the interface device and a data transmit/receive device...."). In these circumstances, we will consider whether the district court's construction is correct.

2

We hold that the term "interface device" is not limited to a "stand-alone device" in the district court's sense relied on for summary judgment: a device that is physically separate and apart from, and not permanently attached to, a data device (or a host computer). Representative claim 1 of the '449 patent begins, "[a]n interface device... comprising the following features," and then recites the necessary components of the claimed interface device. See supra pp. 1259-60. Neither the claim language nor the rest of the intrinsic record supports the district court's exclusion of a device that performs the required interface functions and is installed permanently inside the housing of a particular data device.

The district court did not suggest that the term "interface device" by itself implied its construction. Rather, it heavily relied for its construction on the specific claim requirement that (to paraphrase) a part of the interface, upon receiving an identification query from the host computer, send a signal identifying itself as a host-familiar device "regardless of the type of the data transmit/receive device attached to the second connecting device of the interface device." '449 Patent, col. 11, lines 63-65. The court concluded that the "regardless" phrasing in the claim "strongly indicates that various kinds of data transmit/receive devices could be attached" to the interface device. Claim Constr. Op. at 32-33.

But the court's construction does not follow from its understanding of the "regardless" phrase. Nothing about that phrase forbids any single instance of the claimed interface device to be permanently attached to a particular data device. It readily allows permanent attachment of each copy of the interface device to a particular data device, prescribing only that the same host-responsive identification signal be sent regardless of what type of data device the interface device is attached to. That is, there can be multiple copies of the same interface device, with each permanently attached to one of a variety of different data devices. The claim language, in short, does not limit "interface device" to a device not permanently attached to (readily detachable from) a data device.

The written description does not do so either. Critically, the district court's construction, like the Camera Manufacturers' arguments supporting it, fundamentally mistakes what the description makes clear is the stated advance over the prior art. As explained supra, the described advance over the prior art was the elimination of the need for special drivers to be placed on the host computer by instead having the host computer use a single, already-present, fast, reliable driver to communicate with the interface and, through it, with the data device, which need not be of a particular type. Nothing about that advance suggests exclusion of a permanent attachment of such an interface to the data device — a construction that is "unmoored from, rather than aligned with" what is described as the invention's advance. World Class Tech., 769 F.3d at 1124.

No passage in the written description says otherwise. The Camera Manufacturers cite passages that describe the invention as "sufficiently flexible to permit attachment of very different electrical or electronic systems to a host device." '399 patent, col. 1, lines 56-59; id., col. 7, lines 45-49 (touting the "present invention" as allowing "an interface between a host device and almost any data transmit/receive device"). But that language does not speak to the connection between the interface and data devices. Rather, it addresses the connection between the host computer and data devices, a connection facilitated by the interface device. Even as to that, the passage may be read merely to assert the capability of one-to-one host-to-data-device connections, with the data device chosen from a wide variety of possible data devices. But even if it is read to assert a capability of one-to-many host-to-data-device connections, it says nothing to assert that a given copy of the interface device must be attachable to different data devices either simultaneously or seriatim.

The Camera Manufacturers also point to the written description's statement that "[i]n the interface device according to the present invention an enormous advantage is to be gained ... in separating the actual hardware required to attach the interface device to the data transmit/receive device from the communication unit," '399 patent, col. 8, lines 23-28 (figure numbers removed) — which they say means that permitting multiple data devices to attach to a single interface device is an integral part of the invention. But that passage does not support the district court's limiting construction, and not only because it is part of the description of several preferred embodiments, rather than a clear declaration of what constitutes an essential part of the invention.

The full passage makes clear that the "hardware separation" is not between the interface and data device, but within the interface device itself — between the second connecting device, on one hand, and "the digital signal processor, the memory means[,] and the first connecting device," on the other. Id., col. 8, lines 28-29 (figure numbers removed). When the passage states that this separation "allows a plurality of dissimilar device types to be operated in parallel in identical manner," it immediately adds: "Accordingly, many interface devices can be connected to a host device which then sees many different `virtual' hard disks." Id. col. 8, lines 30-33 (emphasis added). The suggestion is that distinct interface devices are used for distinct data devices, each interface device incorporating a "second connecting device" that works for its particular data device. This suggestion works against, rather than supports, the Camera Manufacturers' view of multiple data devices attached to a single (separate) interface device, whether at once or in sequence, for it readily accommodates a one-to-one permanent attachment of an interface device to a data device. And the parallel operation of dissimilar device types is possible because the invention causes the host computer to use its native software to transfer data at high speed and because the invention creates a uniform interface from the host's perspective for controlling the data device. See, e.g., '399 patent, col. 7, lines 45-49.

Finally, nothing in the prosecution history supports the district court's narrow construction. The Camera Manufacturers point to an amendment that changed the claim language from "the type of a device attached" to "a type of device attached" in what became claim 1 of the '399 patent. J.A. 391. But there was no accompanying explanation of the change, which, on its face, does nothing more than the "regardless" language of claim 1 does, and that language, as we have explained, does not forbid permanent attachment. The Camera Manufacturers also note that the applicant stated that "it is clear that the data transmit/receive device to be connected to the second connecting device of the subject interface provides analog data." J.A. 389 (emphasis added). Nothing in that statement precludes the connection from being permanent once made.

B

Papst also appeals the district court's construction of the phrase "second connecting device," which appears in both patents.3 The district court construed the term as "a physical plug or socket for permitting a user readily to attach and detach the interface device with a plurality of dissimilar data transmit/receive devices." Claim Constr. Op. at 43. The parties' arguments over the proper construction of "second connecting device" largely mirror the arguments over whether the interface device must be readily detachable from the data device. See Camera Manufacturers' Br. 68 ("As explained above, the claim language requires the interface device to be connectable to many different types of [data devices]."); HP's Br. 3 ("Core to the invention is the ability to attach the interface device to different or multiple data transmit/receive devices."). The district court likewise tied its construction of "second connecting device" to its understanding that the interface device must be a stand-alone one readily attachable to and detachable from multiple data devices. See Claim Constr. Op. at 42, 44.

We conclude that the district court's construction of "second connecting device" is incorrect largely for reasons we have given for rejecting the "interface device" construction. The district court did not conclude, and the Camera Manufacturers and HP have not meaningfully argued, that the ordinary meaning of "second connecting device" (or "connecting device") requires a physical plug, socket, or other structure that permits a user to readily attach and detach something else. The principal basis for the district court's inclusion of those requirements was the basis we have already rejected — the view that other claim language and the written description require the interface device (of which the second connecting device is a part, according to the claims) to be stand-alone. For "second connecting device," the district court added that a preferred embodiment from the written description includes pin connectors and other socket-like structures. See Claim Constr. Op. at 42-44. But we see nothing to take that embodiment outside the reach of the usual rule that claims are generally not limited to features found in what the written description presents as mere embodiments, where the claim language is plainly broader. Phillips, 415 F.3d at 1323.

C

The district court's construction of the phrase "data transmit/receive device" is challenged here as well. The district court construed the phrase to mean "a device that is capable of either (a) transmitting data to or (b) transmitting data to and receiving data from the host device when connected to the host device by the interface device." Claim Constr. Op. at 39 (emphasis added). The parties' dispute focuses on the "when connected" portion of the court's construction, which the district court understood to require that the data device be capable of transmitting data while connected to the host, that is, able to begin transmitting after the interface device is connected to the host device. In re Papst Licensing GmbH & Co. KG Litig., 967 F.Supp.2d 1, 6-7 (D.D.C.2013). We reject that portion of the court's construction.

1

The Camera Manufacturers initially argue that Papst may not challenge the district court's construction because "the district court adopted word-for-word the construction of [data transmit/receive device] that Papst proposed." Camera Manufacturers' Br. 47. That is an unreasonable characterization of what occurred in the district court. The Camera Manufacturers, not Papst, proposed the bulk of the court's construction, including the "when connected" language. Claim Constr. Op. at 37. Papst proposed a construction without the "when connected" language, opposing inclusion of that language. Claim Constr. Op. at 37 (noting "Papst objects to any construction" but argues in the alternative "that the term may be construed `for context' as `a device that receives input and provides data to the interface device'" (citation omitted)). When the district court adopted the Camera Manufacturers' "when connected" language, Papst noticed that the adopted construction, in a respect distinct from the "when connected" dispute, rested on a misunderstanding of a patent figure, and it filed a motion identifying the alleged error and asking the court to modify the adopted construction in the one respect needed to correct it. Papst limited its motion to that point, leaving the other, already-contested aspects of the claim construction untouched. The district court agreed with Papst and fixed the construction as urged. Claim Constr. Op. at 39.

The Camera Manufacturers argue that Papst, having unsuccessfully opposed a construction with the "when connected" language, lost its ability to challenge the adoption of the "when connected" language by not re-raising the issue when seeking a modification based on a newly identified issue. See Oral Argument at 33:44-34:10 (arguing that Papst forfeited its challenge because it requested a modification without "reserv[ing] the ability to go back later to ask for [its] old construction"). This contention is wholly without merit. In the district court, Papst opposed the construction it now opposes, and it was not required to state its opposition twice. Papst could not have given the district court the impression that it suddenly supported the construction when, in seeking a modification, it limited its request to a manifest error resting on a plain misapprehension of the record, rather than rehashing the broader arguments on claim construction that the court had fully considered. Papst's limited approach in seeking a modification was, indeed, commendably consistent with the general anti-repetition principle governing requests for reconsideration. See Isse v. Am. Univ., 544 F.Supp.2d 25, 29-30 (D.D.C.2008) ("`[W]here litigants have once battled for the court's decision, they should neither be required, nor without good reason permitted, to battle for it again.'" (citation omitted)).

2

We conclude that the data transmit/receive device recited in the preamble to the claims of the '399 and '449 patents need not be capable of communicating "when connected to the host device by the interface device." (The parties do not dispute that this language, though appearing in the preamble, is a claim limitation. We proceed on the assumption that it is.) Nothing about the ordinary meaning of "data transmit/receive device" suggests any temporal constraint on the transferring of data. As the words imply, a data transmit/receive device is a device that may transmit or receive data; those words offer no information about when data is transferred.

To the extent that some claim language does suggest a temporal constraint, the focus is always on communications between the interface device and the host computer, not between the data device and the host computer. For example, the interface device must send a signal to the host device "when receiving an inquiry from the host device as to a type of a device attached." '399 patent, col. 12, line 65, to col. 13, line 3. After the interface device signals to the host device, the interface device must be able to receive communications from the host device. Id. col. 13, lines 5-8 ("whereupon the host device communicates with the interface device"). But the claims of both patents are silent as to when the interface device must communicate with the data device. If anything, claim 1 of the '399 patent tends to suggest that data can already have been transferred to the interface device from the data device before it is requested by the host computer: claim 1 says that the interface device must "interpret a data request command from the host device ... as a data transfer command for initiating a transfer of the digital data to the host device." Id. col. 13, lines 10-13 (emphasis added). Because claim 1 is limited to interface devices that receive analog data from a data device and then convert it to digital data, the quoted language seems to contemplate that the initiated transfer is of pre-converted digital data stored on the interface device. Regardless, the claim language nowhere requires the interface device to be capable of receiving data that moves from the data device after connecting to the host.

The Camera Manufacturers offer no persuasive argument for why the claim language or any other part of the specification or prosecution history requires that a data device be able to communicate with the host "when connected to the host device by the interface device." At most they assert, without significant elaboration, that the "specification nowhere discloses indefinite storage by the interface device of data from a [data device]." Camera Manufacturers' Br. 51. This assertion does not suggest a disclaimer of any sort; it merely asserts an absence of something in the written description. But that absence must be judged in light of what is plainly present in the written description — a disclosure of memory that is part of the interface device. '399 patent, col. 5, line 52, and Figure 1. And we have been given no reason at all to infer, from the absence of more express statements regarding use of the disclosed memory in the interface device for temporary storage of data from the data device, that the claim should be read to include a textually unsupported "when connected" requirement regarding transfer of data to or from the data device.

The district court, when construing the data-device claim language, focused almost exclusively on whether the data device must be capable of both sending and receiving data. It did not lay out good reasons for adopting the "when connected" requirement as part of its construction. Claim Constr. Op. at 37-39; In re Papst Licensing GmbH & Co. KG Litig., 624 F.Supp.2d 54, 75-77 (D.D.C.2009). Finding no basis for that requirement, we conclude that the court erred by including that phrase in its construction.

D

The next issue we discuss is the district court's construction of the phrase "virtual files" in the '399 patent and the phrase "simulating a virtual file system" in the '449 patent.4 The district court construed "virtual files" as "files that appear to be but are not physically stored; rather, they are constructed or derived from existing data when their contents are requested by an application program so that they appear to exist as files from the point of view of the host device." Claim Constr. Op. at 60. The court construed "simulating a virtual file system" almost identically as "appearing to be a system of files, including a directory structure, that is not physically stored; rather, it is constructed or derived from existing data when its contents are requested by an application program so that it appears to exist as a system of files from the point of view of the host device." Id. at 61. The district court understood its construction to limit the "virtual files" of the "virtual file system" to files "not physically stored on the interface device," whose content is data "originating from the data transmit/receive device." In re Papst Licensing GmbH & Co. KG Litig., 967 F.Supp.2d 48, 56 (D.D.C.2013). We reverse.

The core of the parties' disagreement is whether the "existing data" from which the virtual files are "constructed or derived" may already exist on the interface device when the host requests the virtual file. Although framed in different ways by the parties, the disagreement is similar to the dispute over the "when connected" language of the district court's construction of "data transmit/receive device." The Camera Manufacturers argue that "virtual files" cannot contain data already existing physically on the claimed interface device; rather, the data in such files must be present only on the data device, not the interface device, when requested by the host device. Papst argues that the phrases "virtual files" and "simulating a virtual file system" allow the virtual files to be derived from data already physically stored on the interface device when the host requests the relevant virtual file.

We agree with Papst. Nothing in the claims or written description limits a "virtual file" to one whose content is stored off the interface device, though it includes such files. "Virtual" conveys some kind of as if action, one thing emulating another; the term was prominently used that way in the computer field at the time of the inventions here. See CardSoft v. Verifone, Inc., 769 F.3d 1114, 1117-18 (Fed.Cir.2014) (discussing Java Virtual Machine in patent dating to 1998). What is crucial is how the patent identifies the emulation. In the present context, the emulation does not turn on whether data in a "virtual file" is physically located in the interface device or a data device when the host seeks it.

As we have explained, what the patent describes as the advance over prior art is the use of a host-native driver for obtaining access to data even when the data is not actually on a device of the type for which that driver was designed — in the featured example, not actually on a hard drive. Nothing in the written description suggests that this depends on what non-host physical memory units hold the data as long as the interface device mimics the data-organizational tools expected by the host-native driver, such as directory structures for a hard-disk drive, to enable the host to gain access to it. To impose the district court's requirement tied to physical location is to introduce a meaning of "virtual" that is foreign to what is described as the invention's advance. An interface device file is "virtual" in the only way relevant to the invention when it organizes data in a manner that allows the host to use its native driver to gain access to the data even if the data is not actually on a device for which the native driver was designed — regardless of where else that data may be.

The written description uniformly speaks of the "virtual" files in such data-organization terms, regardless of physical location in the memory of the interface device or on the data device. For example, the interface device may "simulate[] a hard disk with a root directory whose entries are `virtual' files," though no hard disk is in fact present. '399 patent, col. 6, lines 1-3. Similarly, in one embodiment the host device, during its boot sequence (system startup), sends a request to which the interface device responds with "a virtual boot sequence," causing the host to "assume[] that the interface device according to a preferred embodiment of the present invention is a hard disk drive." Id. lines 26-35 (figure numbers removed). Thereafter, the interface device supplies the host with data-organization responses consistent with a hard disk, including "the directory structure of the virtual hard disk." Id. lines 40-44. The written description elsewhere states that, "due to the simulation of a virtual mass storage device, the data is managed and made available in such a way that it can be transferred directly to other storage media, e.g.[,] to an actual hard disk of the host device." Id. col. 8, lines 50-55; see also id. col. 12, lines 26-29 ("[B]y simulating a virtual mass storage device, the interface device is automatically supported by all known host systems without any additional sophisticated driver software." (figure numbers removed)). While all of these examples discuss the organizational structure that the interface device conveys to the host device, not one mentions where data physically resides.

The point is reinforced by "[o]ther claims of the pa-tent[s] in question." Phillips, 415 F.3d at 1314. Claim 1 of the '449 patent requires a "virtual file system including a directory structure." '449 patent, col. 12, lines 5-6. Claim 2 explains the types of files that may appear in the directory structure: "the directory structure has a configuration file ... or an executable or a batch file ... or a data file... or a help file." Id. col. 12, lines 8-13. Enumerating those types of files as part of the virtual file system suggests that virtual files may include data physically stored on the interface device, particularly if the interface device is stand-alone, which it may be. For example, the "help file" is "for giving help on handling the interface device." Id. col. 12, lines 12-13. A logical place to store such a file, as indicated by the written description, is on the interface device. See id. col. 11, line 37 (referring to "[h]elp files included on the interface device"). So too with a "configuration file" for "setting and controlling the functions of the interface device." Id. col. 12, lines 8-9. And the written description makes clear that the data for those files may be stored directly on the interface device. See, e.g., id. col. 6, lines 50-54 (explaining that storing files, like the configuration file, "in the memory means of the interface device" allows "any enhancements or even completely new functions of the interface device [to] be quickly implemented" (figure numbers removed)); id. lines 61-67 ("[I]nstallation [on the host device] of certain routines which can be frequently used ... is rendered unnecessary as the EXE files are already installed on the interface device and appear in the virtual root directory...." (emphasis added; figure numbers removed)). Those passages appear at column 7 of the '399 patent as well, and a similar analysis applies to claims 7-10 of the '399 patent. See '399 patent, col. 13, lines 33-51.

The written description does refer to one type of virtual file as a "real-time input" file, where the host computer can request a portion of the data from the real-time input file "whereupon data commences to be received via the second connecting device and data commences to be sent to the host device via the first connecting device." Id. col. 7, lines 17-22. The written description's discussion of real-time input files shows that a virtual file may be constructed from data residing on the data device. But nothing in the written description limits virtual files to that arrangement. Files whose content resides on the interface device are just as virtual in the relevant respect: they are accessible by the host's use of the same driver it would use if they were present on the actual device for which the host driver was created even when they are not.

E

Finally, Papst appeals the district court's construction of the term "input/out-put device customary in a host device" in the '399 patent and the term "storage device customary in a host device" in the '449 patent. The district court construed the '399 term to be a "data input/output device that was normally present within the chassis of most commercially available computers at the time of the invention." Claim Constr. Op. at 55. The court's construction for the '449 patent is identical, except that the words "data input/output" are replaced with the word "storage." Id.

When a host computer asks the claimed interface device what type of device it is, the interface device must respond that it is an "input/output device customary in a host device" so that the host will communicate with the interface device using the host's native software for that type of device. The parties disagree over whether the claims require that the device the interface device says it is be a type of device "normally present within the chassis" of a computer. We hold that the claims are not so limited. The written description makes clear that it is enough for the device to be one that was normally part of commercially available computer systems at the time of the invention.

Claim 1 of the '399 patent uses the phrase "input/output device[s] customary in a host device" three times, first in the preamble when it explains that the host device comprises "drivers for input/output devices customary in a host device," then twice when it defines how the interface device and the host computer communicate — the interface device "signals to the host device that it is an input/output device customary in a host device," thereby prompting the host to "communicat[e] with the interface device by means of the driver for the input/output device customary in a host device." This language does not carry a plain, precise meaning of physical location inside the chassis. The phrase "customary in a host device" is not especially precise, and it seems to emphasize what is customary, not whether the unit is inside or outside the device. It contrasts with, for example, "customarily found in" or simply "input/output device in a host device" — which have a greater suggestion of location, though themselves perhaps not definitively so.

For these reasons, we turn to the written description, which clearly evinces the intended meaning — and meets even the standard for overriding a seemingly plain meaning of the claim language. The written description shows that the "in" from "customary in" does not imply physical location inside a computer chassis. Most starkly, the patent explains that "[d]rivers for input/output devices customary in a host device ... are, for example, drivers for hard disks, for graphics devices[,] or for printer devices." '399 patent, col. 4, lines 27-30 (emphases added). By its structure — "drivers for X are, for example, drivers for 1, 2, and 3," thus equating X with 1, 2, and 3 — the sentence clearly means that, notably, a printer device is an example of an "input/output device customary in a host device." No one contends that a printer device was physically located inside the chassis of a computer at the time of the invention.

In addition, a preferred embodiment of the invention includes "a 25-pin D-shell connector to permit attachment to a printer interface of a host device[,] for example." Id. col. 9, lines 43-48 (figure numbers removed); see also id., Figure 2 (illustrating the D-shell printer connector). The clear implication is that the preferred embodiment allows the interface device to connect to the printer interface of the host computer because the interface device can inform the host computer that it is a printer and that the host should communicate with it using its built-in printer drivers. We do not generally construe the claims of a patent to exclude a preferred embodiment. Adams Respiratory Therapeutics, Inc. v. Perrigo Co., 616 F.3d 1283, 1290 (Fed.Cir.2010) ("A claim construction that excludes the preferred embodiment `is rarely, if ever, correct and would require highly persuasive evidentiary support.'" (citation omitted)).

Further undermining the construction of "customary in a host device" as "normally found in the chassis of most commercially available computers" is the fact that the written description does not equate "host device" with "computer." To the contrary, the description uses the words "host device," "host systems," "computer," and "computer systems" more or less interchangeably. See, e.g., '399 patent, col. 1, lines 20-21 ("host devices or computer systems are attached by means of an interface to a device"); id., lines 49-50 (describing an "electronic measuring device ... attached to a computer system"); id. col. 2, lines 1-7 (referring to "host systems" and "computer systems"); id. col. 4, line 60, to col. 5, line 32 (alternating between "host device," "host systems," "computer system," and "computer"); id. col. 8, lines 1-22 (similar). Even if we were to conclude that the phrase "customary in" conveys a physical location, therefore, the district court was wrong to conclude that the physical location must be inside a computer chassis. See Pickholtz v. Rainbow Techs., Inc., 284 F.3d 1365, 1373-74 (Fed.Cir.2002) (construing "located in the computer" to mean "located in the CPU, main memory, the CPU or main memory circuit boards, or qualifying peripherals" based on the written description's repeated use of "computer" and "computer system" interchangeably).

CONCLUSION

For the foregoing reasons, we vacate the district court's entry of final judgment and remand for further proceedings consistent with this opinion.

Costs are awarded to Papst.

VACATED AND REMANDED.