dissenting in part:
I agree with the analysis in Sections I and II of the majority opinion, but not with the majority’s claim construction in Section III. Although some may disagree, I think it clear that the '216 patent requires the “licensee unique ID” to be generated from inputs including at least one item of personal information. Because it is undisputed that Microsoft’s license digests are generated from information about the user’s computer and the purchased software, and *345not from information that personally identifies the user, I would affirm the grant of summary judgment on this alternative ground (at least as to the absence of literal infringement).
I. Claim Construction
While if divorced from context the phrase “licensee unique ID” could mean any identification sufficient to discriminate between licensees, this phrase is not used in such a broad sense in the context of the '216 patent specification, “the single best guide to the meaning of [this] disputed term.” Vitronics Corp. v. Conceptronic, 90 F.3d 1576, 1582 (Fed.Cir.1996). Rather, the specification makes clear that the claimed “licensee unique ID” must be generated, at least in part, from personal information and not merely computer-related or software-related information.
First, the specification distinguishes two prior-art patents on the ground that one patent “does not contemplate or disclose utilization of information which is unique to the user or intended licensee as part of the registration process which is to be distinguished from identification of the platform upon which the software is proposed to be run,” Col. 1:60-65 (emphases added), while the other patent’s disclosure similarly “is limited to identification of the platform.” Col. 1:66-2:8. As the majority concedes, these statements make clear that the “licensee unique ID” of the '216 patent cannot be generated from just any old inputs — at the least, inputs concerning the user’s computer are not sufficient. Maj. Op. at 343-44.
Even beyond this disclaimer of computer-related information, the “Summary of the Invention” section of the specification provides that the “licensee unique ID” is preferably generated from inputs including “prospective licensee credit card number, date of birth and full name and address.” Col. 3:50-53 (emphases added). Although the word “preferably” leaves room for other inputs to be used, the listed inputs clearly suggest that at least some data personally identifying the user is required. By contrast, non-personal data such as “hard disk information and/or other computer hardware or firmware information” is preferably used to create a “platform unique ID.” See col. 3:56-59 (emphasis added).
Similarly, the specification distinguishes between “information entered by a prospective registered user unique to that user,” on the one hand, and “a serial number generated from information provided by the environment in which the software to be protected is to run,” on the other hand, and provides that both kinds of information are preferably fed into the “registration number algorithm.” Col. 4:6-12. Thus, it is clear that the “registration number” or “licensee unique ID” must be composed at least in part from information unique to the user — in other words, as the patent abstract explains and the specification repeats, from “information supplied by the licensee which characterizes the licensee,” i.e., personal information. '216 patent abstract; Col. 3:1-2.
Finally, all of the specific embodiments described in the specification are consistent with the requirement that some information that personally identifies the user is input to create the “licensee unique ID.” The First Embodiment explains that “[t]he registration dialogue box C (in Fig. 2b) prompts the user for details unique to that user (including, for example, name, company, address, state, contact number),” which details are “passed through a registration number algorithm” along with a serial number to “generate[ ] a registration number or security key....” Col. 7:8-19 (emphasis added). All of the “details unique to [the] user” listed here are per*346sonal details about the user, not details about the user’s computer or about the software purchased by the user.
The majority writes that by virtue of the words “for example,” the specification leaves room for “other types of inputs.” Maj. Op. at 342-43 (emphasis added). I disagree. The words “for example” are most naturally read to leave room for other inputs of the same type as the listed examples, i.e., personal details other than the combination of name, company, address, state, and contact number. The majority also writes that if a user’s company or state is a sufficient input (rather than, say, her name), then the patent must allow a vendor-provided input to be sufficient for generation of a “licensee unique ID.” Maj. Op. at 343. But the majority’s premise is incorrect — the example given here by the patent is “name, company, address, state, contact number” (i.e., all of them, together serving to personally identify the user, e.g. John Smith of Widgets Inc. at 123 Arbor Lane, Cleveland OH, (216) 555-5555), not “name, company, address, state, or contact number” (i.e., any one of them, by itself likely insufficient to identify the user). My understanding is confirmed by the “registration dialogue box C” in Figure 2b, which corresponds to this Embodiment and provides that the “user must enter details in the specified fields in order to register the product including: name, company, address, contact number (phone and credit card details or corporate account number)” (emphasis added).1 This Figure allows alternatives for the type of contact number, but requires the user to enter each of her name, company, address, and contact number, so that the user is personally identified.
The Second Embodiment is no different. The majority writes that this embodiment refers only to “user registration details” and does not constrain these details in any way. But the Second Embodiment does not purport to differ from the First Embodiment with respect to the registration inputs. Rather, the “distinction as against the [Fjirst [Ejmbodiment” is that “a duplicate key file” is created at the time of registration and stored on the user’s computer. Col. 8:49-55. Thus the Second Embodiment, like the First, requires input of details like the user’s name, address, and contact number.
The Third Embodiment incorporates Figure 4 of the patent, which is a “modified form of the dialogue box C of Fig. 2b” referenced in the First Embodiment, and includes, inter alia, lines for the user’s name, organization, address, and credit card number (i.e., not simply the user’s name or organization or address). Col. 9:32-34. There is no heading for a “Fourth Embodiment.” The Fifth Embodiment recites that the “registration procedure” executed by the disclosed microprocessor is “as previously described with reference to the [Fjirst [Ejmbodiment.” Col. 10:42-44. Thus the Third and Fifth Embodiments, like the First, require input of personal information.
The Sixth Embodiment “operates in the manner generally described in respect of previous embodiments” and recites that “[tjhe algorithm, in this embodiment, combines by addition the serial number 50 with the software product name and customer information 65 and previous user identification 22 to provide registration number 66.” Col. 11:42-56 (emphases added). Here, “customer information 65” most naturally refers to personal informa*347tion because the “software product name” (ostensibly provided by the vendor) is recited separately, and because computer-related information such as “CPU number ..., amount of memory, type of processor etc.” is described as comprising the “serial number 50.” Col. 12:8-18.
Finally, the Seventh Embodiment distinguishes between personal, computer-related, and software-related information by reciting that the “local licensee unique ID generating means [combines], by addition, customer information C, product infoimation P and serial number S in order to provide a local licensee unique ID----” Col. 12:62-65 (emphases added). Because the specification thus distinguishes explicitly between “customer information” on the one hand, and “product information” or “software product name” on the other hand, and because the specification requires information unique to a “user,” “licensee,” or “customer” in every embodiment while only requiring product-related information in some embodiments, I cannot agree with the majority that the patent “leave[s] open the possibility that vendor-provided information, like Microsoft’s Product Key, could be the basis for a ‘licensee unique ID.’” Maj. Op. at 844 (emphasis added). To be sure, vendor-provided (i.e., software-related) information may be among the inputs used to generate a “licensee unique ID,” but the patent clearly requires that at least one item of personal information be included as well.
In arriving at this construction I recognize, as the majority states, that it is improper to import limitations from the specification into the claims. But here the claims explicitly recite a “licensee unique ID”; I am not importing this limitation from the specification, but rather resorting to the specification to determine what an ordinary artisan would understand this limitation to mean, for as we have explained, “[t]he claims are directed to the invention that is described in the specification [and] they do not have meaning removed from the context from which they arose.” Netword, LLC v. Centraal Corp., 242 F.3d 1347, 1352 (Fed.Ch.2001); see also Phillips v. AWH Corp., 415 F.3d 1303, 1316 (Fed.Ch.2005) (“the specification necessarily informs the proper construction of the claims”).
Similarly, the majority is clearly correct that patent claims, in general, may be broader than the preferred embodiments disclosed in a specification. However, we have explained that “the patentee’s choice of preferred embodiments can shed light on the intended scope of the claims.” Astrazeneca AB v. Mut. Pharm. Co., 384 F.3d 1333, 1340 (Fed.Ch.2004). Here I do not propose to limit the scope of the claims to the precise embodiments disclosed in the specification — e.g., to always require input of the user’s name — but rather to refer to those embodiments for examples of the kind of information an ordinary artisan would understand to be involved in generation of a “licensee unique ID.” See, e.g., Inpro II Licensing, S.A.R.L. v. T-Mobile USA, Inc., 450 F.3d 1350, 1355 (Fed.Cir.2006) (“Although claims need not be limited to the preferred embodiment when the invention is more broadly described, neither do the claims enlarge what is patented beyond what the inventor has described as the invention.”) (internal citation omitted).
II. Infringement
Microsoft’s Product Activation system, in contrast to the invention claimed in the '216 patent, does not require any personal information from the user or licensee. Indeed, Microsoft intentionally avoids the use of personal information, explaining in its End-User License Agreement that *348“Microsoft will not collect any personally identifiable information from your device” during the activation process. Instead, the Microsoft system relies on information unique to the computer on which the software is being installed — in the vernacular of the '216 patent, “identification of the platform” — and on information culled from the package in which the software product was purchased — “product information”— regardless of whether the user or licensee is the same person who purchased the software product.
Specifically, Microsoft’s Hardware ID (“HWID”) is generated from information about the hardware of the user’s computer, but does not identify the user herself. A Product ID (“PID”) is generated from the Product Key found on the package in which the software was purchased, information about the software version, and a random number generated by the software. The majority notes that Microsoft’s own documents describe the Product Key as a way to help Microsoft identify its customers, Maj. Op. at 343-44, but such shorthand notwithstanding, it is clear that the Product Key at most identifies a particular copy of the software, and does not personally identify the user of that copy.
In the accused Product Activation system, once a HWID and PID have been generated by a user’s computer, Microsoft’s Clearinghouse uses the PID and HWID to generate a license, hashes the license to form a license digest, and encrypts the license digest. Uniloc’s theory of infringement in this appeal is that the license digest constitutes a “licensee unique ID.” But because the license digest is generated only from platform-related information (the HWID) and product-related information (the PID), and not from any personal information, the license digest cannot be a “licensee unique ID” within the meaning of the asserted claims as I think they are properly construed. Therefore I would affirm the district court’s grant of summary judgment to Microsoft — at least as to the question of literal infringement — on this alternative ground, because “[w]e must affirm the decision of the district court if it is supported by any ground properly preserved on appeal.” Ethicon Endo-Surgery v. United States Surgical Corp., 93 F.3d 1572, 1582 (Fed.Cir.1996) (emphases added); see also Glaxo Group v. TorPharm, Inc., 153 F.3d 1366, 1371-1372 (Fed.Cir.1998) (‘When a matter comes before an appellate court following a summary judgment, the appellate court is free to adopt a ground advanced by the appellee in seeking summary judgment but not adopted by the trial court.”); Datascope Corp. v. SMEC, Inc., 879 F.2d 820, 822 (Fed.Cir.1989) (“Appellees always have the right to assert alternative grounds for affirming the judgment that are supported by the record.”).
. I recognize that the Figure recites "address” where the specification recites "address, state,” but I do not think this discrepancy matters because a request for one's “address” typically includes the state where "state” is not separately requested.