Learn About the Law
Get help with your legal needs
FindLaw’s Learn About the Law features thousands of informational articles to help you understand your options. And if you’re ready to hire an attorney, find one in your area who can help.
AKAMAI TECHNOLOGIES, INC., Plaintiff-Appellee v. MEDIAPOINTE, INC., AMHC, Inc., Defendants-Appellants
This case involves U.S. Patent No. 8,559,426 and its child, U.S. Patent No. 9,426,195, which address systems and methods for efficiently routing streamed media content over the Internet. Each describes an “intelligent distribution network” that centrally manages requests for streamed media from many geographically dispersed users to mitigate bandwidth problems inherent in transmitting large volumes of data. AMHC, Inc. owns the patents, and MediaPointe, Inc. is its subsidiary. We refer to them together as MediaPointe.
Akamai Technologies, Inc. brought suit in the Central District of California against MediaPointe, seeking a declaratory judgment of noninfringement of both patents. MediaPointe counterclaimed for infringement, and Akamai then sought a declaratory judgment of invalidity. At the claim-construction stage of proceedings, the district court held that certain claims using “optimal” and “best” language were invalid for indefiniteness. For the remaining asserted claims, the district court granted Akamai summary judgment of noninfringement. First, it excluded, as untimely presented, key portions of MediaPointe's technical expert's testimony, without which MediaPointe could not reasonably establish infringement. Second, the court ruled that, even with the expert testimony, the record entitled Akamai to summary judgment of noninfringement.
We hold that the judgment of invalidity was correct in view of the intrinsic record and that the district court did not err in granting summary judgment of noninfringement even considering the expert testimony. Accordingly, without reaching the exclusion issue, we affirm.
I
A
The ’426 patent and its continuation, the ’195 patent, are titled “System and Method for Distribution of Data Packets Utilizing an Intelligent Distribution Network.” The two patents share a specification, so we cite only the ’195 specification. Both patents describe and claim systems and methods for distributing streamed media content over the Internet to geographically dispersed users. Data streams from a server, when transmitted over the Internet to a client, may pass through various intermediate “nodes” and other devices (such as routers), each step between adjacent devices constituting a “hop.” See ’195 patent, col. 2, lines 23–52. The ’426 and ’195 patents explain that, in the prior art, inefficient routing meant that a stream could become unacceptably delayed because its route contained either more hops than necessary or particular devices suffering bandwidth constraints. Id., col. 1, lines 41–52; col. 2, lines 53–60.
The patents propose more efficient routing by use of an “intelligent distribution network.” Id., col. 3, lines 17–29. A typical intelligent distribution network has a management center and several nodes; the management center, in response to a client request for data, can direct the client to the “best performance” node for ultimate client delivery and also identify the best route for data to travel from the center to get to that node. See id., col. 3, lines 30–40; col. 6, line 16 through col. 7, line 22. The management center uses a “mapping engine” to gather information about nodes and potential routes. Id., col. 3, lines 37–40. The mapping engine identifies various possible routes to the client and then probes them to create “trace route results,” which are ordered lists of each hop on a route, specifying (1) the Internet Protocol (IP) address of the hop's endpoint device (node, router, etc.) and (2) “latency,” a round-trip time associated with that device, i.e., the time it takes for a message to reach that device from a starting point (e.g., the management center) and for a response to return. Id.; see id., col. 6, line 16 through col. 8, line 7. The parties agreed in the district court that the reliability of the devices along a route is inferable from a trace-route result. See J.A. 2030, 2430–33.
According to the specification, comparing trace-route results “will provide a hierarchical estimate of a plurality of most likely ‘electronically best performing’ ” nodes and routes. ’195 patent, col. 7, lines 12–14. Low latency or fewer hops (in evaluating nodes and routes) should be favored—the former improves the user experience, and the latter reduces inefficiencies associated with loss of data in transmission (“packet loss”). See id., col. 2, lines 36–46. The specification explains, for instance, that a particular node for ultimate client delivery (with a particular route to it) is “best ․ since the network latency is only 77 [milliseconds],” as compared to an alternative node (with an alternative route) having a latency of 189 milliseconds. Id., col. 8, lines 15–26; see id., col. 7, lines 42–55. But, in another exemplary comparison of trace routes, a route is “most efficient” not only because “latency is low,” but also because “the node is within one network hop to [the] client,” reducing “packet loss and unacceptable delay.” Id., col. 8, lines 27–42.
The specification further teaches that criteria other than those reported in trace-route results may be relevant to the analysis of which nodes or routes are best, but it does not explain which factors ought to be considered or how to balance them. For instance, having produced trace-route results, operators of the intelligent distribution network may “assign node-client mappings” (that is, select best nodes) with reference to “reasons intrinsic to their own operation such as time of day or other variances.” Id., col. 8, lines 56–58. And an index of “best performing” nodes for a given client may be compiled by weighing factors such as cost, “network bandwidth, historical performance, ․ and other factors constituting ‘quality of service’ attributes.” Id., col. 11, line 52 through col. 12, line 3.
For the ’426 patent, all independent claims—claims 1, 2, and 17—recite determining “best,” “best situated,” or “optimal” nodes or routes. ’426 patent, col. 17, line 32 through col. 18, line 16; col. 18, line 57 through col. 19, line 17. For the ’195 patent, independent claim 13 (on which claims 14–18 depend), independent claim 19, and dependent claim 2 have similar limitations. See ’195 patent, col. 17, lines 64–67; col. 18, lines 30–53; col. 19, lines 1–32. MediaPointe agreed at oral argument that there is “no meaningful difference” among those limitations for purposes of this appeal. Oral Arg. 12:51–13:06, https://www.cafc.uscourts.gov/oral-arguments/24-1571_10092025.mp3.
Independent claim 1 of the ’426 patent is representative for purposes of the indefiniteness issue before us:
1. A system comprising:
a management center;
a plurality of nodes configured to: relay a continuous stream of data from a content provider to a first client in response to an initial request for the continuous stream of data, replicate the continuous stream of data, and transmit the replicated stream of data to at least one other client;
wherein the management center comprises a mapping engine that is configured to map trace routes between the management center, at least one of the nodes, and at least the first client so as to determine one or more optimal routes from the management center to the first client via the at least one of the nodes, and configured to direct a node relaying the continuous stream of data from the content provider to the first client to replicate the continuous stream of data from the content provider, in response to subsequent requests for the continuous stream of data, while the node is relaying the continuous stream of data from the content provider to the first client, and transmit the replicated stream of data to the at least one other client in response to the subsequent requests for the continuous stream of data; and
wherein the management center is configured to downgrade lower priority clients from a higher quality of service network link to a less optimal network link when a higher priority client requests use of the higher quality of service network link.
’426 patent, col. 17, lines 32–59 (emphasis added).
Claims that lack such a limitation—claims 1, 3–4, and 6–7 of the ’195 patent—are at issue for the noninfringement question before us. Claim 1 is representative:
1. A method comprising:
[a] receiving an initial request for media content from a first client, the request being received by a management center;
[b] directing the first client to a node that is selected to relay a content stream from a content provider to the first client by using a mapping engine that maps trace routes between the management center, the node, and the first client, the first client being directed to the node by the management center;
[c] relaying the content stream from the content provider to the first client via the selected node;
[d] replicating the content stream for other clients during the relaying of the content stream at the selected node, in response to the subsequent requests for the media content from the other clients, the other clients connected to the selected node based on an identification that the selected node is already relaying the content stream from the content provider to the first client; and
[e] transmitting the replicated content stream from the selected node to at least one other client in response to the subsequent requests for the media content.
’195 patent, col. 17, lines 42–63 (emphasis added).
B
In September 2022, Akamai sued MediaPointe for a declaratory judgment of noninfringement of the ’426 and ’195 patents. The next month, MediaPointe counterclaimed for infringement of both patents. Akamai then counterclaimed for declaratory judgment of invalidity of all claims of both patents.
The issue of indefiniteness now before us arose during claim-construction proceedings, which resulted in a July 7, 2023 opinion of the district court. See Akamai Technologies, Inc. v. MediaPointe, Inc., No. 2:22-cv-6233, 2023 WL 7386057 (C.D. Cal. July 7, 2023) (Claim Construction Order). Akamai argued that the claim limitations reciting “best” or “optimal” routes or “best situated” nodes were indefinite. Id. at *4. MediaPointe argued that “optimal routes” should be construed to mean “a path determined to be among the most favorable under the circumstances based on one or more characteristics.” Id. at *4–5. It argued that the “optimal”/“best” limitations were not indefinite because the specification teaches a relevant artisan how to generate trace-route results and grounds the words “best” and “optimal” in the numerical, objective trace-route results, including latency, number of hops, and transmission reliability. Id.; see also J.A. 2028–30.
The district court held the pertinent claims to be indefinite, relying on the intrinsic record. Claim Construction Order, at *5–7. Although the court “presume[d]” that whether a route is optimal is “based on [ ] trace route results,” as MediaPointe had argued, the court concluded that the specification “fails to provide a procedure or any other detail explaining how to consistently use [ ] hop[, ]latency[, and] reliability information to determine ‘optimal/best’ routes.” Id. at *6. Further, the “expanded range of factors” listed in the specification as potentially relevant to compiling an index of best performing nodes (i.e., network bandwidth, historical performance, other quality of service indicators, and so on) “confirm[ed],” in the court's view, “that the specification does not include bounds for the terms ‘best’ and ‘optimal.’ ” Id. at *7 (citing ’426 patent, col. 11, line 45 through col. 12, line 22).
C
On June 22, 2023, shortly before the claim-construction order issued, MediaPointe served its final infringement contentions on Akamai. See J.A. 2918–19. After issuance of the Claim Construction Order, which invalidated various asserted claims, the parties proceeded with litigation over the surviving claims, specifically, claims 1, 3–4, and 6–7 of the ’195 patent. See id.; J.A. 104–14. Certain materially undisputed facts, explained in testimony by MediaPointe's technical expert Dr. Aviel Rubin and Akamai's technical expert Dr. James Kurose, frame the dispute about infringement resolved by the district court and now before us.
Akamai's Internet infrastructure, where the alleged infringement occurs, has three components relevant here: (1) Domain Name System (DNS) servers, (2) edge servers that relay media content to clients, and (3) a functionality called “Mapper.” See J.A. 3313–16 ¶¶ 46–52, 3607–10 ¶¶ 130–144 (both parties’ expert reports). The DNS servers carry out the Mapper functionality, but the edge servers do not. See J.A. 3362–64 ¶¶ 106–09 (Kurose report); J.A. 3697 (Rubin deposition); see MediaPointe Opening Br. at 64. A user who wants to obtain streamed media content enters a web address into the user's browser, and that action results in a DNS query being sent to Akamai's DNS servers (where Mapper functions are performed). J.A. 2653 (Rubin deposition); J.A. 3317–24 ¶¶ 54–61 (Kurose report). The DNS query asks the DNS servers to translate, into an IP address, the domain name that was part of the user-entered web address. J.A. 3374–75 ¶ 118 (Kurose report); J.A. 3607 ¶ 130 (Rubin report). Akamai's Mapper then assesses the user's location in order to identify nearby edge servers. J.A. 3329 ¶ 66 (Kurose report); J.A. 3608 ¶ 135 (Rubin report).
Critically, as MediaPointe's expert conceded, the DNS query in that process does not identify the content the user wants, and the DNS servers (hence Mapper) receive no other messages from the user's computer. See J.A. 2643–45, 2657 (Rubin deposition); Oral Arg. 17:15–27 (MediaPointe's counsel agreeing that “Mapper never knows what the specific content is”); J.A. 3373 ¶ 116 (Kurose report). The DNS servers send an IP address for an edge server selected by Mapper back to the user's computer, which uses the provided IP address to connect to the edge server. J.A. 3333–34 ¶ 72 (Kurose report); 3607 ¶ 131 (Rubin report). Finally, the user's computer sends a hypertext transfer protocol (HTTP) message to the edge server to request a data stream containing the content (i.e., a “content stream”), and it is that HTTP message which identifies the content the user wants to stream. J.A. 2657 (Rubin deposition); J.A. 3334–35 ¶ 73 (Kurose report). The edge server responds by providing the content stream. See J.A. 3335–36 ¶¶ 74–75 (Kurose report); 3607 ¶ 132 (Rubin report).
In its June 2023 final infringement contentions, MediaPointe specified an Akamai product called “Global Traffic Management” as being the “management center” required by claim 1 of the ’195 patent and performing the claimed method. J.A. 2923–27, 2929. Fact discovery closed on July 28, 2023, and MediaPointe served its opening expert report (the Rubin report) on Akamai on August 21, 2023. Akamai Technologies, Inc. v. MediaPointe, Inc., No. 2:22-cv-6233, 2024 WL 608015, at *1 (C.D. Cal. Jan. 3, 2024) (Exclusion Order). The Rubin report, unlike the June Final Infringement Contentions, opined that it was actually Mapper that was the management center of claim 1. See id. at *1–2; J.A. 2753–54 n.9, 2756 ¶ 167. That change from the previous reliance on Global Traffic Management gave rise to the untimeliness-based exclusion ruling now before us.
The Rubin report also elaborated on MediaPointe's theory of how Akamai's products satisfy ’195 limitation 1[a]. Dr. Rubin opined that the receipt of a DNS query by Mapper's DNS servers is a receipt of a request for media content within the meaning of that limitation, stating that “the end-user (a first client) initiates a request for content, for instance, by entering a [uniform resource locator (URL)] in his or her browser,” J.A. 3615 ¶ 166, and “ ‘Mapper’[ ] receives the request for content ․ [which] is initiated by a DNS query,” id. ¶¶ 167–68. When deposed on that point, Dr. Rubin explained his view that “a DNS query being received by the [M]apper [ ] related to [a] user's request ․is the [M]apper receiving the request for the content.” J.A. 2639; see also J.A. 2643 (“[I]n the context of a user making a request for content ․ that DNS query is also a request for content.”). But he also agreed that “a DNS query itself is not the request for content described in the ’195 patent,” J.A. 2629, and stated that a DNS query is not per se a request for content, noting that not every such DNS query results from a user's attempt to stream media content, see J.A. 2639–40.
On October 16, 2023, following Akamai's deposition of Dr. Rubin and production of its own technical expert report, Akamai moved under Rule 37(c) of the Federal Rules of Civil Procedure to strike the portions of Dr. Rubin's report accusing Mapper as untimely, Exclusion Order, at *1; J.A. 108, and, separately, moved for summary judgment of noninfringement of claims 1, 3–4, and 6–7 of the ’195 patent, Akamai Technologies, Inc. v. MediaPointe, Inc., 709 F. Supp. 3d 1058, 1060 (C.D. Cal. 2024) (Summary Judgment); J.A. 108. On January 3, 2024, the district court granted both motions. See Exclusion Order, at *1–2, 5; Summary Judgment, 709 F. Supp. 3d at 1060–61.
The district court's grant of summary judgment of non-infringement rested on two independent, alternative grounds. First, the court held that, because the portions of the Rubin report pertaining to Mapper had been stricken, MediaPointe had no evidence that Akamai's technology met limitation 1[a], so could not prove infringement. Id. at 1064–65. Second, the district court held that, even with the excluded infringement theory considered, MediaPointe's evidence failed to create a fact issue about whether Mapper meets limitation 1[a]. Id. at 1064–67.
Regarding the latter ground, Akamai argued that MediaPointe's evidence at most established that two messages—a DNS query and an HTTP request—go to Akamai's systems; that, of those two messages, only the DNS query goes to Mapper; and that Dr. Rubin had conceded that a “DNS query itself is not the request for content” of limitation 1[a], such that MediaPointe could not prove that Mapper receives a request for media content. J.A. 2592–93 (quoting J.A. 2629 (Rubin deposition)). MediaPointe, in opposition, argued that Akamai was belatedly arguing for a construction limiting “request for media content” to an HTTP message, when the term (like all terms not explicitly construed) was to receive its ordinary meaning. J.A. 3547–52; see Claim Construction Order, at *11. Further, according to MediaPointe, one ordinary sense of “request for media content” is a user entering a URL, and a request in that sense is “received” when “Mapper understands that the user has requested media content ․ [which is] ‘when the [M]apper receives a DNS query that's part of a request for content.’ ” Opposition to Akamai's Motion for Summary Judgment at 16, Akamai Technologies, Inc. v. MediaPointe, Inc., No. 2:22-cv-6233 (C.D. Cal. Oct. 30, 2023), ECF No. 152 (quoting J.A. 2641 (Rubin deposition)).
The district court rejected MediaPointe's arguments. Citing Dr. Rubin's testimony, the district court reasoned that “DNS queries, alone, cannot be the requests for media content” required by limitation 1[a]. Summary Judgment, 709 F. Supp. 3d at 1065 (citing J.A. 2628–29, 2645, 2653–54). And “no evidence show[ed] that [Akamai's] DNS servers, and thus Mapper, receive some other type of information that could comprise a request for media content.” Id. Indeed, the court found that the undisputed facts established that DNS servers cannot receive anything other than DNS queries. Id. at 1066–67 (citing J.A. 2628–29, 2653–54). Thus, the court found that there was no claim-construction question to resolve and granted summary judgment to Akamai because, even on MediaPointe's understanding of a request for media content as a user's entering a URL, MediaPointe's evidence failed to show how such a request is “received by a management center,” as required by limitation 1[a]. Id.; see id. at 1062.
The district court, on February 9, 2024, entered a final judgment of invalidity for indefiniteness of all claims of the ’426 patent and claims 2 and 13–19 of the ’195 patent, as well as a final judgment of noninfringement covering all remaining asserted claims of the ’195 patent. J.A. 1–3. It dismissed all remaining claims and counterclaims as moot. Id. MediaPointe timely appealed. We have jurisdiction under 28 U.S.C. § 1295(a)(1).
II
A
MediaPointe challenges the district court's holding that the claims containing the “optimal”/“best” claim limitations were invalid, under what is now 35 U.S.C. § 112(b), for indefiniteness. (The present case is governed by the pre-2011 provision, 35 U.S.C. § 112 ¶ 2 (2006), but the statutory standards remain the same.) We decide the issue de novo, as the district court's ruling, properly in this case, rested only on intrinsic evidence. Teva Pharmaceuticals USA, Inc. v. Sandoz, Inc., 574 U.S. 318, 331–33, 135 S.Ct. 831, 190 L.Ed.2d 719 (2015).
“[A] patent's claims, viewed in light of the specification ․,” must “inform those skilled in the art about the scope of the invention with reasonable certainty.” Nautilus, Inc. v. Biosig Instruments, Inc., 572 U.S. 898, 910, 134 S.Ct. 2120, 189 L.Ed.2d 37 (2014). The language at issue here plainly is language of degree with a facially discretionary standard. “[T]he written description is key to determining whether a term of degree is indefinite.” Sonix Technology Co. v. Publications International, Ltd., 844 F.3d 1370, 1378 (Fed. Cir. 2017). A term is not definite merely because the specification “identif[ies] some standard for measuring the scope of the [term].” Interval Licensing LLC v. AOL, Inc., 766 F.3d 1364, 1370–71 (Fed. Cir. 2014) (internal quotation marks and citation omitted) (emphasis in original). Language of degree, like the language at issue here, is indefinite unless, “when read in light of the specification and the prosecution history, [it] provide[s] objective boundaries for those of skill in the art.” Id. at 1371; see also Datamize LLC v. Plumtree Software, Inc., 417 F.3d 1342, 1350–51 (Fed. Cir. 2005). We conclude that, as the district court correctly held, the patents here do not give the required objective boundaries for determining what is “optimal” or “best.”
MediaPointe argues that the claims themselves define an objective standard for measuring what is optimal or best, because each such claim includes language requiring the use of trace routes. MediaPointe Opening Br. at 25–30 (citing Sonix, 844 F.3d at 1377–78); see, e.g., ’426 patent, col. 17, lines 40–44 (reciting “a mapping engine that is configured to map trace routes ․ so as to determine one or more optimal routes ․”). But that claim requirement is not enough. It “does not provide a reasonably clear and exclusive definition” of “optimal”/“best” or, therefore, provide “an objective boundary.” Interval Licensing, 766 F.3d at 1373 (emphasis added).
The requirement to use trace routes is, first of all, not exclusive. As a matter of ordinary syntax, the claims require considering at least, but not only, trace-route results. See, e.g., ’426 patent, col. 18, lines 65–67. The claims do not say that the only factors in determining what is optimal or best are trace-route results.
The specification explicitly confirms the absence of such a restriction. It states that, after generating trace-route results, but before “a client is assigned a ‘best’ or ‘nearest’ node,” an intelligent distribution network operator may consider “reasons intrinsic to their own operation such as time of day or other variances” in making such assignments. ’195 patent, col. 8, lines 43–61. Similarly, the specification discloses a “preferred embodiment” in which “ ‘best performing’ nodes” may be determined with reference to “various factors” not limited to trace-route results. Id., col. 11, line 52 through col. 12, line 3. Indeed, MediaPointe's own proposed claim construction before the district court illuminated the open-endedness of the inquiry. See Claim Construction Order, at *4 (acknowledging MediaPointe's proposed construction of “optimal routes” as “a path determined to be among the most favorable under the circumstances based on one or more characteristics” (emphases added)).
In addition, the requirement to rely in part on trace-route results—which report hops, latency, and (indirectly) reliability—itself is not “reasonably clear.” Interval Licensing, 766 F.3d at 1373. A claim term, even if it refers to certain objective measures, is indefinite if it “might mean several different things [but] no informed and confident choice is available among the contending definitions.” Id. at 1371 (quoting Nautilus, 572 U.S. at 911 n.8, 134 S.Ct. 2120). That is so here, where, although what route is best depends on hops, latency, and reliability, MediaPointe admits that the patent provides no guidance about which measure, or what combinations of measures, to rely on when they diverge. See J.A. 2414 (MediaPointe's counsel stating to the district court that the claims “just teach determining an optimal route based on mapping of trace routes”).
The specification itself shows that hops and latency, in a given case, could indicate different “best” routes. Individual devices along a route may have an “intrinsically slow response” or may be “heavily loaded with computational tasks.” ’195 patent, col. 7, lines 58–63. When a node fails, the specification instructs the operator to direct requests to the “next nearest node” in a fashion similar to selecting “the best performing nodes” to avoid “the problem node.” Id., col. 15, line 37 through col. 16, line 18. Those disclosures contemplate that the shortest path in hops may not have the lowest latency, and they provide guidance in the extreme case of a node failure to prioritize latency, but they are silent about what to do when a node is merely slow. See id.
We have repeatedly said that when “multiple methods” for determining whether a claim limitation is met “lead[ ] to different results without guidance ․ as to which method should be used,” the claim is indefinite. Dow Chemical Co. v. Nova Chemicals Corp. (Canada), 803 F.3d 620, 634 (Fed. Cir. 2015); see Teva Pharmaceuticals USA, Inc. v. Sandoz, Inc., 789 F.3d 1335, 1344–45 (Fed. Cir. 2015). MediaPointe identified no sufficient guidance. When the district court noted the apparent potential disparity between hops and latency results, MediaPointe speaking only through counsel, said only that the two metrics “tend to run together” and that an operator “would be looking at both.” J.A. 2413–14; see also J.A. 2411 (MediaPointe's counsel conceding to district court that hops, latency, and reliability “[in] any given instant ․ may not [ ] line up perfectly”). MediaPointe takes the same position on appeal. See MediaPointe Opening Br. at 35 (“[H]ops and latency typically rise and fall together.”). Those lawyer assertions do not erase the specification's suggestion that latency and hops may diverge, so do not solve the indefiniteness problem.
Finally, MediaPointe suggests, for the first time in its reply brief, that “it is not necessary to identify which of [hops, latency, or reliability] must be prioritized,” because any limitation containing an “optimal”/“best” term is met whenever “one maps and compares the outputs of trace routes to determine the ‘optimal’ or ‘best’ route.” MediaPointe Reply Br. at 5. That untimely argument is forfeited. See Norman v. United States, 429 F.3d 1081, 1091 n.5 (Fed. Cir. 2005) (“Arguments raised for the first time in a reply brief are not properly before this court.”); Oral Arg. at 5:07–6:25 (MediaPointe's counsel conceding that this is “another argument” beyond those made in its principal brief). Regardless, MediaPointe is wrong. Its reading of “optimal”/“best” nullifies those very terms—if one need only map and compare trace routes to infringe, “optimal” and “best” add nothing to the claim, a disfavored result. See, e.g., Bicon, Inc. v. Straumann Co., 441 F.3d 945, 950–51 (Fed. Cir. 2006) (“[C]laims are interpreted with an eye toward giving effect to all terms.”) (collecting cases). MediaPointe has thus failed to show that the district court erred in holding the “optimal”/“best” claim terms indefinite.
B
MediaPointe challenges the district court's grant to Akamai of summary judgment of noninfringement of the ’195 patent’s claims 1, 3–4, and 6–7. The grant of summary judgment rested on two independently sufficient grounds: (a) exclusion of necessary proposed testimony from Dr. Rubin; and (b) insufficiency of all the evidence even with Dr. Rubin's proposed testimony. MediaPointe challenges both grounds, and we may affirm the judgment of noninfringement on either ground. We determine that the district court did not err in holding that, even with Dr. Rubin's proposed testimony included, i.e., treating Mapper as the claim-required management center, the record did not create a genuine dispute of material fact. We do not reach the challenge to the exclusion order.
We review a district court's summary judgment ruling “under the law of the regional circuit, here, the Ninth Circuit,” Apple Inc. v. Wi-LAN Inc., 25 F.4th 960, 974 (Fed. Cir. 2022) (citation omitted), which reviews a “grant of summary judgment de novo, viewing the evidence in the light most favorable to the non-moving party and drawing all reasonable inferences in its favor,” Bell v. Wilmott Storage Services, LLC, 12 F.4th 1065, 1068 (9th Cir. 2021). We may affirm the judgment (though not expand the relief) on any ground supported by the record. See Atel Financial Corp. v. Quaker Coal Co., 321 F.3d 924, 926 (9th Cir. 2003); Glaxo Group Ltd. v. TorPharm, Inc., 153 F.3d 1366, 1370–71 (Fed. Cir. 1998).
MediaPointe's challenge on the issue we are deciding rests on the idea that the district court implicitly, and incorrectly, construed limitation 1[a] of claim 1 of the ’195 patent, which requires “receiving an initial request for media content from a first client, the request being received by a management center.” ’195 patent, col. 17, lines 43–45. But that limitation, under the unchallenged claim construction, was to be given its ordinary meaning. See Claim Construction Order, at *11. According to MediaPointe, there are two reasonable ordinary understandings of a “request for media content”: (1) “a user's attempt to access media content,” MediaPointe Opening Br. at 68, and (2) “a computing message, like an HTTP request,” id. at 70; see id. at 65. MediaPointe contends that the district court ignored the first understanding in favor of the second, narrower one. Id. at 67. When the term is given the broader of those understandings, MediaPointe asserts, relying on its expert testimony, that Mapper receives a client's request for content when it receives a DNS query “related to th[e] user's request” at the browser. Id. at 68 (citing J.A. 2639).
All of MediaPointe's noninfringement arguments on this ground thus hinge on the proposition that a “user's attempt to access media content”—rather than only a particular communication received by the management center—is within the ordinary meaning of limitation 1[a], as a relevant artisan would understand that limitation in context. MediaPointe Reply Br. at 30–31. The district court in substance concluded otherwise. We agree.
When a claim limitation, like the one at issue here, is not expressly construed, a jury is entitled to give that limitation any reasonable meaning in determining, as a factual matter, what comes within its scope. See VLSI Technology LLC v. Intel Corp., 87 F.4th 1332, 1341 (Fed. Cir. 2023) (citing Avid Technology, Inc. v. Harmonic, Inc., 812 F.3d 1040, 1048–49 (Fed. Cir. 2016), and Hewlett-Packard Co. v. Mustek Systems, Inc., 340 F.3d 1314, 1320–21 (Fed. Cir. 2003)). Here, therefore, the district court was required to give the issue before us to the jury only if “request for media content” can reasonably bear MediaPointe's relied-on meaning—a “user's attempt to access media content.”
We conclude, however, that a relevant artisan could not reasonably have understood the claim language, considered in the context of the patent, to refer to anything other than a computer message. The claimed “request for media content” must be “received by a management center.” ’195 patent, col. 17, lines 44–45. This is unmistakably language about messages, which are what are sent (or entered) and received. The message is one that somehow identifies content of interest (eventually to be delivered as a “stream”). It is not language about the activity of “attempts,” which are not “received by” a management center, even if a message successfully attempted to be sent could be received. The view now pressed by MediaPointe, if raised before the claim-construction stage of proceedings, would surely have provoked a dispute over the proper construction of the “request for media content” term. That it was not raised then, the matter being left to the ordinary meaning, see Claim Construction Order, at *11, is strong confirmation that there is no reasonable alternative in this context to understanding “request” to mean a computer message, not an “attempt.”
Specifically, the “attempt” MediaPointe identifies is the act of entering a URL into the browser, not the entered URL, see MediaPointe Opening Br. at 67–68, and the act of entering a URL is not received by any device, much less the management center. And even the URL that is entered does not equate conceptually, and may not equate in fact, to what is received by any device other than the one hosting the browser. Here, indeed, the evidence shows that a URL entered by a user into the browser is not received by Mapper at the DNS servers; it is received only by the browser, at which point various computing messages (including the DNS query and the HTTP request described above) begin going to and returning from devices other than the client's device. See J.A. 3317–18 ¶ 54–55 (Kurose report) (explaining that a DNS server receives only the domain name of a URL in a DNS query); J.A. 3615 ¶ 166 (Rubin report) (“[T]he domain name of the URL is translated by the mapping system[.]” (emphasis deleted)). In short, the term “received by a management center” confirms that “request” is limited to, at most, those types of things capable of being received by a management center, and as MediaPointe acknowledges, it is not the “user's attempt to access media content” at the browser, but a related DNS query, that reaches a management center. MediaPointe Opening Br. at 68.
MediaPointe makes one, elliptical, argument for its understanding of an “attempt” as an ordinary meaning of “request.” Interpreting “request for media content” as a computing message, it urges, would make the term equivalent to “request for a content stream,” which would be improper because “content stream” is used elsewhere in the claim but not in the phrase at issue here. See MediaPointe Opening Br. at 71–72. This argument is merit-less. There is no improper equating of different terms, as “request for media content” is a broad reference to the content the user wants, while “request for a content stream” identifies a form (“stream”) in which the content is delivered. And in any event, there is no basis for inferring that “request” is something other than a computer message sent and received.
The district court was therefore correct in finding no triable issue of fact, even considering Dr. Rubin's proposed testimony, over whether this claim element was met by the accused system and activity of Akamai.
III
For the foregoing reasons, we affirm the judgment of the district court.
AFFIRMED
Taranto, Circuit Judge.
Thank you for your feedback!
A free source of state and federal court opinions, state laws, and the United States Code. For more information about the legal concepts addressed by these cases and statutes visit FindLaw's Learn About the Law.
Docket No: 2024-1571
Decided: November 25, 2025
Court: United States Court of Appeals, Federal Circuit.
Search our directory by legal issue
Enter information in one or both fields (Required)
Harness the power of our directory with your own profile. Select the button below to sign up.
Learn more about FindLaw’s newsletters, including our terms of use and privacy policy.
Get help with your legal needs
FindLaw’s Learn About the Law features thousands of informational articles to help you understand your options. And if you’re ready to hire an attorney, find one in your area who can help.
Search our directory by legal issue
Enter information in one or both fields (Required)