AKAMAI TECHNOLOGIES, INC., et al.
v.
LIMELIGHT NETWORKS, INC.
Civil Action No. 06-11109-RWZ.
United States District Court, D. Massachusetts.
June 29, 2007.*35 *36 *37 *38 Carlos J. Perez-Albuerne, Richard C. Abati, Robert S. Frank, Jr., Sarah C. Columbia, G. Mark Edgarton, Stacy L. Blasberg, Choate, Hall & Stewart, Boston, MA, for Akamai Technologies, Inc., et al.
Alexander F. MacKinnon, David Shukan, Marc H. Cohen, Nick Saros, Robert G. Krupka, Timothy G. Majors, Kirkland & Ellis LLP, Los Angeles, CA, Jeffrey T. Hsu, Heller Ehrman LLP, Washington, DC, Michael P. Wickey, Nishita A. Doshi, Robert T. Haslam, III, Stanley Young, Heller Ehrman LLP, Menlo Park, CA, Robert D. Fram, Heller Ehrman LLP, San Francisco, CA, Daniel K. Hampton, Holland & Knight LLP, Boston, MA, Gael Mahony, Holland & Knight, LLP, Providence, RI, for Limelight Networkst.
ORDER REGARDING CLAIM CONSTRUCTION
ZOBEL, District Judge.
I. Introduction
Plaintiffs Akamai Technologies, Inc. and the Massachusetts Institute of Technology (collectively "Akamai") allege that defendant Limelight Networks, Inc. ("Limelight") has infringed (1) United States Patent No. 6,108,703 ("the `703 Patent"), a "Global Hosting System;" (2) United States Patent No. 6,553,413 ("the `413 Patent"), a "Content Delivery Network Using Edge-of-Network Servers for Providing Content Delivery to a Set of Participating Content Providers;" and (3) United States Patent No. 7,103,645 ("the '645 Patent"), a "Method and System for Providing Content Delivery to a Set of Participating Content Providers" (collectively, the "Akamai Patents"). The three patents share a common specification; only the claims differ between them. The common Abstract describes the invention as an "inventive framework" that "allows a Content Provider to replicate and serve its most popular content at an unlimited number of points throughout the world." (Akamai Patents, Abstract.) The parties dispute the construction of a total of seventeen claim terms from the three patents.
II. Legal Standard
The construction of patent claims is a matter of law for this court to decide. Markman v. Westview Instruments, Inc., 517 U.S. 370, 372, 116 S. Ct. 1384, 134 L. Ed. 2d 577 (1996). "[T]he words of a claim are generally given their ordinary and customary meaning," in other words, "the meaning that the term would have to a person of ordinary skill in the art in question at the time of the invention, i.e., as of the effective filing date of the patent application." Phillips v. AWH Corp., 415 F.3d 1303, 1312-13 (Fed.Cir.2005) (internal citations omitted); see also Markman v. Westview Instruments, Inc., 52 F.3d 967, 985 (Fed.Cir.1995) (en banc), aff'd, 517 U.S. 370, 116 S. Ct. 1384, 134 L. Ed. 2d 577 (1996) (describing the focus in construing disputed terms as applying an objective test of the term's meaning to "one of ordinary skill in the art at the time" and not a consideration of the subjective intent of the parties creating the patent contract). However, the presumption that words are given their ordinary meaning may be overcome if the patent specification or prosecution history "clearly and deliberately set[s] forth" a different meaning. K-2 Corp. v. Salomon S.A., 191 F.3d 1356, 1363 (Fed. Cir.1999).
The scope and meaning of a patent's claims must be ascertained in the context of the specification and the prosecution *39 history. Phillips, 415 F.3d at 1315. While limitations from the specification should not be read into the claims, a patent is a "fully integrated written document" and the "claims must be read in view of the specification, of which they are a part." Markman, 52 F.3d at 978-79; see also Gentry Gallery, Inc. v. Berkline Corp., 134 F.3d 1473, 1480 (Fed.Cir.1998) ("claims may be no broader than the supporting disclosure, and therefore [] a narrow disclosure will limit claim breadth").
The Federal Circuit has refused to endorse a bright-line rule limiting the scope of the claims to the embodiment disclosed when only a single embodiment is described in the specification. See Teleflex, Inc. v. Ficosa N. Am. Corp., 299 F.3d 1313, 1326 (Fed.Cir.2002). However, "when the preferred embodiment is described in the specification as the invention itself, the claims are not necessarily entitled to a scope broader than that embodiment." Modine Mfg. Co. v. United States Int'l Trade Comm'n, 75 F.3d 1545, 1551 (Fed.Cir.1996), abrogated on other grounds, Festo Corp. v. Shoketsu Kinzoku Kogyo Kabushiki Co., Ltd., 234 F.3d 558 (Fed.Cir.2000) (en banc); see also Microsoft Corp. v. Multi-Tech Systems, Inc., 357 F.3d 1340, 1348 (Fed.Cir.2004) ("In light of those clear statements in the specification that the invention (the present system') is directed to communications `over a standard telephone line,' we cannot read the claims of [the patents at issue] to encompass data transmission over a packet-switched network. . . ."). In addition, statements in the "Summary of the Invention" portion of the specification "are not limited to describing a preferred embodiment, but more broadly describe the overall inventions of [the] patents." Multi Tech Systems, 357 F.3d at 1348.
III. Claim Construction and Discussion
Having considered in light of the applicable legal standard the parties' written submissions as well as the argument of counsel at a hearing held on May 17, 2007, the court construes the disputed claim terms as follows:
A. '645 Patent Terms in Dispute
1. Term 1 ('645 Patent, Claim 1)
Term Court's Construction
... a given object of a participating ... a particular object of a
content provider participating content provider
is associated with an alphanumeric is associated with an
string ... string that
includes the URL used to
identify the object in the
absence of a content delivery
network ...
Akamai's suggestion that the term "associated" be given its dictionary meaning[1] ignores the Federal Circuit's warning in Phillips that "[t]he risk of systematic overbreadth is greatly reduced if the court [] focuses at the outset on how the patentee used the claim term in the claims, specification, and prosecution history, rather than starting with a broad definition and whittling it down." Phillips, 415 F.3d at 1321. The `645 Patent specification describes as the present invention a single embodiment in which the Uniform Resource Locator ("URL") used to retrieve an embedded object from the content provider's server(s) in the absence of a content delivery network is modified by prepending it with a virtual server host-name:
"According to the present invention, a given Web page (comprising a base HTML document and a set of embedded objects) is served in a distributed manner. . . . To serve the page contents in *40 this manner, the URL associated with an embedded object is modified. As is well known, each embedded object that may be served in a page has its own URL. . . . According to the invention, the embedded object URL is first modified, preferably in an off-line process, to condition the URL to be served by the global hosting servers[2]. . . . Thus, according to the present invention, a virtual server hostname is prepended into the URL for a given embedded object. . . . "
('645 Patent, col.6 1.35-col.7 1.40 (emphasis added).)
The specification then continues on to describe "the inventive global framework" in the context of a specific example. (Id. col.7 ll.50-53 (emphasis added).) At step 5 of the example, a copy of the object is retrieved from a content delivery provider ("ghost") server. The specification goes on to explain:
Step 6: If, however, no copy of the data on the ghost exists, a copy is retrieved from the original server or another ghost server. Note that the ghost knows who the original server was because the name was encoded into the URL that was passed to the ghost from the browser.
(Id. col. 12 ll.54-58 (emphasis added).) Here, the specification describes the invention as associating a particular object of a content provider with an alphanumeric string consisting of a virtual server hostname prepended onto the URL for the object. The URL of the object is necessary to the inventive global framework in order to retrieve the object from the content provider's server if no copy exists on a ghost server. The specification discloses no other way that an object is associated with an alphanumeric string, nor is there any suggestion or teaching that an association which did not include the URL for the embedded object could be used in an embodiment of the invention. Therefore, Akamai's proposed construction is overly broad and the court declines to adopt it. Rather, the court adopts a construction that incorporates the association described in the specification as "the . . . invention." (Id. col.7 ll.36-40.)[3]
2. Term 1 ('645 Patent, Claim 1)
Term Court's Construction
... an alternative domain ... a domain name system,
name system (DNS), distinct separate from the Internet
from the Internet domain DNS and the client's name
name system and any server, that is controlled by
client local name server... a content delivery network
service provider and includes
control routines that
are different from regular
name servers ...
*41 Both parties' proposed claim construction for Term 2 are deficient. Akamai's proposal essentially reads out the limitations in the claim requiring the DNS established by the service provider to be "alternative" and "distinct," while Limelight's proposed construction does not read on the preferred embodiment.
The Brief Summary of the Invention describes the "object of the present invention" as "provid[ing] a network architecture that moves content closer to the user." ('645 Patent, col.2 ll.49-50.) This is accomplished by "replicating content over a large network of distributed servers." (Id. col.2 ll.46-47.) The task of determining which of this multiplicity of servers should supply content to a particular user's request is handled by the alternate and distinct DNS system:
The determination of which hosting server to use to serve a given embedded object is effected by other resources in the hosting framework. In particular, the framework includes a second set of servers (or server resources) that are configured to provide top level Domain Name Service (DNS). In addition, the framework also includes a third set of servers (or server resources) that are configured to provide low level DNS functionality.[4]
To locate the appropriate hosting servers to use, the top-level DNS server determines the user's location in the network to identify a given low-level DNS server to respond to the request for the embedded object. The top-level DNS server then redirects the request to the identified low-level DNS server that, in turn, resolves the request into an IP address for the given hosting server that serves the object back to the client.
(Id. col.3 ll.29-36, 42-49 (Summary of the Invention) (emphasis added).) The specification emphasizes the difference between the invention and the operation of "regular DNS servers" which return the Internet Protocol ("IP") addresses of one or more DNS or content servers without any consideration of where the user or the server is located:
[T]he global hosting architecture of the present invention manipulates the DNS system so that the name is resolved to one of the ghosts that is near the client and is likely to have the page already. . . . The top level DNS servers [for the inventive global hosting framework] have a special function that is different from regular DNS servers like those of the .com domain. The top level DNS servers include appropriate control routines that are used to determine where in the network a user is located, and then to direct the user to . . . a low level DNS[] server that is close-by.
(Id. col.9 ll.40-44, 49-55 (emphasis added).) Akamai confirmed the character of this alternative, distinct DNS at the Markman hearing:
. . . the Domain Name System described in the patent is, one, something that is established by, set up by, run by the content delivery network. And, second, it is different in that it has intelligence that will direct that will inform the translation of character strings into IP addresses.[5]*42 (Hr'g Tr., 59:10-15, May 17, 2007 (emphasis added).) Thus, read in the context of the specification, the meaning of "distinct" and "alternative" describes a domain name system established and controlled by a content delivery network service provider, which includes control routines "different from regular DNS servers like those of the .com domain." ('645 Patent, col.9 ll.50-51.)
3. Term 1 ('645 Patent, Claim 1)[6]
Term Court's Construction
... the given name server ... the particular name
that receives the DNS server that receives the
query being close to the DNS query is selected by
client local name server as the alternative domain
determined by given location name system and is close in
information ... Internet terms to the client
local name server ...
The parties' first disagreement concerns whether "close" refers to geographic distance or Internet distance.[7] While Limelight argues that the specification only intends to specify Internet distance where explicitly stated, the language of the specification supports the concept of Internet distance generally where it refers to distance.[8] For example, the Brief Summary of the Invention describes an object of the invention as "to serve Web content efficiently, effectively, and reliably to end users" by "provid[ing] a network architecture that moves content close to the user" to avoid having to "build[] a massive infrastructure to handle the associated traffic." (Id. col.2 ll.41-42, 49-53 (emphasis added).) "Close," read in this context, refers to Internet distance. In addition, the description of the preferred embodiment generally references the network or network delays in its measure of distance:
Several factors may determine where the hosting servers are placed in the network. . . . By studying [network] traffic patterns, the ISP may optimize the server locations for the given traffic profiles." (Id. col.6 ll.28-34 (emphasis added).)
"[A]ppropriate control routines [are used to determine where in the network the user is located, and then to direct the user to a . . . server that is close-by." (Id. col.9 ll.51-54 (emphasis added).)
"Thus, a given top-level DNS server directs the user to a region of the Internet. . . ." (Id. col.9 ll.57-59 (emphasis added).)
After determining where in the network the request originated, the top level DNS server redirects the DNS request to a low level DNS server close to the user in the network. (Id. col.10 ll.28-30 (emphasis added).)
*43 In general, the clients are directed to regions in a way that minimizes the overall latency experienced by clients subject to the constraint that no region becomes overloaded.[9] (Id. col. 10 ll.64-67 (emphasis added).)
While Limelight is correct that none of these descriptions explicitly states that closeness refers to Internet distance, it is implied by the emphasized text. (Cf. id. col. 10 ll.9-11 ("[T]he routines make the assumption that the user is located near (in the Internet sense) this server.").)
The second issue concerns whether there is any limitation on how this closeness is determined. Akamai argues that the words of the claim do not limit the determination of closeness, while Limelight asserts that it must be determined by the alternative domain name system. For the reason discussed supra, Term 1, I believe Limelight has the better argument. The specification describes "the present invention" as "manipulat[ing] the DNS system so the name is resolved to one of the ghosts that is near the client ." (Id. col.9 ll.42-44 (emphasis added); see also id. col.3 ll.42-44 (Brief Summary of the Invention) ("[T]he top-level DNS server determines the user's location in the network. . . . . ").) As discussed supra, Term 2, the purpose of establishing "an alternative domain name system (DNS), distinct from the Internet domain name system" is to run "appropriate control routines" to "determine where in the network a user is located." (Id. Claim 1; id. col.9 ll.52-53.) Read in light of the specification, the invention claims an alternate DNS system that selects a DNS server in response to a user request based on the location of the user.
4. Term 1 ('645 Patent, Claim 1)
Term Court's Construction
... the alphanumeric string ... the alphanumeric string
is resolved without reference is translated into an IP address
to a filename for the without reference to
given object... the name of the object ...
The parties do not appear to disagree n the explicit limitation in this term requiring resolution of the string without regard to the object name. Limelight, however, argues that the term should be further limited to require the name resolution to resolve to the "Internet Protocol address of the optimal content server." (See Docket # 71, 26.) Reading the contested term in light of the rest of the claim demonstrates that the claim itself provides explicit limitations on string resolution. Claim 1 requires that the IP address returned by the contested term be associated with one of the content servers associated with the "close" DNS server selected in the previous step, and also that the content server be selected according to a load-sharing algorithm. ('645 Patent, Claim 1.) The word "optimal" does not appear in the specification (or the claims) of the '645 Patent, and adding it as a limitation, where the claim step itself limits the result of the string resolution, would muddy, rather than clarify, an understanding of the claim step.
4. Term 1 ('645 Patent, Claim 1)
Term Court's Construction
... being selected by a procedure ... being selected according
that distributes requests to a load sharing algorithm
for objects among a enforced across the
group of content servers in subset of the set of content
a content delivery network servers associated with the
associated with the particular given name server ...
name server to avoid
overloading any single content
server ...
*44 The conflict between the parties arises over the meaning of the words "load sharing." Limelight seeks to limit this term to an active, real-time algorithm which allocates server requests in order to "even out transient load peaks." (See Docket # 71, 29.) Akamai attempts to distinguish between load sharing and load balancing, arguing the former is broader and encompasses both the latter, which they argue is active, as well as "other load distribution methods." (Docket # 68, 24.) The specification does not explicitly define (or use) the term "load sharing," and, as Akamai points out, prior art references "do[] not establish the meaning of these terms to a person of ordinary skill in the art" because they "contain directly conflicting descriptions." (Docket # 81 Ex. A, 18.)
The specification uses the term "load balancing" to describe a two-step process to allocate requests for objects to various content servers in order to distribute the load; a pre-processing step that allocates objects randomly across potentially available servers, followed by the active instrumentation and adjustment of actual server loads:
According to the present invention, load balancing across the set of hosting servers is achieved in part through a novel technique for distributing the embedded object requests. In particular, each embedded object URL is preferably modified by prepending a virtual server hostname into the URL. . . . This function serves to randomly distribute the embedded objects over a given set of virtual server hostnames . . .
According to the invention, the virtual ghost names may be hashed into real ghost addresses using a table lookup, where the table is continually updated based on network conditions and traffic in such a way to insure load balancing and fault tolerance. . . . The low-level DNS servers monitor the various ghost servers to take into account their loads while translating virtual ghost names into real addresses. This is handled by a software routine that runs on the ghosts and on the low level DNS servers.
('645 Patent, col.4 ll.13-24, col.11 ll.23-27, 53-57 (emphasis added) (describing the preprocessing of embedded object alphanumeric strings to randomly distribute object requests across a set of virtual servers, followed by an active step which translates virtual server hostnames into real server IP addresses to avoid overloading any single server).) The specification describes the goal of load sharing not as evening out transient load peaks, but as distributing object requests among a set of servers so that "no server becomes overloaded." (Id. col. ll 1.67; accord id. col. 11 ll.7-10 ("The local DNS server is responsible for returning the IP address of one of the ghost servers on the network that is close to the user, not overloaded, and most likely to already have the required data.").) Given the lack of clarity in the prior art and the lack of an explicit definition of load sharing in the specification, a limitation requiring that the load sharing algorithm avoid overloading the content servers comports with the understanding of a person of ordinary skill in the art's reading of the patent. Phillips v. AWH Corp., 415 F.3d 1303, 1313 (Fed.Cir.2005) ("[T]he person of ordinary skill in the art is deemed to read the claim term not only in the context of the particular claim in which the disputed term appears, but in the context of the entire patent, including the specification.").
B. '645 Patent Terms in Dispute
1. Term 7 ('413 Patent, Claim 8, 18,
20)
*45
Term Court's Construction
... responsive to a DNS ... in response to a DNS
query, selecting a given one query, the content delivery
of the name servers in the network's domain name
content delivery network system selects a particular
... [claims 8, 18] name server ...
... responsive to a DNS ... in response to a DNS
query received from a query received from a
client local name client local name server,
server, selecting a given in work's domain name system
one of the name servers in the content delivery network
the content delivery network selects a particular
... [claim 20] name server ...
The crux of the disagreement between the parties here is whether the selection of the particular name server is a result of a DNS lookup, or whether the claim covers any method which results in the selection of a particular name server in response to a DNS query. Limelight argues that there is no support in the specification for any method of choosing a particular name server other than by a DNS lookup. The Brief Summary of the Invention describes the "hosting framework" as including two sets of DNS servers. ('413 Patent, col. 3 ll.27-32.) "To locate the appropriate hosting servers to use, the top-level DNS server determines the user's location in the network to identify a given low-level DNS server to respond to the request for the embedded object." (Id. col.3 ll.37-41.) In Limelight's view, this requires the invention's domain name system to choose the second-level name server.
Akamai counters that, under Limelight's proposed construction, if the particular name server is selected by a first DNS lookup, the particular name server chosen must therefore be a member of a second DNS level. This, they assert, is in conflict with language earlier in each of the three claims describing the content provider's domain name system as "having one or more DNS levels ." ('413 Patent, Claim 1 (emphasis added).) In addition, they point to other claims that explicitly require a two-level DNS system as evidence that the patent differentiates between claims that require a two-level DNS, implementation and claims that do not. Therefore, Akamai argues for a broad, dictionary definition of "selecting" as "making a choice." (Docket # 68, 28.)
The error in Akamai's argument is that limiting the selection of a particular name server to the DNS lookup does not necessitate two DNS levels from the client's perspective. While the embodiment describes a global hosting system containing a two-level DNS system, it notes that "the functionality of the top and low-level servers" may be combined in "a single DNS level." ('413 Patent, col.5 ll.59-65 (emphasis added).) Thus, the specification supports language claiming a single-level DNS system, but with the requirement that it accomplish the same steps as the described embodiment. For example, in the described embodiment, the top-level DNS server selects a low-level name server and "[re]direct[s] the user to a . . . low-level DNS [server that is close-by [the user]." (Id. col.9 ll.49-50.) The user's local name server then makes a second DNS request to this second level of DNS to obtain the object's IP address.[10]
In a single-level DNS embodiment, as suggested by the specification, the user's local name server would still contact a content delivery provider's top-level name server to resolve the IP address of a server to serve an object. This name server, however, would then directly communicate *46 with a particular local name server, based on the user's location, to resolve the server's IP address and return it to the user, rather than require the user to conduct a second lookup. Thus, the user would obtain the IP address of the appropriate ghost server with only a single DNS request, however the selection of a particular name server would still be the result of a DNS lookup by the service provider's DNS system. Such an embodiment would satisfy the claimed "one" level of DNS, yet not be in conflict with Limelight's proposed claim construction.
However, Limelight's proposed requirement that "the content delivery network service provider conducts a DNS lookup to select a single specific name server" is excessively limiting. (Docket # 71, 23.) Each of the three claims containing the term to be construed requires a "content delivery network service provider" to establish a "domain name system (DNS) having authority to resolve the alphanumeric strings in the URLs of the objects identified by the participating content providers" having "one or more DNS levels." ('413 Patent, Claims 8, 18, 20.) As discussed supra, Term 2, the service provider's domain name system includes "special function[s] that [are] different from regular. DNS servers like those of the .com domain" and "appropriate control routines" to select a particular name server. (Id. col.9 ll.44-50.) Read in this light, the selection of a particular name server is made by these special functions in the DNS system in response to a DNS query, but not necessarily by a DNS lookup.[11] The construction adopted by the court reflects this broader understanding of the term in dispute.
2. Term 9 ('413 Patent, Claim 8, 18,
20)
Term Court's Construction
... the alphanumeric string ... the alphanumeric string
is resolved without reference is translated into an IP address
to a filename for the without reference to
given object ... the name of the object ...
This term to be construed in the '413 Patent is identical to Term 5, supra, in the '645 Patent. Limelight argues that a limitation of an "optimal content server" should be read into these claims. (See Docket # 71, 26.) Again, the remainder of the claim or subsequent dependent claims provide explicit limitations on the string resolution, so the addition of the undefined term, "optimal," is unnecessary. See supra, Term 5.
C. '703 Patent Terms in Dispute
1 Term 10 ('413 Patent, Claim 5,)[12]
Term Court's Construction
... a routine for modifying ... a procedure for modifying
at least one embedded object a Uniform Resource
URL of a web page Locator for an object embedded
... in a page that is
accessible in or through the
World Wide Web ...
Akamai objects to Limelight's construction that limits "a routine" to a computer program or other automated process. Rather, Akamai argues for a definition of "a routine" as "a procedure" or a "series of steps" that could be performed by either humans or machines. (Docket #81 Ex. A, 23.)
The specification uses the terms "routine," "process" and "method" to describe the modification of object URLs. In the preferred embodiment, the embedded object URL is "first modified, preferably in *47 an off-line process, to condition the URL to be served by the global hosting servers." ('703 Patent, col.6 ll.40-44 (emphasis added).) The flowchart "illustrating the preferred method for modifying the object URL" is described and referred to as "[t]he routine." (Id. col.6 ll.44-47 (emphasis added).)[13]
Limelight asserts that in an earlier case claiming infringement of the same patent, Akamai limited the same term to a computer program. (Docket # 71, 38 (citing Akamai Techs., Inc. v. Digital Island, Inc. (No. 00-cv-11851-RWZ), Trial Exhibit 96).) In that case, Akamai argued "[a] `routine' has its ordinary meaning of a set of instructions, e.g. a computer program or process." (Id.) "E.g.," however, denotes an example and is therefore not limiting.[14]
While the hash value calculations described in the preferred embodiment would be difficult to calculate manually, simpler embodiments might be more amenable to hand calculation. For example, the specification describes an alternate method for modifying the object URL with a serial number which contains information about the object. ('703 Patent, col.6 1.65-col.7 1.29.) Therefore, there is insufficient support in the specification to limit the "routine" which modifies object URLs solely to automated or computer programs.
2 Term 11 ('703 Patent, Claim 5,)
Term Court's Construction
... modifying a URL for ... modifying a Uniform
the page object ... Resource Locator for an
object embedded in a page
...
Limelight similarly seeks to limit this term to "a computer program that modifies an existing Uniform Resource Locator of an embedded object of a web page." (Docket # 71, 36.) This construction fails not only for the reasons discussed supra, Term 10, but also because claim 15 is a method claim and Limelight's proposed construction describes a product claim limitation.
3. Term 12 ('703 Patent, Claim 5,
15)[15]
Term Court's Construction
... hostname ... a name or other identifier
that can be translated
by a client machine's local
DNS server into the IP
address of a content server
...
These two patent claims describe prepending a hostname to the URL for an embedded web page object. ('703 Patent, Claims 5, 15.) As described in the remaining steps of claim 15, in response "to a browser query to resolve the hostname," the IP address of a particular one of the "set of content servers distinct from the content provider server" is returned to the client's browser. (Id. Claim 15; accord id. Claim 5.) Thus, the hostname identifies a server on the Internet which the client's DNS server can resolve into an IP address so his or her browser can fetch the object. (See id. col.9 ll.20-28.) The court's construction *48 strikes a balance between Akamai's broad proposed construction and Limelight's narrow one, opting instead to include the functional limitations described in the claims rather than one specific to the current Internet name resolution system.
4. Term 13 ('703 Patent, Claim 5,
15)[16]
Term Court's Construction
... domian name and path ... a name or other identifier
... that defines a network
connection to the embedded
object at a content provider
server and is used to retrieve
the object in the absence
of a content delivery
network ...
Akamai describes the domain name portion of a URL as "an expression that identifies the content provider's servers." (Docket # 81 Ex. A, 26.) This is broader than the normal use of the term to describe the address of a particular host or server that can be resolved to establish a network connection with that server.[17] (Cf. Akamai Technologies, Inc. Tutorial Corrected Version) (Docket # 84), 20 ("The first portion of a URL relates to the computer or a group of computers on which a resource may be located. This is the portion of the URL that is resolved by a domain name service to an IP address."). There is nothing in the specification or claims to indicate that the term is being redefined by the patent to be broader than its normal usage. At the Markman hearing, Akamai conceded that the domain name "has to be something recognized by the Domain Name System. . . ." (Hr'g Tr., 187:25-188:3, May 17, 2007.)
The path contains the name and location of the file, e.g., the object, on the server. (Docket # 81 Ex. A, 26.) Together, the domain name and path form the URL which provides a client computer with the information necessary to identify the server and retrieve the object from that server on the network. Both claims describe "modifying" the URL of an embedded object and claim 15 describes the domain name and path as "content provider-supplied." ('703 Patent, Claims 5, 15 (emphasis added).) Read in light of the specification explaining that "according to the present invention, a virtual server hostname is prepended into the URL for a given embedded object," the terms domain name and path in claims 5 and 15 would be understood by one skilled in the art to refer to the URL used to retrieve the embedded object in the absence of a content delivery, network. (Id. col.7 ll.24-28 (emphasis added).)
5. Term 14 and 15 ('703 Patent,
Claim 5)[18]
Term Court's Construction
... at least one first level ... a computer or program
name server that provides a running on a computer in
first level domain name service the hosting framework that
(DNS) resolution ... receives a request to resolve
[Term 14] a name or other identifier
into an IP address,
and returns the IP address
*49
of a name server or servers
...
... and at least one second ... a computer or program
level name server that provides running on a computer in
a second level domain the hosting framework that
name service (DNS) resolution receives a request to resolve
... [Term 15] a name or other identifier
into an IP address,
and returns the IP address
of a content server or
servers ...
Akamai argues that a proper construction of these terms should include the regular Internet DNS root[19] and top-level (e.g. ".com") name servers, while Limelight insists that the patent limits the invention to name servers within the "distributed hosting framework" cited in the claim preamble. ('703 Patent, Claim 1.) Akamai bases its argument on an appellate decision in a prior case, Akamai Techs. v. Cable & Wireless Internet Servs., 344 F.3d 1186 (Fed.Cir.2003) ("C & W"). Akamai, however, misreads that decision. The issue addressed by the Federal Circuit in C & W was "a single point of contention the placement of the load balancing software at either the DNS servers or the origin server." Id. at 1193. The court found that claim 1 of the '703 Patent did not require the load balancing software to be located at the DNS server, and therefore was anticipated by an earlier C & W patent. Id. at 1194.
In attempting to save claim 3, which added only a redundant second-level name server to the limitations of claim 1, Akamai argued that the earlier patent did not disclose a hierarchical DNS. Id. The Federal Circuit considered this argument but concluded:
This additional argument, however, fails to address C & W's contention that hierarchical DNS is inherent in any Internet system. Indeed, C & W proffered documentary evidence and testimony at trial that redundant domain name servers are inherent in any Internet-based application. See Dayco, 329 F.3d at 1369.
Id. at 1195 (emphasis added). Contrary to Akamai's contention, this language does not construe the terms of claim 1 concerning limitations on the location of the claimed name servers. Indeed, the Federal Circuit had no reason to examine claim 1 further, having already determined it invalid. Rather, it holds that, given an invalid claim 1 anticipated by an earlier patent, the additional limitation of a redundant name server in claim 3 does not sufficiently limit claim 1 to create a valid claim.
A plain reading of claim 1 in the '703 Patent describes the two-level DNS service as part of "[a] distributed hosting framework operative in a computer network . . . the framework comprising: . . . at least one first level name server . . . and at least one second level name server. . . ." ('703 Patent, Claim 1.) The specification supports a construction of this language that limits the location of the name servers to the claimed invention's hosting framework:
The hosting framework of the present invention comprises a set of servers operating in a distributed manner. . . . In particular, the framework includes a second set of servers (or server resources) that are configured to provide top level Domain Name Service (DNS). In addition, the framework also includes a third set of servers (or server resources) that are configured to provide low level DNS functionality. (Id. col.3 *50 ll.4-5, 19-24 (Summary of the Invention) (emphasis added).)
[T]he global hosting system 35 comprises three (3) basic types of servers (or server resources): hosting servers (sometimes called ghosts) 36, top-level DNS servers 38, and low-level DNS servers 40. (Id. col.3 ll.51-54 (Summary of the Invention) (emphasis added).) Step 3: As previously described, preferably there are two types of DNS servers in the inventive system: top-level and low-level. The top level DNS servers 38 for ghosting.com have a special function that is different from regular DNS servers like those of the .com domain. (Id. col.9 ll.31-35 (emphasis added) (distinguishing the DNS servers in the inventive framework from those of the Internet root and top-level servers).)
Thus, both the claim and the specification limit the invention to a global framework containing two levels of DNS servers different from the DNS servers providing root and top-level name resolution.
Term 16 and 17 ('703 Patent,
Claim 5, 15, 19, 34)[20]
Term Court's Construction
... given one of the content ... a particular one of the
servers ... [Claims 5, content servers distinct
34] from the content provider
server described previously
... given one of the set of in the claim ...
content servers ... [Claim
15]
... given content server
... [Claim 19]
The parties both agree that a single construction is sufficient for all three claims terms.[21] Limelight seeks to add the limitation that the given content server be "a single, optimal content server." (Docket # 71, 50.) In claim 5, the contested term appears in a limitation of claim 1 requiring "the embedded object [to be] served from a given one of the content servers as identified by the first level and second level name servers." ('703 Patent, Claim 1; accord id. Claim 15.) In C & W, the Federal Circuit refused to read any requirement for a load balancing mechanism into the word "identified" in this claim. C & W, 344 F.3d at 1193-94 ("[The plain meaning of the claim language] simply requires the embedded object to be served from the content servers as identified by the first level and second level name servers.'"). Similarly, it would be inappropriate to read a requirement for an "optimal" server into it as well.
Additional language in claim 34 limits the "given one of the content servers" to a server which is "within the given region that is likely to host the embedded object and that is not overloaded." ('703 Patent, Claim 34.) As discussed supra, Term 5, adding a requirement that the server be "optimal" is unnecessary and confusing, as the claim already provides a specific limitation, consistent with the specification, as to which content server's IP address should be returned to the client. Similarly, while independent claim 19 provides no particular limitations on which given content server serves the embedded object, subsequent dependent claims 20 through 22 limit the server selected in ways that would be redundant with Limelight's construction.
Akamai's proposed construction, however, reads out the word "given" from the *51 claims. It is appropriate to construe the term as a referring to a "particular" server, to make clear that a selection is made.
7. Term 18 ('703 Patent, Claim 5,)
Term Court's Construction
... the second level name ... a mechanism in the second
server includes a load balancing level name server monitors
mechanism that balances the loads on a group
loads across a subset of content servers in a content
of the set of servers. delivery network and
distributes requests for objects
among them to avoid
overloading any single content
server.
As discussed supra, Term 6, the specification uses the term "load balancing" to describe a two-step process to allocate requests to various servers in order to distribute the load, a preprocessing step on embedded object alphanumeric strings to randomly distribute object requests across a set of virtual servers, followed by an active step which translates virtual server hostnames into real server IP addresses to avoid overloading any single server. (See id. col.3 l.66-col.4 l.4, col.11 ll.6-10, 35-39.) This second step includes active instrumentation and adjustment of server loads. (Id.) Limelight seeks to have this limitation included in the claim construction. (See Docket # 71, 29.) Akamai concedes that load balancing "requires something more than load sharing." (Docket # 81 Ex. A, 31.) Given the construction of load sharing adopted by the court in Term 6, the court construes the "something more" in load balancing to be the additional limitation of actively monitoring the loading on the content servers.
8. Term 19 ('703 Patent, Claim 17,)
Term Court's Construction
... prepending given data ... generating an alternative
to a content provider-supalternate resource locator (ARL)
plied URL to generate an by adding a name or other
alternate resource locator identifier that can be translated
(ARL)... by a domain name
system into the IP address
of a content server to the
beginning of the URL of an
embedded object supplied
by a content provider ...
Claim 17 describes several steps comprising a "content delivery method" which, inter alia, requires modifying the URL of an embedded object to generate an alternative resource locator ("ARL"). ('703 Patent, Claim 17.) This ARL is then "resolv[ed] to identify a content server in [a domain other than a content provider's] domain." (Id.) Thus, the language of the remaining steps in the claim limits "given data" to a string resolvable to the address of a content server in the content delivery system.
NOTES
[1] (See Akamai's Claim Construction Mem. (Docket # 67) at 9 (citing the definition of associated" from Merriam-Webster's Collegiate Dictionary).)
[2] The '645 Patent specification uses the terms "ghost," "ghost server" and "hosting server" interchangeably to describe the service provider's servers which replicate and deliver a participating content provider's content to the user. (See '645 Patent, col.5 ll.65-67.) The claims, however, use the term "content server(s)," a term which does not appear in the specification, to describe these servers. (See, e.g., '645 Patent, Claim 1 (claiming "a method of content delivery wherein participating con:: tent providers identify content to be delivered by a service provider from a set of content servers that are distinct from the participating content provider sites and associated with the service provider").) The court construes "ghost(s)," "ghost server(s)," and "hosting server(s)" to refer to "content server(s) distinct from the content provider server(s)."
[3] Limelight's proposed construction requiring the alphanumeric string to include "the domain name conventionally used . . . to identify the object," is excessively limiting. (See Docket # 90, 1.) Neither the specification nor the claim requires the domain name to be a part of `the object URL. (See '645 Patent, col.6 ll.51-54 ("Typically, the URL has a hostname identifying the Content Provider's site from where the object is conventionally served. . . .") (emphasis added).)
[4] The first set of servers are the framework's hosting servers (also referred to as ghost servers or ghosts). (See '645 Patent, col.5 ll.65-67.)
[5] In addition to the intelligence in the top-level DNS servers that determines the location of the user and chooses `a particular close-by low-level DNS server to service that user, the specification also describes intelligence in the low-level DNS servers, not present in regular DNS servers, which provides other claimed functionality. (See '645 Patent, col. 11 ll.53-55 ("The low-level DNS servers monitor the various ghost servers to take into account their loads while translating virtual ghost names into real addresses.") (emphasis added).)
[6] The parties reached an agreement as to the construction of several contested terms prior to the Markman hearing and agreed that one other did not require immediate construction. Therefore, Terms 3, 8 and 20 are not addressed by the court here.
[7] A particular DNS or content server may be closer to a user in geographic terms, but delays in routing or high-traffic conditions along a particular route may mean that information can be obtained in less time from a server that is physically located farther away.
[8] The exception to the general reference to Internet distance in the specification occurs in the Brief Summary of the Invention which asserts "[a]s an additional feature [of the inventive framework], the actual content that is replicated at any one geographic location is specifically tailored to viewers in that location." ('645 Patent, col.3 ll.7-9.) However, it does not appear that this particular benefit of the invention is claimed in the '645 Patent. (See also id. col.10 ll.11-16 ("Alternatively, the user's location or IP address could be directly encoded into the request sent to the top level DNS.").)
[9] Latency refers to the time delay between making a request for Internet content and receiving the requested content.
[10] (See '413 Patent, col. 10 ll.26-27 ("[T]he ability to redirect [DNS] requests is a standard feature in the DNS system."); see also Akamai Technologies, Inc. Tutorial Corrected Version (Docket # 84) Figure 7 (showing the end user's local domain name server making two separate DNS lookups, steps 2 and 3, to determine the IP address of the Akamai content server).)
[11] While a subtle distinction, the court interprets a "DNS lookup" to be the name resolution function provided by normal DNS servers like those of the .com domain.
[12] The term to be construed appears in claim 1 of the '703 Patent. Akamai is asserting that claim 5, which is dependent on claim 1, is infringed by Limelight.
[13] Limelight asserts that a flowchart is a "typical representation[] of a' computer program." (Docket # 71, 37.) While flowcharts are often used to represent computational steps, this is not determinative. Flowcharts are used to document human processes as well; the Internal Revenue Service uses, flowcharts to illustrate the procedure necessary for a human to figure out various complicated tax scenarios. See, e.g., Chart 1 Eligibility for the Self-Correction Program ("SCP") Qualified Plans and 403(b) Plans, http://www. irs.gov/publirs-tege/scp_qual_403b_flowchart.pdf (last visited June 14, 2007).
[14] See Black's Law Dictionary 555 (Bryan A. Garner ed., 8th ed.2004) (contrasting "e.g." with "i.e.").
[15] The term to be construed appears in claim 15 and claim 1, upon which claim 5 depends.
[16] The term to be construed appears in claim 15 and claim 1, upon which claim 5 depends.
[17] To support its construction of the term "domain name," Akamai cites to the glossary definition of the term "domain" alone at `an obscure ISP site. (See Docket # 68, 37 n. 13). Not only is "domain" a different term than "domain name," but the popular dictionary definition of "domain name" eschewed by Akamai for its proposed construction is very close to Limelight's proposed construction. See Webster's II New College Dictionary 337 (2001) (defining "domain name" as "[a] series of alphanumeric strings separated by periods, such as www.lunco.com, that is the address of a computer network connection and that identifies the owner of the address.").
[18] The terms to be construed appear in claim 1, upon which claim 5 depends.
[19] The root servers are a worldwide set of domain name servers at fixed IP addresses which can be queried to provide the location of the next level of lower-level DNS servers supporting the top-level domains such as .com, .org, etc. They provide a known starting place at the top of the domain name hierarchy for a client's local name server to begin in order to resolve a hostname. (See Docket # 84, 14.)
[20] The term to be construed in claim 5 appears in claim 1, upon which claim 5 depends.
[21] The four claims use three similar terms with slightly different wording. The parties have, consolidated these into two separate contested terms in their briefs; however, they each argue for the same (but different between the parties) construction for all three.