Opinion
CIVIL ACTION NO. 06-11109-RWZ.
June 29, 2007.
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
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 (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 (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 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, Fast Corp. v. Checkouts 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
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 participating content provider is associated with an content provider is associated with an alphanumeric string . . . alphanumeric 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 ignores the Federal Circuit's warning inPhillips 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 hostname:
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 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. . . . Thus, according to the present invention, a virtual server hostname is prepended into the URL for a given embedded object. . . ."
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 content 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)."
(`645 Patent, col. 6 l. 35 — col. 7 l. 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.) 2. Term 2 (`645 Patent, Claim 1) Term Court's Construction
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).)
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.
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.
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.)
(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.(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.)
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).)
3. Term 4 (`645 Patent, Claim 1) Term Court's Construction
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.
"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).)
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. (Id. col. 10 ll. 64-67 (emphasis added).)
Latency refers to the time delay between making a request for Internet content and receiving the requested content.
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 5 (`645 Patent, Claim 1) Term Court's Construction
. . . the alphanumeric string is resolved . . . the alphanumeric string is translated without reference to a filename for the into an IP address without reference to given object . . . the name of the object . . . The parties do not appear to disagree on 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.5. Term 6 (`645 Patent, Claim 1) Term Court's Construction
. . . being selected according to a load . . . being selected by a procedure that sharing algorithm enforced across the distributes requests for objects among a subset of the set of content servers group of content servers in a content associated with the given name server . . . delivery network associated with the particular name server to avoid overloading any single content server . . . 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. 11 l. 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. `413 Patent Terms in Dispute
1. Term 7 (`413 Patent, Claims 8, 18, 20) Term Court's Construction
. . . responsive to a DNS query, selecting . . . in response to a DNS query, the a given one of the name servers in the content delivery network's domain name content delivery network . . . [claims 8, system selects a particular name server . . . 18] . . . responsive to a DNS query received . . . in response to a DNS query received from a client local name server, from a client local name server, the selecting a given one of the name content delivery network's domain name servers in the content delivery network system selects a particular name server . . . . . . [claim 20] 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 asecond 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.
(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).)
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 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 discussedsupra, 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. The construction adopted by the court reflects this broader understanding of the term in dispute.
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.
2. Term 9 (`413 Patent, Claims 8, 18, 20) Term Court's Construction
. . . the alphanumeric string is resolved . . . the alphanumeric string is translated without reference to a filename for the into an IP address 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 (`703 Patent, Claim 5) Term Court's Construction
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.
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 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 preferredmethod for modifying the object URL" is described and referred to as "[t]he routine." (Id. col. 6 ll. 44-47 (emphasis added).)
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/pub/irs-tege/scp_qual_403b_flowchart.pdf (last visited June 14, 2007).
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.
See Black's Law Dictionary 555 (Bryan A. Garner ed., 8th ed. 2004) (contrasting "e.g." with "i.e.").
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 l. 65 — col. 7 l. 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 15) Term Court's Construction
. . . modifying a URL for the page object . . . . . . modifying a Uniform 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, Claims 5, 15) Term Court's Construction
The term to be construed appears in claim 15 and claim 1, upon which claim 5 depends.
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. Terms 14 and 15 (`703 Patent, Claim 5) Term Court's Construction
The terms to be construed appear in claim 1, upon which claim 5 depends.
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 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.
6. Terms 16 and 17 (`703 Patent, Claims 5, 15, 19, 34) Term Court's Construction
The term to be construed in claim 5 appears in claim 1, upon which claim 5 depends.
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 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 server includes . . . a mechanism in the second level name a load balancing mechanism that server monitors the loads on a group of balances loads across a subset of the set content servers in a content delivery of servers. 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" inload 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 to a content . . . generating an alternative resource provider-supplied URL to generate an locator (ARL) by adding a name or other alternate resource locator (ARL) . . . identifier that can be translated 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.