Summary
holding that SuperGuide was "distinguishable because it involved selecting from a set of more than two items "
Summary of this case from Bradley v. Applied Marine Systems LLCOpinion
Case No. C-13-2021 RMW Related Case No. C-13-02024-RMW
04-18-2014
RADWARE LTD., an Israeli Company; RADWARE, INC., a New Jersey Corporation, Plaintiffs, v. A10 NETWORKS, INC., a California Corporation, Defendant. RADWARE LTD., an Israeli Company; RADWARE, INC., a New Jersey Corporation, Plaintiff, Counter Defendants, v. F5 NETWORKS, INC., a Washington Corporation, Defendant, Counter-Plaintiff.
ORDER CONSTRUING CLAIMS OF U.S.
PATENT NOS. 6,665,702; 8,266,319; and
8,484,374
On April 8, 2014, the court held a claim construction hearing for the purpose of construing the meaning of certain terms in three Radware patents.
I. BACKGROUND
Radware brings this patent infringement action against its competitors A10 and F5, alleging infringement of claims 1, 2, 6-9, 13 and 14 of U.S. Patent No. 6,665,702 ('702 Patent); claims 1-7, 9-19, and 21-32 of U.S. Patent No. 8,266,319 ('319 Patent); and claims 1-4, 6-12, 14, and 15 of U.S. Patent No. 8,484,374 ('374 Patent) (collectively Asserted Patents). All three patents are entitled "Load Balancing" and relate to the "management of networks that have multiple connections to the Internet through multiple Internet Service Providers (ISPs)." '702 col.15 ll.53-56. The '319 Patent is a division of the '702 Patent and the '374 Patent is a continuation of the '319 Patent. The '702 and '319 Patents have the same specification (other than some formatting variances) and the '374 Patent shares the same specification other than the "Summary" section.
The technology at issue relates to link load balancing in a multi-homed environment. A "multi-homed" network is a network with multiple connections to the Internet. '702 col.15 ll.53-56. "Link load balancing" is a process for allocating network communications across these connections.
The asserted patents relate to techniques and systems for selecting a specific route from the multi-homed network to the Internet and from the Internet into the multi-homed network. The claimed inventions describe both "outbound" and "inbound" link load balancing. The claims of the '702 Patent and claims 24-28 of the '319 Patent are directed to outbound link load balancing. Claims 1-23 and 29-32 of the '319 and the claims of the '374 Patent are generally directed to inbound link load balancing. The court explains outbound link load balancing in detail; inbound link load balancing is essentially the reverse.
The patents claim link load balancing as both a method and system. Representative Claim 1 of the '702 patent describes a method for outbound link load balancing:
1. A method for managing a computer network connected to the Internet through a plurality of routes, comprising the steps of:
receiving a request from a client within a client computer network directed to a remote server computer within a second computer network;
looking up a table entry within a proximity table indexed by an address related to the remote server computer, the tables entries of the proximity table containing ratings for a plurality of routes between the client computer network and the second computer network; and
selecting one of the plurality of routes through which to route the client request, based on the ratings within the table entry looked up in the proximity tables,
wherein the plurality of routes assign respective IP addresses to the computer network, and wherein the method further comprises the step of setting the source IP address of the client request corresponding to the selected route on the client side.
Figure 3B of the asserted patents depicts outbound link load balancing:
Image materials not available for display.
The client 105 is situated within a multi-homed environment and is connected to the Internet 110 through three ISPs 115, 120, and 125. '702 col.15 ll.61-64. In this example, each ISP provides a single route 1, 2, or 3, to the Internet through routers 130, 135, and 140, respectively. Id. col.15 l.64-col.16 Each router has its own IP address range, 20.x.x.x, 30.x.x.x, and 40.x.x.x, respectively. Id. col.16 ll.4-6.
Client 105 has an IP address of 10.1.1.1 and seeks to connect to remote server 150, with an IP address of 192.115.90.1. When the client 105 connects to remote server 150 over the Internet, content router 145 sends three "polling requests" to server 150 through each of the three routers and ISPs. Id. col.16 ll.10-14. "When sending the polling requests, content router 145 assigns respective network addresses 20.1.1.1, 30.1.1.1 and 40.1.1.1 to client 105. Thus three polling requests are sent: one from each of the sources 20.1.1.1, 30.1.1.1 and 40.1.1.1 to destination 192.115.90.1." Id. col.16 ll.10-14.
The server 150 replies to each of the three polling requests, which are returned through the ISPs. The polling results are then translated by content router 145 into a rating for each route. Id. col.16 ll.26-28. In this example, the polling replies are "measured for latency and number of hops," but the patents also disclose other measureable parameters. Id. col.16 ll.18-20.
The number of hops refers to the number of networking elements between the source and the destination along a particular connection. Dkt. No. 156-2 (Peles Depo.) at 95:23-96:4. Latency is a measure of the time it takes for a communication over the network to travel from one point to another. Id. at 65:9-12. Another measurement used is "time to live" or "TTL," which is the number of hops a packet is allowed to travel before expiring.
All docket numbers are from the 13-cv-2021 docket unless otherwise noted.
Based on the polling results, the content router selects one of the three routes for connecting the client 105 with the server 150. '702 col.16 ll.18-20.The polling results are stored in a "proximity table" 155, shown in Figure 3D. The polling results are saved so that "when a new client 160 with IP address 10.2.2.2 on the private network attempts to connect to a server 165 with IP address 192.115.90.2, through a content router 145, content router 145 determines from proximity table 155 that the best router to use is router 135." Id. col.16 ll.28-34.
Another aspect of the invention ensures that when the content router sends the client request out to the remote server, it also sets the client IP address to correspond to the specific route chosen. For example, if the best route, as determined by the polling requests and selected by the content router is "2", the content router will send the request from the client through router 135 and ISP 120, and sets the client IP address to 30.1.1.1, so that when the remote server replies to the client the information returns through the same route. Id. col.16 ll.40-46.
II. LEGAL STANDARD
Claim construction is exclusively within the province of the court. Markman v. Westview Instruments, Inc., 517 U.S. 370, 387 (1996). "It is a 'bedrock principle' of patent law that 'the claims of a patent define the invention to which the patentee is entitled the right to exclude.'" Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (en banc) (internal citation omitted). Claim terms "are generally given their ordinary and customary meaning," defined as "the meaning . . . the term would have to a person of ordinary skill in the art in question . . . as of the effective filing date of the patent application." Id. at 1313 (internal citation omitted). The skilled artisan reads the claim term "in the context of the entire patent . . . including the specification." Id., see also Multiform Desiccants, Inc. v. Medzam, Ltd., 133 F.3d 1473, 1477 (Fed. Cir. 1998). In determining the meaning of a disputed claim limitation, the intrinsic evidence, including the claim language, written description, and prosecution history, is the most significant. Phillips, 415 F.3d at 1315-17. The court reads claims in light of the specification, which is "the single best guide to the meaning of a disputed term." Id. at 1315. Furthermore, "the interpretation to be given a term can only be determined and confirmed with a full understanding of what the inventors actually invented and intended to envelop with the claim." Id. at 1316 (quoting Renishaw PLC v. Marposs Societa' per Azioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998)). The words of the claims must be understood as the inventor used them as revealed by the patent and prosecution history. Id.
Although extrinsic evidence is less significant than the intrinsic record, the court may also reference extrinsic evidence to "shed useful light on the relevant art." Id. at 1317 (quoting C.R. Bard, Inc. v. U.S. Surgical Corp., 388 F.3d 858, 862 (Fed. Cir. 2004)). "[T]echnical dictionaries may provide [help] to a court 'to better understand the underlying technology' and the way in which one of skill in the art might use the claim terms. . . . Such evidence . . . may be considered if the court deems it helpful in determining 'the true meaning of language used in the patent claims.'" Id. at 1318 (internal citations omitted).
III. CLAIM CONSTRUCTION
A. "Proximity" or "Proximities"
| Radware's Proposed Construction | Defendants' Proposed Construction | Court's Construction |
| The quality of the relationship between a client and a first server or server farm as compared with the relationship between the client and a second server or server farm when collectively considering multiple measurable factors such as latency, hops, and server processing capacity | A measurement/measurements based on at least latency and number of hops | A measurement or measurements based on hops, latency, TTL, or a combination thereof. |
The term "proximity" or "proximities" appears in claims 1 and 8 of the '702 patent, claims 3-5, 9, 15-17, 21, 29, 30, and 32 of the '319 patent, and claims 5 and 13 of the '374 patent. Dependent claim 3 of the '319 patent is representative of how the disputed term is used:
3. The device of claim 1, wherein said network controller further determines proximities of remote computers to the computer network via the plurality of routes and selects one of the plurality of routes based on the proximity determination.
There are several facets to the dispute over "proximity." Radware believes that the definition of "network proximity" should be used to construe "proximity." A10 maintains that "proximity" requires a measurement of both latency and hops. F5, at the claim construction hearing, suggested that proximity might not be limited to a measurement of just latency and hops, but definitely could not include "server processing capacity" or any measurements related to the destination server.
The court must give the claims their plain and ordinary meaning consistent with the specification. Phillips, 415 F.3d at 1315-17. As explained below, the "proximity" measurement must be based on at least one measurable factor of hops, latency or TTL. Therefore, the court construes "proximity" as: "A measurement or measurements based on hops, latency, TTL, or a combination thereof."
(a) "Proximity" does not have the same meaning as that given for "network proximity"
Radware argues that "proximity" has the same meaning as the term "network proximity" which is defined in the specification as:
It is noted that throughout the specification and claims the term "network proximity" refers to the quality of the relationship between a client and a first server or server farm as compared with the relationship between the client and a second server or server farm when collectively considering multiple measurable factors such as latency, hops, and server processing capacity.'702 c.4 ll.57-64. Defendants argue that this passage only defines "network proximity" and does not have the same meaning as "proximity." Defendants also point out that this definition of "network proximity" does not appear in the '374 specification, although it is incorporated by reference through the '319 Patent.
"Network proximity" is used in the context of describing global server load balancing, which all parties appear to agree the patent claims do not cover. This is apparent from the comparison of a client to two different server farms. In global server load balancing, a load balancer selects which redundant server farm should be used to respond to a client request. The patents cover link load balancing, or the selection of which redundant route to the same server should be used to respond to a client request.
The inventors sometimes shortened the term "network proximity" to "proximity" when discussing server load balancing, such as in Figure 2A. Figure 2A depicts server load balancing and shows a "proximity" table which could be more fully be labeled a "network proximity" table. However, the patents never use the term "network proximity" when discussing link load balancing. See, e.g. '702 col.14 ll41-46 ("A 'network proximity' may be determined for a requester such as client 26 with respect to each load balancer/server farm by measuring and collectively considering various attributes of the relationship such as latency, hops between client 26 and each server farm, and the processing capacity and quality of each server farm site.") (emphasis added). Thus, Radware's contention that the terms are "interchangeable" is not supported. Because network proximity is used exclusively to discuss server load balancing, the court will not import that term into link load balancing.
(b) "Proximities" is limited to hops, latency, or TTL
F5's contention at the claim construction hearing was that "proximity" measurements do not include server capacity. Although the patents do disclose using attributes like capacity as a factor in selecting a route, the patents only disclose looking at server and other characteristics after determining proximity. For example, the patents describe determining a proximity as follows:
Additionally in accordance with a preferred embodiment of the present invention, the measuring step measures proximities based on the number of hops undergone by the received replies in travelling from the remote server to the computer network. Preferably the measuring step measures proximities based on the latency, relative TTL, and number of hops of the received replies in travelling from the remote server to the computer network.'702 col.5 ll.16-37. After determining proximity, "the selecting step determines whether or not an ISP is overloaded based upon a user-configurable load threshold. Furthermore, the selecting step may also select an ISP based on current load, in the event that all three of the best three choices for ISP are unavailable or overloaded." Id. col.6 ll.5-11 (emphasis added).
Additionally or alternatively the measuring step may measure proximities based on the number of hops undergone by the received replies in travelling a round trip from the computer network to the remote server and back to the computer network, based on the TTL of the received replies in travelling a round trip from the computer network to the remote server and back from the remote server to the computer network, based on the latency of,the received replies in travelling from the remote server to the computer network or based on the latency of the received replies in travelling a round trip from the computer network to the remote server and back from the remote server to the computer network.
The patents also contrast between "content information," "quality level of the routes," and "proximity measurements." Id. col.10 ll.47-49 ("system also includes a route selector operable to select one of the routes for sending data between the first node and second node on the basis of content information of the data, an obtained quality level of the routes and proximity information."); see also id. col.11 ll.17-21 ("a Destinations Table is built to summarize the connection data for each one of a plurality of possible destination nodes. The Destinations Table is built based on previously determined proximities.").
This distinction is also apparent in the claims. For example, in the '702 patent, claim 1 uses a "proximity table ratings for a plurality of routes" and selects a route "based on the ratings within the table." Dependent claim 3 then adds "said selecting step selects the best route, from among the best three choices for routes [found in the proximity table], that is available and not overloaded." Claim 5 adds "said selecting step selects an route based on current load, in the event that all three of the best three choices for route are unavailable or overloaded."
In the '319 Patent, independent claim 1 "selects" a route and the dependent claims add further limitations to the selecting function, such as "proximities" (claim 3), "proximities based on at least one of a number of hops between said device and a remote computer and latency of a packet traveling between said device and a remote computer" (claim 4), "costing information" (claim 6), "load [on the route]" (claim 7), "data packet loss" (claim 8), "one or more criteria" (claim 10), and "at least two of the following: a proximity of a remote computer to the computer network via the plurality of routes, a load of said respective routes, data packet loss of said respective routes, and costing information of said respective routes" (claim 9). Claim 9 is especially indicative that "proximities" does not include load, data packet loss, or costing information.
Defendants also argue that Radware cannot rely on "server processing capacity" as a proximity factor, as it contented at the Board of Patent Appeals and Interferences (BPAI) that the '319 Patent does not "monitor the server status, the CPU utilization or the processors of the response time of the server" in selecting the best route. Dkt. No. 156-11 (BPAI trans.) at 4:10-12. Radware argues that at that point, Radware's representative was distinguishing the invention, which "only talk[s] about how to select the route," id. at 4:14, from server load balancing, which deals with "decid[ing] how to distribute [ ] requests to different servers inside the organization," id. at 4:19-20. During the same hearing, Radware's representative stated that the "route criteria" could be determined based on "[t]he load, the current load, how much the route is utilized, in general, and a few other parameter[s] that we have specified in our application." Id. at 3:11-13.
The transcript from the BPAI shows that Radware was attempting to distinguish its invention on the basis of selecting a specific route to a server, but does not provide any support for expanding the list of "proximitiy" measurements beyond those listed in the specification. The inventors appear to have carefully categorized hops, latency, and TTL as the only "proximity" measurements, although they do disclose other parameters that can be used in the selecting step (and are covered in different claims). The court also notes that the inventors disclosed measuring hops and latency both one-way and roundtrip. '702 col.5 ll.16-37.
The defendants are correct that a preferred embodiment of the invention measures both latency and hops. Defendants point to Figures 3A-4B, which depict a preferred embodiment of link load balancing in a multi-homed environment. '702 col.15 l.57-60. The specification describes a preferred method of determining proximity by sending polling requests to a server 150 and receiving replies to the polling request through each of three ISPs 115, 120, and 125. Id. col.16 ll.4-20. Once the replies are received, "each of the replies is measured for latency and number of hops." Id. col.16 ll. 18-19.
Defendants also point to Radware materials promoting its LinkProof product, which Radware contends practices the claimed invention. Radware stated that LinkProofs "patented proximity checks combine latency detection and hop count." This is not persuasive because the patentee's commercial embodiment does not limit the claims.
The problem with defendants' argument is that nothing in the specification limits the claims to this preferred embodiment. "[I]t is improper to read limitations from a preferred embodiment described in the specification—even if it is the only embodiment—into the claims absent a clear indication in the intrinsic record that the patentee intended the claims to be so limited." Liebel-Flarsheim Co. v. Medrad, Inc., 358 F. 3d 898, 913 (Fed. Cir. 2004).
Further, in the Summary of Invention, the inventors disclose determining proximity based only on the number of hops:
Additionally in accordance with a preferred embodiment of the present invention, the measuring step measures proximities based on the number of hops undergone by the received replies in travelling from the remote server to the computer network.'702 at col.5 ll.16-20; see also id. at col.6 ll.48-50, col.8 ll.9-16, col.7 l66-col. 8 l.3, col.5 ll.23-36.
(c) "Proximities" does not require two measurements
As explained above, the specification discloses examples of measuring proximity based on only one parameter, such as hops. '702 col.5 ll.16-20. Accordingly, one of ordinary skill in the art would not limit "proximities" to require measurement of two or more factors.
Accordingly, the court construes "proximity" as: "A measurement or measurements based on hops, latency, TTL, or a combination thereof."
2. "Based on at least one of"
| Radware's Proposed Construction | Defendants' Proposed Construction | Court's Construction |
| Plain and ordinary meaning | Based on at least one of each | Plain and ordinary meaning, read in the disjunctive. |
The term "based on at least one of" appears in claims 4, 16, and 30 of the '319 Patent. Defendants ask the court to construe the phrase in the conjunctive. Defendants cite SuperGuide Corp. v. DirecTV Enterprises, Inc., 358 F.3d 870, 884 (Fed. Cir. 2004), where the Federal Circuit interpreted "first means for storing at least one of a desired program start time, a desired program end time, a desired program service, and a desired program type" in the conjunctive.
First, SuperGuide has not been interpreted as a uniform rule that "at least one of . . . and" be construed in the conjunctive. See, e.g., Joao v. Sleepy Hollow Bank, 348 F. Supp. 2d 120, 124 (S.D.N.Y. 2004) (construing "at least one of a clearing transaction, a check clearing transaction, an account charging transaction, and a charge-back transaction" in the disjunctive); Pinpoint Inc. v. Amazon, 03-C-4954, 2004 WL 5681471 (N.D. Ill. Sept. 1, 2004); Rowe Intern. Corp. v. Ecast, Inc., 500 F. Supp. 2d 891, 909 (N.D. Ill. 2007) ("SuperGuide, however, did not state a universal rule for construction of the phrase 'at least one of.' Rather, SuperGuide was fact-specific; the court's construction of the term was consistent with the specification of the patent in that case.").
Second, the court finds SuperGuide distinguishable because it involved selecting from a set of more than two items. Here, the phrase "at least one of" in the claims of the '319 Patent is only used to select between two parameters separated by "and." The inventors used "at least one of hops and latency as a shorthand for hops, or latency, or hops and latency. If the inventors had limited their claims to only "hops and latency," the phrase "at least one of" would be unnecessary: the claim could simply read "wherein said network controller determines proximities based on hops and latency."
Other portions of the specification beyond the claims themselves also support the court's interpretation. For example, in the Summary of Invention, the inventors disclose determining proximity based on "at least two attributes selected from the group consisting of latency, relative TTL, and number of hops to requester." '702 col.4 ll.43-44 (emphasis added). If this phrase were interpreted as defendants suggest, the use of the conjunctive "and" would mean that all three attributes are required. This obviously conflicts with the phrase "at least two." A list using "and" is not properly construed as using "and" in the conjunctive where other uses of "and" in the specification suggest that the inventors used it in a disjunctive sense.
In the context of claims 4, 16, and 30 of the '319 Patent, the proximity determined "based on at least one of a number of hops between the computer network and a remote computer and latency of a packet traveling between the computer network and a remote computer" means that the proximity may be determined based on hops alone, latency alone, or both hops and latency together.
3. "Ratings [for a plurality of routes]"
| Radware's Proposed Construction | Defendants' Proposed Construction | Court's Construction |
| Plain and ordinary meaning | Preferred order of selection [for a plurality of routes] based on measurements of latency and number of hops through each route to the remote server or the subnet of the remote server | Ratings based on proximity measurements taken through each of the plurality of routes. |
The term "ratings [for a plurality of routes]" appears in claims 1 and 8 of the '702 Patent. Claim 1 is representative of how "ratings" is used in the patent:
1. . . . looking up a table entry within a proximity table indexed by an address related to the remote server computer, the tables entries of the proximity table containing ratings for a plurality of routes between the client computer network and the second computer network; and
selecting one of the plurality of routes through which to route the client request, based on the ratings within the table entry looked up in the proximity tables, wherein the plurality of routes assign respective IP addresses to the computer network, and wherein the method further comprises the step of setting the source IP address of the client request corresponding to the selected route on the client side.
As discussed with regard to "proximity," "ratings" does not require measurements based on both latency and hops.
Defendants argue that the rating should be the "preferred order of selection" of routes and the measurements are taken from the client computer network through each of the routes to the remove server or subnet. However, the ratings are not required to be in a preferred order of selection. That is, the ratings do not have to be "1st choice, 2nd choice, 3rd choice" as defendants seem to suggest. Instead, the ratings are used in the "selecting" step to determine which route to use; the ratings are not the order of routes themselves. It is clear from the claims that the ratings are based on proximity measurements, as they are found within the proximity table.
The court construes "ratings [for a plurality of routes]" as "ratings based on proximity measurements taken through each of the plurality of routes."
4. "[one load balancing] criterion" and "one or more criteria"
| Radware's Proposed Construction | Defendants' Proposed Construction | Court's Construction |
| Plain and ordinary meaning | Lacks written description or "one of round-robin, random, latency, number of hops, packet loss, response time, load, availability or costing information" | A standard on which a decision about load balancing may be based, such as hops, latency, TTL, response time, cost, link pricing, load on the route, data content, data packet loss, availability, current load, round robin, or random. |
The term "[one load balancing] criterion" appears in claims 1-5 and 9-13 of the '374 patent and the term "one or more criteria" appears in claims 11 and 13 of the '319 patent. The "criterion" is used in the "selecting" step, as in Claim 1 of the '374 Patent: "selecting, based on at least one load balancing criterion, one ISP link from the plurality ISP links." Dependent claim 5 requires "[t]he method of claim 1, wherein the [at] least one load balancing criterion includes a measured proximity between the server and each of the ISP links."
Using Radware's plain and ordinary meaning construction could render the claim indefinite. The patents do not cover an unlimited range of load balancing criteria. However, the "criterion" is not limited to those listed by defendants. For example, the patents also disclose selecting an ISP based on "current load." '702 at col.8 ll.57-59. One of ordinary skill would understand that a "load balancing criterion" could include other parameters not explicitly disclosed by the inventors, but understood in the art at the time the invention was made.The patents disclose the following criteria for selecting a route: hops, latency, TTL, response time, cost, link pricing, load on the route, data content, data packet loss, availability, current load, round robin, or random.
Therefore, the court construes "[one load balancing] criterion" and "one or more criteria" as "A standard on which a decision about load balancing may be based, such as hops, latency, TTL, response time, cost, link pricing, load on the route, data content, data packet loss, availability, current load, round robin, or random."
5. "Weighed function of at least one of"
| Radware's Proposed Construction | Defendants' Proposed Construction | Court's Construction |
| Plain and ordinary meaning or "function in which one or more of the attributes is given a weight" | Lacks written description or "weighed function of at least one of each" | Function in which one or more of the attributes is given a weight. |
The "weighed function of at least one of" element appears in claims 4 and 12 of the '374 patent. Claim 4 is representative:
4. The method of claim 1, wherein the at least one load balancing criterion includes a decision function, wherein the decision function is a weighed function of at least one of a load on each ISP link, packet losses on each ISP link, and a cost of each ISP link.
The dispute over this claim centers on the dispute over "at least one of," which the court has already addressed in Part III.A.2, supra. The only difference in these claims is that "at least one of applies to more than just two possibilities. The inventors described using a weighed function with one or more factors:
The Decision Function for a particular path is determined by an administrative manager (not shown) and may depend, for example, on the minimum number of hops or on the relevant response time, or on the packet loss, or on the path quality, or any combination of the above parameters, according to the administrative preferences.'702 col.18 ll.38-44. The court adopts Radware's proposed construction: "function in which one or more of the attributes is given a weight."
B. "A Proximity Table [indexed by an address related to the remote server computer]"
| Radware's Proposed Construction | Defendants' Proposed Construction | Court's Construction |
| A table expressing a proximity [indexed by an address related to the remote server computer] | A table structure including at least one row [indexed by the IP address of the remote server computer or the subnet IP address of the remote server computer] | "Logically organized electronically stored information expressing a proximity [indexed by an IP address related to the remote server computer]." |
The term "a proximity table [indexed by an address related to the remote server computer]" appears in claims 1 and 8 of the '702 patent. Claim 1 is representative:
1. . . .
looking up a table entry within a proximity table indexed by an address related to the remote server computer, the tables entries of the proximity table containing ratings for a plurality of routes between the client computer network and the second computer network; and [selecting a route based on the ratings]
The parties dispute whether the "table" is limited to a "table structure including at least one row" and whether "an address related to the remote server" is limited to "the IP address of the remote server computer or the subnet IP address of the remote server computer." Defendants' proposed construction is not supported by the specification.
Nothing in the specification limits the structure of the table to rows. It is true that a depiction of the proximity table 155 uses rows. See '702 Fig. 3D; col. 16 l.25. However, the specifications do not use the term "row", "column", or even "cell", to describe the proximity table.
Defendants point to a dictionary definition of "table" from the Dictionary of Networking:
In a relational database system, a table is comparable to a database file, but is more highly structured. The organization of a table is logical, not physical. Each row (or record) in a table contains a unique key, or primary key, so that any item of data in the table can be retrieved by referring only to that key. Through the process known as normalization, all data items in a row are made to depend only on this primary key. View and data dictionaries in a relational database take the form of two-dimensional tables.Dkt. No. 156 (Def. Br.) at 19 (emphasis added). The court does not find this definition helpful. The definition explains that a "table" is just way to describe logically organized data items. The defendants did not present any evidence that one of ordinary skill in the art would require a "table" to be organized into physical columns and rows, rather than understanding "table" as a computer engineering shorthand for a type of data structure.
Similarly, nothing limits the "address related to" the remote server computer to only an IP address or subnet IP address. "Related to" is broader than these two possibilities, although the patent is limited to identifying remote computers by related IP addresses. The patent does not disclose that the inventors understood any other means for identifying the remote computer.
The court construes "proximity table" as: " Logically organized electronically stored information expressing a proximity [indexed by an IP address related to the remote server computer]."
1. "The Table Entries" of the proximity table containing
| Radware's Proposed Construction | Defendants' Proposed Construction | Court's Construction |
| Plain and ordinary meaning | Each of the table rows of the proximity table containing | Entries in the proximity table |
This term appears in claims 1 and 8 of the '702 Patent. As discussed above, the proximity table is not limited to a table containing rows. The term "the table entries" has a plain and ordinary meaning of "entries in the proximity table."
C. "Multi-Homed [Network]"
| Stipulated Construction |
| A network that has two or more connections to the Internet at a single geographic location, each through a discrete ISP link |
This term appears in claims 1 and 9 of the '374 Patent. At the claim construction hearing, the parties indicated that they could likely reach a stipulation on the construction of multi-homed network. On April 11, the parties submitted a stipulated construction of multi-homed network, specifically: "a network that has two or more connections to the Internet at a single geographic location, each through a discrete ISP link." Dkt. No. 180. This term appears in claims 1 and 9 of the '374 patent. The court accepts this construction, which clarifies that although the entire network does not have to be at a single geographic locations, at least two Internet connections must be at a single geographic location.
D. "A Plurality of Routes"
| Radware's Proposed Construction | Defendant's Proposed Construction | Court's Construction |
| Two or more routes | Two or more ordered sequences of hosts, routers, bridges, gateways, and other devices that network traffic takes from the source to the destination that comprises a path through a network For the '702 Patent, the source is "the client computer network" and the destination is "the remote server computer" For the '319 and '374 Patents, the source is the "remote computer" and the destination is the "device" or "system" in the "computer network" or "multi-homed network" | Two or more pathways connecting a source and a destination. For the '702 Patent and claims 24-28 of the '319 Patent, the source is 'the client computer network' and the destination is 'the remote server computer.' For the'374 Patent and claims 123 and 29-32 of the '319 Patent, the source is the 'remote computer' and the destination is the 'device' or 'system' in the 'computer network' or 'multi-homed network.' |
The term "a plurality of routes" appears in claims 1 and 8 of the '702 patent, and claims 1-3, 6-15, 18-29, 31, and 32 of the '319 patent.
While the parties agree that "plurality" means two or more, Radware argues that "routes" does not require construction and argues that defendants' proposal is unnecessary and unhelpful.
Defendants' only support for their construction of "route" as "sequences of hosts, routers, bridges, gateways, and other devices" is derived from a leading attorney question posed to one of the named inventors at deposition. See Peles Depo. at 43:14-24 ("Q: . . . a route on the internet is a path that traffic takes from its source to its destination; is that right? A: I would say it's the vice versa. You can say that were the - the way from - or the route from a source to a destination is a path. Q: Okay. A: Yeah. Q: And that path consists of a sequence of network devices, like routers, bridges, gateways or other devices; is that right? A: . . . yes.").
This extrinsic evidence is not particularly helpful in construing the term "routes." The patents do not discuss any specific structure of the "routes" and generally refer to a "pathway" or "path" for connecting a source and destination. See, e.g., '702 col.17 ll.35-45. The court elects not to import a list of specific "route" structures into the claims and believes that a lay jury will understand the scope of a "route" or "pathway" between a source and destination, especially when coupled with the defendants' suggestion of indicating the source and destination for each patent.
The parties also disagree over whether claims 24-28 of the '319 Patent are directed to outbound or inbound link load balancing. During prosecution, the inventors referred to claims 2428 (then pending claims 146-50) as inbound claims. Dkt. No. 156-13 ('319 File History) at 828. However, claims 24-28 refer to "translating the source IP address to an IP address corresponding to the selected route of the plurality of routes," which is only done for outbound link load balancing. Compare '702 col.16 ll.35-39 (setting source IP address for outbound) to id. col.17 ll. 1 -5 (setting destination IP address for inbound). Thus, the general statement that "claims 12310, and new claims 151-154, are directed toward techniques for performing multi-homing for inbound DNS requests" was not accurate. Dkt. No. 156-13 ('319 File History) at 828.
The court construes "a plurality of routes" as: "Two or more pathways connecting a source and a destination. For the '702 Patent and claims 24-28 of the '319 Patent, the source is 'the client computer network' and the destination is 'the remote server computer.' For the'374 Patent and claims 1-23 and 29-32 of the '319 Patent, the source is the 'remote computer' and the destination is the 'device' or 'system' in the 'computer network' or 'multi-homed network.'"
1. "A plurality of available routes from said first node to said second node"
| Radware's Proposed Construction | Defendants' Proposed Construction | Court's Construction |
| Plain and ordinary meaning | A plurality of available routes connecting said first node to said second node through the Internet | A plurality of available routes connecting said first node to said second node through the Internet. |
The term "a plurality of available routes from said first node to said second node" appears in claims 24, 26, and 28 of the '319 patent. Defendants seek to replace "from" with "connecting" and add that the routes pass over the Internet. Essentially, defendants ask the court to construe claims 24, 26, and 28 "as requiring the same multi-homed network architecture as all of the other claims of the asserted patents (i.e., a computer network connected to the Internet through a plurality of routes)." Def. Br. at 33.
Defendants rely on the prosecution history where Radware argued that claims 24-28 (then pending claims 146-50) were "directed toward techniques for performing multi-homing for inbound DNA requests" and that "the 'plurality of routes' as defined in the claims are a plurality of routes each connecting the same device to the internet." Dkt. No. 156-13 ('319 File History) at 828, 831. Radware argues that these portions of the prosecution history were not directed to claims 24-28. As discussed above, Radware is correct that the statements made in the prosecution history were not necessarily directed at claims 24-28. Nonetheless, the court does not find Radware's "network" position persuasive.
The patents do not disclose any "networks" other than the Internet. Although the specification refers to the more generic "network" when discussing "nodes" '319 col.10 ll.25-47 ("There is thus provided in accordance with yet another preferred embodiment of the present invention a routing system for routing data via a network from a first node to a second node, and wherein the network having a plurality of available routes from the first node to the second node . . ."), this portion of the specification is directed to enabling the use of different parameters for selecting a route, such as "costing information," col.10 l.43, "content information," col.10 l.32, or "quality level," col.10 l.33. These passages do not suggest that the inventors contemplated selecting routes in any networks other than those connecting to the Internet.
The court construes "a plurality of available routes" as: "A plurality of available routes connecting said first node to said second node through the Internet."
2. "[Internet Service Provider (ISP)] Links"
| Radware's Proposed Construction | Defendants' Proposed Construction | Court's Construction |
| Plain and ordinary meaning | Lacks written description or "routes" as construed for the '319 Patent | A pathway connecting to or from an ISP. |
The term "Internet Service Provider (ISP)/ISP] link[s]" appears in claims 1, 2, 4-7, 9, 10 and 12-15 of the '374 patent. Defendants contend that unless "ISP link" is construed as "routes" the term lacks written description. Specifically, defendants point out that the term "ISP links" appears in the '374 specification, filed in 2012, and not in the '702 specification, filed in 1999. Therefore, if "ISP links" is construed as something other than "routes," the written description supporting that term does not appear until 2012, which would render the claim anticipated by prior Radware sales.
The defendants fail to explain why one of ordinary skill in the art would not understand the term "ISP link" based on the description in the '702 patent. It is true that the exact phrase does not appear in the '702 patent, but the patent does describe (1) ISPs, (2) how ISPs connect a computer to the internet, and (3) uses the term "link" to describe a part of a route. See '702 col.17 l.61, col.18 l.24; see also Figs. 3A-3F (depicting routes between a client 105 and a remote server 150 with links to an ISP 130, 135, 140). Based on the description found within the '702 specification, the court understands that an "ISP link" is a subpart of a "route." The court gives "ISP link" its plain and ordinary meaning of "a pathway connecting to or from an ISP."
E. "Configured To"
| Radware's Proposed Construction | Defendants' Proposed Construction | Court's Construction |
| Plain and ordinary meaning | Specifically set up for operation in a particular way, including defining any necessary settings, to | Programmed to [perform certain functions]. This does not require user intervention if the feature claimed is included in the product as supplied. |
The term "configured to" appears in claims 9 and 14 of the '374 patents. For purposes of construing the term, claim 14 of the '374 patent is representative of how the disputed term is used:
14. The device of claim 9, wherein the network controller is further configured to translate a source IP address of the server to the address of the selected ISP link, thereby responses to the client are routed through the selected ISP link.
Defendants essentially argue that "configured to" should be interpreted to require user-intervention to select settings and operating parameters. The defendants cite to various technical dictionaries defining the term "configure" or "configuration" in computer networking fields. Def. Br. at 30. Defendants also accuse Radware of construing "configured to" as "capable of."
First, the court notes that the term "configured to" is a term used by patentees in nearly every field of art. It is not used in the claims in a technology-specific manner. This is similar to preamble terms "comprising," "consisting," and "consisting essentially of" which are generally not interpreted according to specific fields of art. See Manual of Patent Examining Procedure § 2111.03 (Transitional Phrases). Here, nothing in the specification suggests that the inventors used the term "configured to" in a technology-specific manner, rather than as a patent term of art. Thus, the definitions cited by defendants which require actively setting up computer programs are not persuasive. Phillips, 415 F.3d at 1322 (technical dictionaries are inappropriate if it is unclear whether "a term is used in the same way in a treatise as it would be by the patentee.").
Second, courts have generally interpreted "configured to" more narrowly than simply "capable of." See Typhoon Touch Technologies, Inc. v. Dell, Inc., 659 F.3d 1376, 1380 (Fed. Cir. 2011) (construing "memory . . . configured to" as "memory that must perform the recited function");see also Aspex Eyewear, Inc. v. Marchon Eyewear, Inc.,672 F.3d 1335 (Fed. Cir. 2012) (interpreting "adapted to" and construing it in the "narrow" sense of "configured to" in contrast to the "broader" sense as "capable of"); Sta-Rite Indus., LLC v. ITT Corp., 682 F.Supp.2d 738, 753 (E.D. Tex. 2010) (construing "adapted to," in context, to mean "designed or configured to," not "having the capacity to"); Boston Scientific Corp. v. Cordis Corp., 2006 WL 3782840 (N.D. Cal. Dec. 20, 2006) (construing "adapted to," in light of patent as a whole, to mean "configured to," not "capable of").
In general, the court agrees with Radware that "configured to" does not require user activation, but does require "that the claimed feature be included in the software." Dkt. No. 136 (Radware Br.) at 13 citing Fantasy Sports Properties, Inc. v. Sportsline.com, Inc., 287 F.3d 1108, 1118 (Fed. Cir. 2002). Thus, merely being "capable of" performing a function is not enough, but if a device comes programmed with specific claimed functions it falls within the claims.
The court construes "configured to" as: "programmed to [perform certain functions.]" This does not require user intervention if the feature claimed is included in the product as supplied. Fantasy Sports, 287 F.3d at 1118.
F. "Sets/Setting the source IP address of the client request corresponding to the selected route on the client side"
| Radware's Proposed Construction | Defendants' Proposed Construction | Court's Construction |
| Plain and ordinary meaning | Settings/sets the source IP address of the client request to one associated only with the selected route that connects the client computer network to the Internet | Setting/sets the source IP address of the client request to one associated only with the selected route that connects the client computer network to the Internet. |
The term "set[s]/[ting] the source IP address . . ." appears in claims 1 and 8 of the '702 patent. Claim 1 of the '702 patent is representative of how the disputed term is used:
1. . . . selecting one of the plurality of routes through which to route the client request, based on the ratings within the table entry looked up in the proximity tables, wherein the plurality of routes assign respective IP addresses to the computer network, and wherein the method further comprises the step of setting the source IP address of the client request corresponding to the selected route on the client side.
The parties dispute whether source IP address must be associated with only one route. The court agrees with defendants that the intrinsic evidence supports their proposed construction.
The specification describes that one aspect of the invention is to ensure that responses sent back from a destination server will be returned through the specific selected route on the source network. This is illustrated in Figures 3E and 3F, which show that
[C]ontent router 145 sends requests issued from client 160 via router 135, and indicates a source IP address of 30.1.1.1 with each such request, which is the IP address associated with router 135 from within the range of IP addresses allocated by ISP 120.'702 at col.16 ll.35-46. Claim 1 of the '702 Patent describes this action as "the step of setting the source IP address of the client request corresponding to the selected route on the client side."
As illustrated in FIG. 3F, this ensures that subsequent responses sent back from server 165 will be addressed to IP address 30.1.1.1 and, accordingly, will be routed through ISP 120. Content router 145 in turn uses network address translation (NAT) data to determine that IP address 30.1.1.1 corresponds to private IP address 10.2.2.2, and transmits the responses from server 165 back to client 160.
Radware argues that "corresponding to" should not be replaced with "associated only with" and that the term does not require construction. First, the court disagrees that the jury will understand the meaning of the term "setting the source IP address" without a construction. Radware presents no evidence that this term has a plain and ordinary meaning. Second, the specification does not provide any support for a construction other than "associated only with." The court is not improperly importing a limitation from a preferred embodiment into the claims because there is no suggestion that responses received from the destination server will go anywhere other than the selected route or that the inventors contemplated any other meaning for this term.
At the claim construction hearing, Radware also suggested that one of ordinary skill in the art would understand that a network controller must have a "fail over" or "high availability" function so that if the return route was unavailable the client request would return along a different route. This argument was not presented in the papers and was not supported by any evidence about the state of the art or knowledge of one of ordinary skill. Furthermore, the specification seems to indicate that this problem would be solved at the selecting step before routing the response to the client:
In the event that the router indicated as first choice for the best proximity connection is unavailable or overloaded, the present invention preferably uses a second choice router instead. Thus the present invention ensures that if an ISP service is unavailable, connectivity to the Internet is nevertheless maintained.'702 col.17 ll.9-27.
Referring back to FIG. 3F, suppose for example that ISP 120 is unavailable, and that content router 145 routes the outgoing client request through ISP 125 instead of through ISP 120. In accordance with a preferred embodiment of the present invention, content router 145 routes the outgoing request through ISP 125 and labels the outgoing request with a source IP address of 40.1.1.1. Had content router 145 used ISP 125 but indicated a source IP address of 30.1.1.1, the response from server 150 would be directed back through ISP 125, and not be able to get through to client 160.
Radware counters that defendant's construction is not technically correct because routers, and not routes, have IP addresses. Thus, you cannot "set the source IP address" to a "selected route." At the hearing before the BPAI, Radware explained how to assign an IP address to a specific route:
JUDGE HOMERE: How do you assign the IP address to a specific route? I thought the IP address was traditionally assigned to a device for instance, a server, a workstation. How do you determine assigning an IP address to route that may include the plurality of components in there?BPAI Trans. at 4:22-5:23 (emphases added). This exchange reinforces the conclusion that part of the invention is ensuring that responses will return to the server using the same route, and also shows that the inventors understood how to assign an IP address to a route. See also id. at 8:2-6 ("So we are using techniques that you will find in prior art like DNS interception in the replies and some other things. But they are not invented or take into consideration all what is required in order to select a route, not select a router. And I think this is the main difference . . . ."); 9:19-21 (the prior art "assigns an address to a destination, so they don't talk about what route to that destination.").
MR CHESLA: So when an organization is buying IP addresses, public IP addresses is buying a different radius from different ISPs. He is not buying these IP addresses or pay for that for specific server so he can use whatever he want for that. So when you set these IPs on the router, for example, in the interest to the organization, this is the destination IP that represent the whole organization. And we use this IP in order to enforce the route through the right ISP to come into the organization. And then we know how to take—we, technically, know how to take this
destination IP and replace it with another destination IP. This is what we call the IP network translation that will go to a certain server.
And there is pre-configuration that you will not IP to certain other IP inside. This is the way that it actually works on the outbound, meaning that if a client inside the organization going out, and we decide to which route we want to direct the traffic, then what we are doing, we are using our solution to simply send the information to a very, to a specific link that go directly to this route because our solution is being connected to all these routes to the Internet.
And we are changing the source IP address in order that the replies that will come back will go through the same route. So we enforce consistency of the request, and the replies that will go through the same way that we have decided to do. So we look on two roles from our perception, one is the route itself and certain parameters that characterize it, and have also the network manager to decide which route you want to take.
The court adopts the construction "setting/sets the source IP address of the client request to one associated only with the selected route that connects the client computer network to the Internet."
G. "Costing Information" or "Cost"
| Radware's Proposed Construction | Defendants' Proposed Construction | Court's Construction |
| Plain and ordinary meaning | The monetary price | Plain and ordinary meaning not limited to monetary price. |
The term "costing information" or "cost" appears in claims 6, 9, 18, 21, 24, 26, and 28 of the '319 Patent and in claims 4 and 12 of the '374 Patent. Claim 6 of the '319 Patent is representative:
6. The device of claim 1, wherein said network controller selects one of the plurality of routes on the basis of costing information of said respective routes.
The only issue with respect to cost is whether it is limited to monetary price. Defendants argue that "cost" should be limited to monetary price based on the prosecution history. During a hearing before the Board of Patent Appeals and Interferences (BPAI), Radware argued that their invention selects a route based on criteria "like the cost of the line of the route itself. It's going to be more expensive for one ISP and less expensive for another one." Dkt. No. 156-11 (BPAI trans.) at p.57 ll.8-11. Defendants' allege that this statement links cost to monetary price.
The '319 and '374 specifications do not define "cost" or "costing information" but do mention "the cost of the path connection," '319 at col.12 l.11, or "costing of the link", '319 at col.17 l.36 and '374 at col.8 l.36. The specifications also separately use the term "pricing." See '319 at c.12 l.1, col. 17 l.25; '374 at col.8 l. 24.
The court declines defendants' invitation to limit cost to monetary price. "Cost" can represent an array of non-monetary resources. Something can "cost" bandwidth or be "expensive" in terms of time. Radware's statement at the BPAI hearing did not limit cost to monetary price. The use of the different terms "cost" and "price" in the specification suggest that the inventors understood the terms had different meanings and were not synonymous as defendants suggest. The terms "costing information" or "cost" are given their plain and ordinary meaning, not limited to monetary price.
IV. ORDER
For the reasons set forth above, the court construes the claims as follows:
| Claim Terms | Construction |
| Proximity or Proximities | A measurement or measurements based on hops, latency, TTL, or a combination thereof. |
| Based on at least one of | Plain and ordinary meaning, read in the disjunctive. |
| Ratings [for a plurality of routes] | Ratings based on proximity measurements taken through each of the plurality of routes. |
| "[one load balancing] criterion" and "one or more criteria" | A standard on which a decision about load balancing may be based, such as hops, latency, TTL, cost, link pricing, load on the route, data content, data packet loss, availability, current load, round robin, or random. |
| Weighed function of at least one of | Function in which one or more of the attributes is given a weight. |
| A proximity table [indexed by an IP address related to the remote server computer] | Logically organized electronically stored information expressing a proximity [indexed by an IP address related to the remote server computer]. |
| Table Entries | Entries in the proximity table. |
| Multi-homed [network] | A network that has two or more connections to the Internet at a single geographic location, each through a discrete ISP link. |
| A plurality of routes | Two or more pathways connecting a source and a destination. For the '702 Patent and claims 24-28 of the '319 Patent, the source is 'the client computer network' and the destination is 'the remote server computer.' For the'374 Patent and claims 1-23 and 29-32 of the '319 Patent, the source is the 'remote computer' and the destination is the 'device' or 'system' in the 'computer network' or 'multi-homed network.' |
| A plurality of available routes from said first node to said second node | A plurality of available routes connecting said first node to said second node through the Internet. |
| [Internet Service Provider (ISP)] Links | A pathway connecting to or from an ISP. |
| Claim Terms | Construction |
| Configured to | Programmed to [perform certain functions]. This does not require user intervention if the feature claimed is included in the product as supplied. |
| Setting/sets the source IP address of the client request corresponding to the selected route on the client side | Setting/sets the source IP address of the client request to one associated only with the selected route that connects the client computer network to the Internet. |
| Costing information or cost | Plain and ordinary meaning not limited to monetary price. |
________
Ronald M. Whyte
United States District Court Judge