Opinion
No. C 03-3029 PJH.
September 24, 2004
ORDER CONSTRUING CLAIMS
Plaintiff IDN Technologies, LLC ("IDNT") owns U.S. Patent No. 6,182,148 ("the `148 patent"), which is entitled "Method and System for Internationalizing Domain Names." The `148 patent describes a system for converting non-English and other special characters in an Internet domain name to a standard character set so that international users can specify web sites and other Internet addresses using their local scripts and languages, rather than English characters.
Defendant VeriSign, Inc. ("VeriSign") operates an Internet domain name registry. VeriSign distributes and uses software that allows Internet users to access web pages by entering domain names that use non-English and other special characters. This software is referred to as "International Domain Name" or "IDN" software. IDNT alleges that VeriSign's distribution and use of this software infringe IDNT's `148 patent.
On March 15, 2004, pursuant to the local rules of this court, the parties filed a joint claims construction statement. On July 21, 2004, following the filing of briefs by the parties, the court heard argument regarding the construction of two disputed terms in the claims of the `148 patent. IDNT appeared by its counsel Scott D. Wofsy and Neil G. Cohen, and VeriSign appeared by its counsel Stephen R. Mick, Andrew Spicer, and Clark Jablon. At the conclusion of the hearing, the court took the matter under submission, and now rules as follows.
BACKGROUND
In addition to the sources cited in this section, the court relied on sources and information presented by the parties in connection with the technical tutorial and the Markman hearing. The court also consulted the following: Harry Newton, Newton's Telecom Dictionary (17th ed. 2001); McGraw Hill Dictionary of Scientific and Technical Terms (6th ed. 2003); and Connected: An Internet Encyclopedia, available at http://freesoft.org/CIE.
The Internet is a worldwide system of interconnected computer networks that communicate using a set of rules known as "protocols." The Internet's principal communication standard is known as "TCP/IP." The TCP (Transmission Control Protocol) component breaks down and reassembles data packets, providing reliable connections between computers. The IP (Internet Protocol) component controls the flow of data packets across the Internet, ensuring that the data is sent to the correct destination.
A computer can send data one character at a time, but it is more efficient to send information in blocks or bundles, known as "packets."
See Register.com, Inc. v. Verio, Inc., 356 F.3d 393, 409 n. 9 (2d Cir. 2004) (history and operations of the Internet); see also Thomas v. Network Solutions, Inc., 176 F.3d 500, 502-04 (D.C. Cir. 1999) (development of the Internet);PGMedia, Inc. v. Network Solutions, Inc., 51 F.Supp. 2d 389, 390-400 (S.D.N.Y. 1999) (development and history of the Internet).
An "Internet host" is a computer that provides services to users' computers. Each Internet host is assigned a unique numerical designation or "address," called the "IP address." A host computer can function as the source or as the recipient of data transfers on a network. When one computer sends data to another computer over the Internet, the data packet contains the IP address of the destination. The IP address is essentially a routing system that allows data to be forwarded to an appropriate computer across the Internet.
The World Wide Web is an Internet service, which uses TCP/IP to provide access to web pages and other documents and resources. The web pages are stored in computers known as "web servers." A computer user generally runs a program called a "browser" — e.g., Netscape Navigator® or Microsoft Internet Explorer® — to access web pages.
To access a web page, a user may enter the numerical IP address of the web server in the browser. Because IP addresses consist of strings of numbers separated by periods (dots), they are difficult for most people to remember. The Domain Name System (DNS) makes using the Internet easier by allowing users to access web pages by entering Uniform Resource Locators (URLs), which specify, among other things, the name of the web server rather than its numerical IP address. The names of web servers are called "domain names."
A domain name is an alphanumeric string — a series of characters manipulated as a group — that identifies a particular computer or a network on the Internet. Every domain name has a corresponding IP address, but not every IP address is assigned a domain name. A domain name is associated with a particular IP address only when the end-user registers the domain name.
The DNS is a database containing information about Internet hosts. Hosts use DNS to convert domain names to IP addresses through a process called "resolution." DNS divides the Internet into multiple levels of domains, each representing a group of hosts, organized in a hierarchical structure similar to an inverted "tree." The inverted tree structure includes many nodes, which are represented by dots ("."), and each of these nodes has an associated descriptor, known as a "label." Thus, a label is essentially a string of characters delineated by dots.
The "root," or highest level, of the system is unnamed. All other domains are contained under the root, and each node indicates a different domain. Immediately under the root lie numerous the top-level domains (TLDs), such as ".com" for commercial sites and ".gov" for government sites, as well as the "country codes" — such as ".uk" and ".fr" — which are used primarily, though not exclusively, by citizens of the corresponding countries. Lower-level domains branch out down the tree: second-level domains (SLDs) branch out from the TLDs, third-level domains branch out from the SLDs, and so forth.
In the DNS inverted tree representation, the full name of a domain is obtained by traversing a path beginning at the lowermost node and concluding at the root. A browser traverses this path, however, by reading a domain name from right to left. Thus, the domain name "cand.uscourts.gov." consists of 1) an empty-text label to the right of the right-most dot, which represents the root node; 2) ".gov" — which represents the TLD, in this case, one reserved for networks associated with the government of the United States; 3) ".uscourts" — which represents the SLD, in this case, a set of the networks used by the United States Courts; and 4) "cand" — which represents the third-level domain, a subnetwork or computer used by the United States District Court for the Northern District of California.See Register.com, 356 F.3d at 410-11; Lockheed Martin Corp. v. Network Solutions, Inc., 985 F.Supp. 949, 952 (C.D. Cal. 1997).
The Internet is structured so that each domain can assign responsibility for the domains directly under it — the subdomains — to others. This process, known as "delegation," distributes responsibility for management of domain names across the Internet. In the DNS, all domains reside under the root. The root has delegated management responsibilities to the TLDs, which in turn have delegated management to the SLDs. Some SLDs have delegated management to third-level domains. For example, "www.uscourts.gov" is responsible for the World Wide Web service for "uscourts.gov."
All TLDs, and many domains on the second level and lower, are divided into smaller, more manageable units by delegation. These units are called "zones." A "name server" is a computer associated with a zone, which is responsible for resolving (providing the IP address for) any host computer in its zone. The name server for a particular zone is charged with maintaining a list of the IP addresses for the hosts in that zone, and is considered "authoritative." There are presently 13 name servers on the Internet that act as "root name servers" or "root servers," and which know the IP addresses of each name server for the TLDs — both the global registries such as .com and .org, and the country-specific registries.
Web browsers rely on domain name "resolution" to function properly. Resolution is the process of obtaining information necessary to convert a domain name into its corresponding IP address. When presented with a domain name for resolution, a browser (or other application) executes a program called a "resolver." The resolver sends the domain name to a local name server for the zone in which it is executing. If the local name server knows the IP address for the domain name, it will return that address to the resolver. If, however, the local name server does not know the requested IP address, it will send out an "address query," performing a series of steps in which it traverses the "delegation path" specified by the domain name, until it reaches a server from which it can obtain the IP address.
Address inquiries are resolved hierarchically. The local domain name server contacts the domain server for the root zone, and requests the IP address. The root domain server refers the local domain name server to the appropriate domain name server for the TLD zone. If the appropriate TLD zone domain name server does not know the IP address, it refers the local domain name server to the location of the domain name server it should ask next (the appropriate SLD name server). The process continues until the local domain name server locates the IP address. The local server then returns the IP address information to the resolver.
In the early days of the Internet, most users used only ASCII character sets on their computers. As a result, the initial standardized format allowed only domain names that contained the English upper and lower case letters A through Z, the digits 0 through 9, and the hyphen. These characters — the English letters, the digits, and the hyphen — are referred to as "compliant" characters because they comply with the standards of the DNS. Thus, a domain name that includes only compliant characters is known as a "compliant domain name." A domain name that contains at least one non-compliant character in at least one of its labels is known as an "Internationalized Domain Name" (IDN).
ASCII is the acronym for American Standard Code for Information Interchange. ASCII is a code for representing English characters as numbers, with each letter assigned a number from 0 to 127.
RFC 1035, the standard for establishing a compliant domain name, was developed by the Internet Engineering Task Force (IETF), which publishes its standards in documents known as "Requests for Comments" or "RFCs." Thus, compliant domain names are often referred to as "RFC compliant" or "RFC-1035 compliant."
The problem with Internet domain names being in an ASCII format is that an Internet user whose native language is represented by a non-ASCII character set, or script, such as Japanese or Arabic, cannot access or use domain names containing characters from his or her native language because those domain names cannot be resolved to IP addresses using accepted DNS standards. The technology at issue in the present case is a system that allows non-compliant characters to work with the existing DNS rules for resolving domain names.
The `148 patent teaches a method and system for internationalizing domain names. When a user enters a domain name including non-English (non-compliant) characters into an Internet program, a domain name "transformer" provided at the user level intercepts the domain name before it reaches the resolver. The domain name is then converted into a standard format that can represent all language sets, such as UNICODE, and the UNICODE string is converted to a RFC-1035 compliant format. A "redirector string," which contains information for resolving the RFC-1035 compliant domain name, is then attached to the domain name. The compliant domain string is then resolved by the authoritative domain name server just as any domain name made up of English characters.
UNICODE is a 16-bit system for encoding letters and characters of all the world's languages. It was developed by the UNICODE Consortium. See http://www.unicode.org
DISCUSSION
A. Legal Standard
Patent infringement analysis involves a two-step process. First, the court must determine as a matter of law the correct scope and meaning of disputed claim terms. Second, the properly construed claims are compared to the accused device to see whether the device contains all the limitations (literally or by equivalents) in the claims at issue. Markman v. Westview Instruments, Inc., 517 U.S. 370, 384 (1996).
Claim construction "begins and ends" with the actual words of the claims. Renishaw PLC v. Marposs Societa' per Azioni, 158 F.3d 1243, 1248 (Fed. Cir. 1998). "The terms used in the claims bear a `heavy presumption' that they mean what they say and have the ordinary meaning that would be attributed to those words by persons skilled in the relevant art." Texas Digital Sys., Inc. v. Telegenix, Inc., 308 F.3d 1193, 1202 (Fed. Cir. 2002) (citations omitted), cert. denied, 538 U.S. 1058 (2003).
A patentee is presumed to have intended the ordinary meaning of a claim term in the absence of an express intent to the contrary.York Prods., Inc. v. Central Tractor Farm Family Ctr., 99 F.3d 1568, 1572 (Fed. Cir. 1996). In determining ordinary meaning, the court is explicitly permitted to rely on reference materials such as dictionaries, treatises, or encyclopedias in general use at the date of the patent's issuance. Texas Digital, 308 F.3d at 1202-03 (citations omitted).
The words in the claim must be then interpreted "in light of the intrinsic evidence of record, including the written description, the drawings, and the prosecution history, if in evidence." Teleflex, Inc. v. Ficosa North Am. Corp., 299 F.3d 1313, 1324-25 (Fed. Cir. 2002) (citations omitted). "Such intrinsic evidence is the most significant source of the legally operative meaning of disputed claim language." Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996).
Only if an analysis of the intrinsic evidence fails to resolve any ambiguity in the claim language may the court then rely on extrinsic evidence, such as expert declarations. Id. at 1583 ("In those cases where the public record unambiguously describes the scope of the patented invention, reliance on any extrinsic evidence is improper").
B. Claims Construction
The `148 patent has 38 claims, of which 5 are in independent form. Independent claims 1, 28, and 31 are asserted in this action. In the present proceeding, the parties request the court to construe the meaning of two terms used in independent claims 1, 28, and 31. The disputed claim terms are "appending" and "redirector string."
Claim 1 recites
A method of converting an internet international domain name to an RFC1035 compliant format, where the international domain name includes non-English characters which are RFC1035 non-compliant, the method comprising:
intercepting the international domain name, where the intercepting is transparent to the user;
transforming the international domain name to an RFC1035 compliant domain name;
automatically generating a redirector string which includes information for resolving the RFC1035 compliant domain name; and
appending the redirector string to the RFC1035 compliant domain name.
Claim 28 recites
A software program for enabling a user device to be connected to the Internet wherein domain name requests in the user device are obtained having a non-compliant format; said program comprising:
instructions for modifying a domain name resolving process in the user device; wherein said instructions for modifying include instructions for performing the following steps:
transforming a non-compliant domain name request to a compliant format;
automatically generating a redirector string which includes information for resolving the domain name request; and
appending the redirector string to the domain name request.
Claim 31 recites
A method of modifying a user device which communicates to the Internet wherein the user device processes a compliant domain name according to a resolving procedure, and further wherein a domain name request may be in a non-compliant format, the method comprising the steps of:
providing a program to the user device for modifying the resolving procedure so that the modified resolving procedure performs the following steps:
transforming a non-compliant domain name to a compliant domain string;
automatically generating a redirector string which includes information for resolving the transformed compliant domain string; and
appending the redirector string to the compliant domain string.
IDNT argues that "appending" means "attaching," while VeriSign interprets it as "adding or attaching to the end of." IDNT argues that "redirector string" means "delegation instructions — information that is part of a path under a root — for enabling domain name servers to provide information (e.g., an IP number) corresponding to a compliant domain name request." VeriSign contends that "redirector string means "one or more contiguous domain labels, including a top level domain that was not part of the originally entered domain name, which identify the domain name server responsible for resolving the transformed compliant domain name."
The parties seem to agree that the patentee (Dr. Walid Tout) did not act as his own lexicographer with regard to the disputed terms, in the sense that he did not provide any explicit definition. They agree further that there is no clear or precise indication in the patent claims or specification or in the prosecution history of any special meaning assigned to the two disputed terms. Thus, the court must consult the other available sources of the acquired meaning of the claim language.See IMS Tech., Inc. v. Haas Automation, Inc., 206 F.3d 1422, 1433 (Fed. Cir. 2000).
The court first considers the proper construction of "redirector string," and then considers whether the `148 patent requires that the redirector string be attached to the end of the domain name, or simply that it be attached to the domain name, location unspecified.
1. "Redirector String"
IDNT argues that "redirector string" should be construed as "delegation instructions — information that is part of a path under a root — for enabling domain name servers to provide information (e.g., an IP number) corresponding to a compliant domain name request." VeriSign contends that "redirector string" means "one or more contiguous domain labels, including a top level domain that was not part of the originally entered domain name, which identify the domain name server responsible for resolving the transformed compliant domain name."
In the language of the claims, the "redirector string" is identified only as something that "includes information for resolving" the compliant domain name or the domain name request. The parties agree that "redirector string" does not have an ordinary meaning and is not generally known in the art. In such cases, the specification of the patent becomes the best source of meaning. Novartis Pharmaceuticals Corp. v. Abbott Labs, 375 F.3d 1328, 1334-35 (Fed. Cir. 2004). Both sides find support for their proposed constructions in the specification. VeriSign also claims that the prosecution history supports at least part of its proposed construction — the requirement that the TLD in the "redirector string" not be entered by the user. IDNT argues, however, that the prosecution history does not shed light on the meaning of "redirector string."
a. IDNT's proposed construction
IDNT argues that "redirector string" means "delegation instructions," as stated above. IDNT cites to the specification, which states that "the redirector string . . . provides delegation instructions for resolving the compliant domain name," col. 2, lines 49-53; that "the redirector information . . . provides delegation instructions for resolving the international domain name," col. 8, lines 1-3; and that "the redirector information controls the delegation path for resolving the domain name," col. 8, lines 32-37. VeriSign contends, however, that none of the statements in the specification actually defines what a "redirector string" is, suggesting that stating what something provides is not the same as stating what it is.
IDNT asserts that "delegation instructions" is commonly understood to mean "information that is part of a path under a root," citing Paul Albitz Cricket Liu, DNS and BIND (3d ed. 1988) ("Albitz") chapter 2.0. IDNT describes the concept of the "delegation path," from root to TLD to SLD, and explains that this delegation path enables a domain name server to resolve the domain name. IDNT argues that the specification of the `148 patent provides a specific example as to how such "delegation instructions" are used for resolving IDNs, and an explanation of what they are and what they do to facilitate resolution. The example cited by IDNT states that the "redirector information" ar.i18n.net "provides the following exemplary delegation instructions for resolving the international domain name."
Albitz states that "the term delegation refers to assigning responsibility for a subdomain to another organization."
The "i18n" identifies the domain name as "international" and the "ar" further identifies it as being in Arabic which is determined from the UNICODE range of the domain name characters. The domain resolution is explained as follows. The transformed compliant domain name including the redirector information is received by the domain name server 30 where it is attempted to be resolved. The domain name server 30 identifies the top level domain ".net" for which it is not an authoritative DNS. As such, the domain name server consults an authoritative root server which is responsible for net domains, for example, root server m from the root server group 35. Examining the second level domain "i18n", root server m determines from its database that the authoritative domain name server for this domain is, for example, DNS2 40. DNS1 30 then communicates the entire domain to DNS2 40. DNS2 40 first determines whether it is authoritative and delegated for this domain by scanning its database of registered domains. In this case, DNS2 40 determines from the redirector information that the delegated server for "ar.i18n.net" (Arabic domains) is the root server i3 from root server group 60. The resolution continues in the predescribed manner until the authoritative DNS for the current domain is determined which returns the IP number of the domain name. The foregoing example assumes that the domain "i18n.net" and sub-domain "ar.i18.net" were properly pre-assigned and registered to the appropriate root servers and domain name servers.
Col. 8, lines 1-31. IDNT does not analyze this example, however, or explain it any further other than to assert that "the specification describes precisely how the path under the root is traversed in order to resolve a domain name."
VeriSign contends that "delegation instructions" is an undefined term without an ordinary meaning. VeriSign disputes IDNT's assertion that the phrase "delegation instructions" is well-known and commonly understood in the art to mean "information that is part of a path under a root." VeriSign asserts that the Albitz reference does not support IDNT's proposed construction, noting that Albitz discusses "delegation" in the context of the delegation of subdomains by the organization that administers a given domain, much as a manager delegates responsibilities to his/her subordinates. VeriSign argues that "delegation" — which involves the granting of authority to someone else over something that is currently controlled by the person or thing doing the delegating — is not analogous to the description of "redirector string" or "redirector information" as it appears in the `148 patent, because a "redirector string" does not grant authority over anything to anyone.
VeriSign notes three differences between the concept of "redirector string" and "delegation." First, delegation occurs in a domain name server controlled by a domain name registrant, whereas a redirector string would reside in an Internet user's application or resolver. Second, delegation is executed by the registrant of a particular domain name or domain name server to give authority to another zone, whereas a redirector string can be created by anyone (such as by an application) to alter the resolution of the domain name to which a redirector string is appended. Third, delegation is analogous to instructions that configure a domain name server or system to function a certain way, occurring relatively rarely, while a redirector string is analogous to an instruction to go to a particular place, and is automatically generated each and every time an IDN is accessed.
b. VeriSign's proposed construction
VeriSign claims that the purpose of a "redirector string" in the `148 patent is to "provide a particular transformed IDN (in compliant format) with a specialized `international' TLD . . . where that IDN can be resolved." VeriSign argues that the specification and the prosecution history reveal several essential characteristics, which, taken together, define a "redirector string" in the `148 patent. VeriSign contends that "redirector string" means "one or more contiguous domain labels, including a top level domain that was not part of the originally entered domain name, which identify the domain name server responsible for resolving the transformed compliant domain name."
First, based on the examples in the `148 patent, VeriSign claims that a "redirector string" includes one or more contiguous domain labels. As indicated above, a domain label is part of a domain name, and consists of a string of characters delineated by dots. The specification states that "any identifiers can be used to represent a domain set." Col. 8, lines 3-4. The specification states further that "the redirector information can be a single unique top level domain which identifies an international root server," referred to as an "iroot server," or "may include multiple levels of identifiers such as "ar.i8n.net." Col. 8, lines 34-37. Put another way, the examples of redirector information provided in the specification all consist either of one domain label or of multiple contiguous domain labels.
Second, based on the specification, VeriSign asserts that a "redirector string" in the `148 patent must include a TLD. The specification identifies a string — ".ar.i18n.net" — as "redirector information" that is "appended to" the converted string of domain labels and which "functions like a top level domain" and "identifies the authoritative domain name server responsible for the current domain name." Col. 7, lines 50-54. The specification states further that a domain name becomes a fully-qualified domain name once "redirector information" is appended to the domain name. Col. 7, lines 54-58. According to the Albitz reference, a "fully-qualified domain name" must, by definition, include a TLD. As explained in the patent, a compliant domain name can be resolved only if it is a fully-qualified domain name, thereby including by definition a TLD that identifies the domain name server responsible for resolving the compliant domain name. Id.
Third, VeriSign argues that the TLD in the "redirector string" cannot be part of the originally entered domain name. VeriSign contends that this requirement is established by the fact that every embodiment of the `148 patent requires a TLD that is not part of the originally entered domain name, and by the fact that the only detailed example in the `148 patent that attempts to explain how to append a "redirector string" to a domain name does not include a TLD in the string entered by the user (citing to col. 7, lines 5-46, where the entered foreign script or text does not include a TLD and the TLD appears for the first time as part of the "redirector information"). VeriSign argues that this requirement is also implied by the definition in the specification — "the redirector information . . . is appended to the converted string and functions like a top level domain" (citing col. 7, lines 50-53).
The specification includes two additional examples in which the TLD portion of the "redirector string" is not part of the originally-entered IDN, but rather is automatically provided by the computer system running the translation process.
VeriSign asserts further that this requirement is reflected in the prosecution history. The Patent Examiner rejected the claims of the patent application that matured into the `148 patent on the basis that the primary reference (the "i-DNS reference") required the user to either manually enter and append a predetermined suffix, such as "i.DNS.apng.org" (necessary to direct the domain name request to a proxy server), or manually point the computer's DNS resolver to the proxy server for resolution of the entered IDN. The Examiner found that the claims of the `148 patent application were anticipated by prior art (the i-DNS reference).
In response to the Examiner's rejection of the claims, the applicant added the word "automatically" to the phrase "generating a redirector string" in each of the independent claims, arguing that this distinguished the claimed invention from the prior art, where the user entered the redirector information. The applicant argued that "with the present method, international domain names can be used with existing internet protocols" and "without additional steps performed by a user." VeriSign claims that these "additional steps" referred to by the applicant include the entry of a TLD by the user as defined in the i-DNS reference. In other words, in the system claimed in the `148 patent, the user does not need to input or even to know what TLD is required to resolve an IDN. Thus, VeriSign claims, the patent requires that the system automatically generate the "redirector string" without any user input of the TLD or any other portion of the redirector string.
IDNT contends that the patent provides no basis for construing "redirector string" as argued by VeriSign, and asserts that the three "essential characteristics" are not defined in the specification, the claims, or the prosecution history. First, IDNT argues that it is not essential for a "redirector string" to include one or more domain labels. IDNT cites to the statement in the specification which states that "any predetermined string can be used to identify an international domain and identify a responsible server." Col. 9, lines 1-2. IDNT contends that there is no requirement in the `148 patent that the "redirector string" include a single label, let alone one or more contiguous labels. IDNT asserts that according to the `148 patent, a "redirector string" need only be delegation instructions, and any "predetermined" string can suffice. IDNT argues that examples from the patent specification cannot not be read into the claims as limitations, and that claims of a patent cannot be limited by preferred embodiments.
IDNT also contends that the requirement that a "redirector string" include "one or more contiguous labels" contravenes the doctrine of claim differentiation. This doctrine provides that an independent claim is to be afforded a broader scope than a claim that depends from it. AK Steel Corp. v. Sollac and Ugine, 344 F.3d 1234, 1242 (Fed. Cir. 2003). In the case of the `148 patent, claim 30 depends from claim 28. Claim 28 recites "[a] software program . . . comprising . . . instructions for performing the following steps: . . . automatically generating a redirector string which includes information for resolving the domain name request." Claim 30 recites "[a] software program . . . including instructions for automatically generating the redirector string where the redirector string identifies a domain name server for resolving the transformed compliant domain name." Under the doctrine of claim differentiation, claim 28 must be interpreted as broader than (or at least not narrower than) claim 30. Thus, the "redirector string" in independent claim 28 can include, but is not limited to, a "redirector string" that identifies a domain name server. IDNT contends that VeriSign's interpretation requiring "one or more contiguous labels" — which IDNT claims effectively requires that the "redirector string" identify a domain name server — cannot be correct.
Finally, IDNT asserts that it is not necessary for a "redirector string" to include a top-level domain. IDNT points to the specification, which states at col. 8, lines 34-35, that "[t]he redirector information can be a single unique top level domain." IDNT argues that there is nothing in the specification that requires that the "redirector information" include a TLD, and asserts that the inventor's use of the open-ended word "can" — as opposed to "must" — mandates the opposition conclusion. IDNT claims that the DNS tree could be structured so that the "redirector string" functions as an SLD, rather than a TLD.
IDNT also disputes VeriSign's contention that it is necessary under the `148 patent for the "redirector string" to include a TLD because the patent does not teach through experimentation or example what a "redirector string" would look like if the user entered a TLD with the IDN. IDNT asserts that while it is true that a patent application must adequately disclose the claimed invention, it is not necessary that there be a description of "every nut, bolt, or detail used to practice the invention." IDNT claims that a person skilled in the art would know that a prerequisite for any implementation of IDNs is a set of rules governing how IDNs are handled in DNS, including the way a "redirector string" is generated. Once those rules are set, it would be a simple matter of routine programming to generate the "redirector string."
c. construction of "redirector string"
The court finds that VeriSign's proposed construction is the better of the two. While it is true, as IDNT contends, that the specification indicates that the "redirector string . . . provides delegation instructions," that does not mean that the "redirector string" is delegation instructions. Moreover, as VeriSign persuasively argues, the concept of "delegation" — a term that is well-known in the art — is not analogous to the concept of "redirector string" or "redirector information" as it appears in the claims of the `148 patent, because a "redirector string" does not grant authority over anything to anyone. Nor can "delegation instructions" (or "redirector string") be defined in turn as "information that is part of a path under a root." As VeriSign's counsel noted during the hearing on claims construction, "information" can mean anything or everything, and "the path under the root" includes everything in the Internet.
One of the questions underlying the parties' dispute with regard to the construction of "redirector string" is the extent to which the specification should limit the construction, in a case where there is no common meaning for the disputed term and the patentee did not directly indicate a definition. The general rule is that the court is required to interpret the claims in light of the specification, but must avoid impermissibly importing limitations from the specification. The balance between the two turns on how the specification characterizes the claimed invention. Alloc, Inc. v. Int'l Trade Com'n, 342 F.3d 1361, 1370 (Fed. Cir. 2003), cert. denied, 124 S.Ct. 2390 (2004).
In this respect, the court looks to whether the specification refers to a limitation only as a part of less than all possible embodiments or whether the specification read as a whole suggests that the very character of the invention requires the limitation be a part of every embodiment. For example, it is impermissible to read the one and only disclosed embodiment into a claim without other indicia that the patentee so intended to limit the invention. On the other hand, where the specification makes clear at various points that the claimed invention is narrower than the claim language might imply, it is entirely permissible and proper to limit the claims.Id. (citations omitted).
In a case such as the present one, where a term has no meaning outside of the patent, the general rule that the court cannot read limitations into the claims from the examples in the specification does not apply in the same way. Instead, the specification may act as a dictionary when it defines the claim terms by implication, just as when it expressly defines claim terms. See Vitronics, 90 F.3d at 1582. When a patentee uses a claim term throughout the entire patent specification, in a manner consistent with only a single meaning, he has defined that term "by implication." Bell Atlantic Network Servs., Inc. v. Covad Communications Group, Inc., 262 F.3d 1258, 1271 (Fed. Cir. 2001); see also Scimed Life Sys., Inc. v. Advanced Cardiovascular Sys., Inc., 242 F.3d 1337, 1344 (Fed. Cir. 2002) (while it is true that the claims define the scope of the right to exclude and that the claim construction inquiry begins and ends in all cases with the actual words of the claim, the written description can provide guidance as to the meaning of the claims, thereby dictating the manner in which the claims are to be construed, even if the guidance is not provided in explicit definitional format).
VeriSign's proposed construction finds support in both the specification and the prosecution history. First, the "redirector string" must include a TLD. The specification states that "[a] redirector string . . . includes information for resolving the RFC1035 compliant domain name" and is "appended to the RFC1035 compliant domain name." Col. 1, lines 61-64. This "redirector information . . . functions like a top-level domain," and once it is appended to the compliant domain name, "the domain name becomes a fully qualified domain name" that includes at least a TLD and a SLD, "which is enough information to resolve the domain name. Col. 7, lines 49-57.
Second, the "redirector string" contains one or more contiguous labels. The only way to specify a TLD is with a label. According to the specification, the redirector information "can be a single unique top-level domain" — a single label — or it "may include multiple levels of identifiers" — several contiguous labels. See Col. 8, lines 34-37. The court does not agree with IDNT that this construction violates the principle of claim differentiation as to claims 28 and 30. It is true that a "redirector string" in claim 28 can include, but is not limited to, a "redirector string" that identifies a domain name server for resolving the compliant domain name. However, it does not follow from this that defining "redirector string" as having one or more contiguous labels effectively requires that the "redirector string" identify the domain name server responsible for resolving the compliant domain name.
It is more accurate to say that a "redirector string" consists of either a single label or two or more contiguous labels.
Third, the "redirector string" cannot be part of the originally entered domain name. Every embodiment of the `148 patent requires a TLD that is not part of the originally entered domain name. Moreover, the only detailed example that explains how to append a "redirector string" to a domain name does not include a TLD in the string entered by the user. See col. 7, lines 5-46.
This requirement is also reflected in the prosecution history, which indicates that the patent applicant added the word "automatically" to the phrase "generating a redirector string" in the independent claims, arguing that this distinguished the claimed invention from the prior art (where the user entered the information). It is well-established that statements made during prosecution are used to interpret the scope and meaning of ambiguous claim terminology. Schumer v. Lab. Computer Sys., Inc., 308 F.3d 1304, 1312 (Fed. Cir. 2002) (citing Vitronics., 90 F.3d at 1582).
2. "Appending"
IDNT and VeriSign agree that "appending" means "attaching," but dispute whether the term should be construed simply as "attaching" (IDNT) or as "attaching to the end of" (VeriSign). In other words, the dispute regarding the construction of "appending" centers on whether, in the claims at issue, the redirector string must be attached to the end of the domain name, or whether it must simply be attached to the domain name, with the location being unspecified.
Where, as here, the patent applicant has not acted as his or her own lexicographer, the process for determining the acquired meaning of a word in a claim begins with the presumption that the word (or term) has its full ordinary or accustomed meaning.Johnson Worldwide Assocs. v. Zebco Corp., 175 F.3d 985, 989 (Fed. Cir. 1999). If a word has a meaning from the ordinary use of the English language, then the word is presumed to have acquired that meaning. Nat'l Recovery Techs. v. Magnetic Separation Sys., Inc., 166 F.3d 1190, 1195 (Fed. Cir. 1999). In addition, however, if the word had a customary meaning known at the time of invention to one with ordinary skill in the art to which the patent pertains, then the word is presumed to have acquired that meaning. Arthur A. Collins, Inc. v. Northern Telecom Ltd., 216 F.3d 1042, 1044-45 (Fed. Cir. 2000). If there is both an ordinary meaning and a customary meaning, and the two are in conflict, then the customary meaning to persons skilled in the relevant art is the presumed meaning. Karlin Tech., Inc. v. Surgical Dynamics, Inc., 177 F.3d 968, 971 (Fed. Cir. 1999).
Nevertheless, ascertaining the presumed meaning is not dispositive by itself of the acquired meaning of the word (or term) in a patent claim, because the court must also consider the particular use of those words in the patent. Toro Co. v. White Consol. Indus., Inc., 199 F.3d 1295, 1301 (Fed. Cir. 1999).
In construing claim terms, the general meanings gleaned from reference sources, such as dictionaries, must always be compared with the use of the terms in context, and the intrinsic record must always be consulted to identify which of the different possible dictionary meanings is most consistent with the use of the words by the inventor.Ferguson Beauregard/Logic Controls, Div. of Dover Resources, Inc. v. Mega Sys., LLC, 350 F.3d 1327, 1338 (Fed. Cir. 2003);see also Netword, LLC v. Centraal Corp., 242 F.3d 1347, 1352 (Fed. Cir. 2001) (claims are directed to invention described in specification; they have no meaning removed from context from which they arose); Toro, 199 F.3d at 1299 (words of ordinary usage must be construed in context of patent documents; court must determine how a person of experience in field of invention would, upon reading the patent documents, understand words used to define the invention); Renishaw, 158 F.3d at 1250 (interpretation to be given claim term can be determined and confirmed only with full understanding of what inventors actually invented and intended to envelop with claim). In addition, it may be necessary for the court to consider the use of the claim language and the patent applicant's statements in the patent's prosecution history, as the claims issue after an examination process. Toro, 199 F.3d at 1299.
In sum, if the patentee is not deemed to be the lexicographer, the court can determine the acquired meaning of the claim language only by ascertaining the acquired meaning of the term, and then testing this meaning against the particular use of the word in the patent and possibly against the particular use in the patent's prosecution history. Cortland Line Co., Inc. v. Orvis Co., Inc., 203 F.3d 1351, 1356-57 (Fed. Cir. 2000). While it is important that the court determine the context and usage of the words in the patent claims by examining the specification, the prior art, and other evidence (including dictionaries and treatises) showing the understanding of those skilled in the art, "a court must resist relying on any of these sources in a vacuum because they each influence the understanding of one of skill in the art at the time of invention." Alloc, 342 F.3d at 1368.
Here, each party claims that its proposed construction is consistent with the ordinary meaning of "appending." Dictionaries provide evidence of a term's "ordinary meaning." Texas Digital Sys., 308 F.3d at 1202. Such dictionaries include standard dictionaries of the English language, which in most cases will provide proper definitions, as well as technical dictionaries, encyclopedias, and treatises, which may be used for establishing specialized meanings in particular fields of art. Inverness Medical Switzerland GmbH v. Princeton Biomeditech Corp., 309 F.3d 1365, 1369 (Fed. Cir. 2002). IDNT contends that the ordinary meaning is the meaning set forth in a standard dictionary, citing the Merriam-Webster Collegiate Dictionary, which defines "appending" as "attaching." VeriSign asserts that the ordinary meaning is the meaning set forth in two technical dictionaries — Webopedia, an online dictionary that specializes in Internet terminology, and the Random House Webster's Computer and Internet Dictionary, both of which define "appending" as "adding to the end of" or "attaching to the end of."
IDNT also asserts, however, that there are other technical dictionaries that define "appending" as "attaching" without the limitation of "to the end of," such as the on-line Computer Hopes Computer Dictionary which defines "append" as "attach or combine," and the Webster's New World Dictionary of Computer Terms, which defines "append" as "add on."
A review of a range of both standard and technical dictionaries shows that "append" has multiple, though related, meanings. The "general-use" dictionaries consulted by the court define "append" as follows: (1) attach, affix; to add as a supplement or appendix (as in a book) (Merriam-Webster's Collegiate Dictionary (10th ed., 1999)); (Webster's II New Riverside University Dictionary (1988); Merriam-Webster Online (http://www.m-w.com)); 2) to hang on, to attach as a pendant; to attach, join on, annex, as an accessory either material or attributive; to add in writing by way of supplement or appendix (Oxford English Dictionary Online (http://dictionary.oed.com)); 3) add to the end of a document or a piece of writing (Compact Oxford English Dictionary (http://www.askoxford.com)); 4) to add extra information to something, especially to add extra information to a document; to add an authorized signature to a bill or official agreement; to attach something or fasten it to something else (MSN Encarta Online Dictionary (http://encarta.msn.com)); 5) to add something to the end of a piece of writing (Cambridge Dictionaries Online (http://dictionary.cambridge.org)); and 6) to add as a supplement or appendix; to fix to; attach (American Heritage Dictionary of the English Language (4th ed.) (http://www.bartleby.com)).
The court has also consulted a number of self-styled "computer" or "Internet" dictionaries, which provide the following definitions: 1) to add something to the end — for example, to append one file to another, or to append a file to a record; "append" always means to add at the end, while "insert" means to add in between (Webopedia (http://www.webopedia.com)); (Random House Webster's Computer and Internet Dictionary (3d ed. 2000)); 2) to add the contents or a list, or file, to those of another (Newton's Telecom Dictionary (17th ed. 2001)); 3) to attach or combine (Computer Hopes Computer Dictionary (http://www.computerhope.com)); 4) to add on, for example, to add new records to a data base or to add to the end of a character string or list (Webster's New World Dictionary of Computer Terms (3d ed. 1988); 5) state or say further; fix to, attach; add to the very end (HyperDictionary (http://www.hyperdictionary.com); and 6) to add to the end of an existing structure (TechEncyclopedia (http://www.techweb.com/encyclopedia).
Some computer/Internet dictionaries provide no definition for "append."
A review of all these definitions shows that "append" generally means "attach" in the sense of "add to the end of." One definition that appears repeatedly in the general-purpose dictionaries is "attach or add to a piece of writing," while the definition in several of the computer/Internet dictionaries is "attach or add to the end of a file [or list or data base or existing structure]." Nevertheless, where a term has more than one meaning when standing in isolation, the court must consider the use of the term in context. Inverness Med., 309 F.3d at 1370. VeriSign argues that its proposed construction is supported by the usage of the term in the specification, and is also supported by the prosecution history. VeriSign cites to two instances in the description of the preferred embodiments where "appending" is used to exemplify attaching something — such as a redirector string or one or more domain labels — at the end of something else — such as another domain label. VeriSign also notes that there is no instance in the `148 patent specification where "appending" refers to adding or attaching something to a position other than the end.
The first example is taken from an illustration of the translation process. It lists several steps, one of which is "[c]onstruct the final domain name by appending the redirector information to the FC1035-compliant domain name obtained above." Col. 7, lines 35-42. VeriSign notes that in this example, the redirector information ".ar.i18n.net" is added to the end of the initial string. The second example is the following:
The string "ar.i18n.net" is redirector information 130 that is appended to the converted string and functions like a top level domain, and identifies the authoritative domain name server responsible for the current domain name. Once the redirector information is appended to the domain name, the domain name becomes a fully qualified domain name (FQDN). A fully qualified domain name includes at least a top level domain and a secondary domain which is enough information to resolve the domain name.
Col. 7, lines 50-58. VeriSign asserts that, by definition, the redirector information or redirector string is added to the end of a domain name to make the domain name a fully qualified domain name. VeriSign claims that any other position of the redirector string with respect to the domain name to which it is attached would render the entire string useless for resolution.
IDNT responds, however, that VeriSign is improperly attempting to limit the meaning of "appending" by incorporating the preferred embodiments from the specification. IDNT contends that "it is fundamental that claims of a patent `are not limited by preferred embodiments.'" CVI/BETA Ventures, Inc. v. Tura LP, 112 F.3d 1146, 1158 (Fed. Cir. 1997). IDNT also argues that an accused infringer cannot "narrow a claim term's ordinary meaning . . . simply by pointing to the preferred embodiment." CSS Fitness, Inc. v. Brunswick Corp., 288 F.3d 1359, 1366 (Fed. Cir. 2002).
VeriSign also argues that its proposed construction is supported by the prosecution history, where the patent owner, in discussing the primary reference applied against the claims, notes that "the user is required to manually enter the suffix `i-DNS.apng.org' in order to point the request to the i-DNS Proxy server to properly resolve the request." VeriSign argues that it is clear from this i-DNS reference that "appending" means "adding something at the end," and asserts that the patent owner clearly understood that the term "append" is equivalent to a "suffix," something that is placed at the end of that which precedes it.
IDNT submits, however, that VeriSign's proposed construction conflicts with the way the word "appending" was used in the prosecution history. During prosecution, the patent application (Dr. Walid Tout) commented on the i-DNS reference as follows: "The [prior art] i-DNS publication teaches a system that requires the user to manually enter and append a predetermined suffix." IDNT contends that if "append" is construed as "attach to the end of," as VeriSign claims it should be, then the word "suffix" is superfluous in the quoted sentence.
The court is persuaded that VeriSign's proposed construction is the proper one. The term "append" does not convey any special technical meaning; however, its use is "technical" in the sense that it is used in conjunction with the term "redirector string," and in the sense that the person skilled in the art is a person familiar with Internet applications of computer programming or computer science. Thus, the definitions in the computer/Internet dictionaries are likely to more closely reflect the usage of "append" in the context of domain labels and character strings.
The court finds, moreover, that the term "appending" is not ambiguous, because the claims and the written description provide sufficient information to guide the court's interpretation of the term. See Renishaw, 158 F.3d at 1251-52. The examples in the specification — illustrating the "appending" of redirector information, or a redirector string, to a domain name — all indicate that "appending" means "attach to the end of." There is no indication anywhere in the specification of a system that would allow the redirector string to be attached to the front of, or to be inserted in the middle of, a domain name.
Nor is the court persuaded by IDNT's argument that the use of the word "suffix" in the prosecution history indicates that the concept "add to the end" cannot be considered part of "appending" because that concept is conveyed by "suffix. In the court's view, the word "suffix" in the quoted sentence is simply being used to underscore that "append" is being used in the sense of "attach to the end of" rather than in the sense of "attach somewhere."
C. VeriSign's Motion to Strike Declaration of Benjamin Goldberg
In support of its reply brief, IDNT submits a declaration from Benjamin Goldberg, its expert consultant. VeriSign seeks an order striking this declaration, on the ground that IDNT did not previously disclose Goldberg as an expert, and explicitly opted out of presenting testimony evidence in connection with the Markman hearing, so that VeriSign would not depose any such testifying witness. In the alternative, VeriSign requests leave to depose Goldman and to file a sur-reply brief. In addition, VeriSign argues that Goldberg should not be qualified as an expert witness under Federal Rule of Evidence 702
IDNT responds that Goldberg's declaration is not being presented as part of its claim construction argument, but rather that he is being presented as a "rebuttal witness," and that the Local Rules do not require the disclosure of rebuttal witnesses. VeriSign responds that Goldberg is plainly offering his opinion as part of IDNT's claim construction argument — specifically when he asserts that "one of ordinary skill in the art" would, based on the `148 patent specification and file history and when provided with appropriate rules or authoritative treatises, 1) understand that a redirector string need not include a top level domain name, 2) understand how the redirector string would be generated, and 3) understand the meaning of the term "delegation instructions."
Based on the information in Dr. Goldberg's CV, he appears well-qualified to testify as an expert in this area. However, IDNT has not presented any specific explanation of his qualifications, apart from the declaration and accompanying CV, plus a brief statement that Goldberg is a tenured professor in the Department of Computer Science at NYU, with educational and professional experience in the area of computer programming and networks.
With regard to whether he should be permitted to testify as a "rebuttal witness," the motion to strike is GRANTED. A retained expert who is testifying as to how "one of ordinary skill in the art" would interpret various terms (as, for example, "delegation instructions" — which is IDNT's proposed construction of the disputed term "redirector string") is in actuality testifying in support of that party's proposed construction of the disputed claim terms.
CONCLUSION
In accordance with the foregoing, the court finds that the term "redirector string" means " a single domain label or two or more contiguous domain labels, including a top level domain that was not part of the originally-entered domain name, which identify the domain name server responsible for resolving the transformed compliant domain name." The term "appending" means " attaching to the end of."
IT IS SO ORDERED.