Telecom Network Solutions, LLC v. AT&T Corp

Opinion

IN THE UNITED STATES DISTRICT COURT FOR THE EASTERN DISTRICT OF TEXAS MARSHALL DIVISION TELECOM NETWORK SOLUTIONS, LLC, § § Plaintiff, § CIVIL ACTION NO. 2:21-CV-00415-JRG v. § (LEAD CASE) § AT&T CORP., § AT&T COMMUNICATIONS LLC, § AT&T MOBILITY LLC, § AT&T MOBILITY II LLC, § AT&T SERVICES INC., § SPRINT SPECTRUM LLC § v. § § CIVIL ACTION NO. 2:21-CV-00416-JRG CELLCO PARTNERSHIP D/B/A § (MEMBER CASE) VERIZON WIRELESS, § § v. § § T-MOBILE USA, INC., T-MOBILE US, § CIVIL ACTION NO. 2:21-CV-00418-JRG INC. § (MEMBER CASE) § Defendants. § CLAIM CONSTRUCTION MEMORANDUM OPINION AND ORDER In the above-captioned consolidated patent cases, Plaintiff Telecom Network Solutions, LLC (“TNS”) alleges that Defendants AT&T, Corp., AT&T Communications LLC, AT&T Mobility LLC, AT&T Services Inc., Sprint Spectrum LLC, Cellco Partnership d/b/a Verizon Wireless, and T-Mobile USA, Inc. (collectively, “Defendants”) infringe certain claims of U.S. Patent RE47,813 (the “’813 Patent”). (See generally Dkt. No. 1.) The ’813 Patent is generally directed to networked computing, and more specifically “to a feedback loop for dynamic network resource allocation.” (’813 Patent at 1:20–22.) The parties dispute the scope of nine claim terms, several of which are related.1 The Court held a Markman hearing on January 30, 2023. (Dkt. No. 114; see also Dkt. No. 127.) Having considered the parties’ briefing and arguments of counsel during the hearing, the Court resolves the disputes as follows.

I. BACKGROUND In a one-paragraph Background section, the ’813 Patent explains that “[m]obile computing devices are increasingly being used to access content hosted on the Internet or other type of network. Different computing devices can be allocated different service levels, while at the same time network congestion can change unpredictably, thereby compromising allocated services levels.” (’813 Patent at 1:26–31.) The ’813 Patent generally describes avoiding compromised service levels by monitoring a shared network resource (e.g., transmission rate, number of sessions) and dynamically modifying the resource’s allocation according to service and billing profiles of the various devices. (See id. at Abstract.) The “dynamic modification” feature, which is central to the asserted claims, is described

with reference to FIG. 4 and FIG. 5 of the ’813 Patent. In FIG. 4, the method first determines if there is active traffic over a shared network resource associated with a group of devices. (See generally ’813 Patent at 7:41–8:20 (describing the method with respect to FIG. 4).) If so, the method receives “traffic profiles” for each device link. (Id.) The method then determines if the received “traffic profiles” can be accommodated according to the “service profiles” of the devices with the overall capacity of the shared network resource. (Id.)

1 The parties briefed a tenth term, “configured to,” but resolved their dispute prior to the hearing. (Dkt. No. 127 at 111:4–8.) 70 ( % ) Oy on" FF = 80-1 x \, 86-3 » GY LS 54-1 y a : « ge wevweenn onan ne er §4-2 (Ro J a meee, “mh +a 5 Le

The patent provides an example based on the system shown in FIG. 1 (above): [A]ssume that base station 58 is capable of sending data to all devices 54 connected to base station 58 at a maximum bit rate of twenty megabits per second. Now assume that all devices 54 each have a service profile that guarantees each device 54 a maximum bit rate of five megabits per second. Now assume that each device 54 has requested content 92 that fully consumes the maximum bit rate of five megabits per second. In this example, contention will not exist, as base station 58 will be able to provide the demanded full fifteen megabits per second... (813 Patent at 8:21-32.) If, however, the received traffic profiles cannot be accommodated, the method dynamically modifies the service profiles or billing profiles (or both) as necessary. (See, id. at 2:23-39.) As an example, the method might automatically reduce the maximum guaranteed bit rate for one or more devices until such time as the collective demand on the resource allows re-establishing the devices’ default service profiles. (See id. at 9:4—9, 9:23-36.) FIG. 5 “shows another method for dynamic resource allocation.” (813 Patent at 2:50-51.)

The figure is identical to FIG. 4 except for the addition of Steps 331a and 332a. In Step 331a, the method “determin[es] if there is extra capacity available over a given shared network resource.” (Id. at 9:55–57.) If so, Step 332a “modifies the the service or billing profile or both to utilize the extra available capacity.” (Id. at 10:24–25.) If there is not extra capacity available, the method

implements the same “managing step” (Step 335a) described with reference to FIG. 4. (Id. at 10:38–39 (“Block 335a then functions in the same manner as block 335.”).) The ’813 Patent includes both method and system claims directed to dynamic resource allocation. Claim 1, which is representative of the ’813 Patent’s independent method claims, recites: 1. A method for dynamic allocation of network resources comprising: receiving a service profile for each of a plurality of devices sharing a network resource; receiving a billing profile for each of said plurality of devices; generating a prioritization list defining an order of said plurality of devices, based on said billing profiles and on a billing history for each of said plurality of devices; repeating: receiving traffic profiles over said network resource for said plurality of devices; managing said network resource according to said service profile and said billing profile if said network resource is fully utilized by said traffic profiles; and, selecting at least one of said devices based on said prioritization list and dynamically modifying at least one of said service profile and said billing profile for said selected devices, if said network resource is under-utilized by said traffic profile or if said network resource would be over-utilized by said traffic profiles; until said plurality of devices no longer continue to share said network resource; and when said plurality of devices are no longer sharing said network resource, clearing said prioritization list. (’813 Patent at 14:30–55.) Claim 10, which is representative of the ’813 Patent’s structural independent claims, recites an apparatus with a network interface and processor collectively configured to perform the same steps recited in Claim 1: 10. An apparatus for dynamic allocation of network resources comprising: a network interface configured to receive a service profile for each of a plurality of devices sharing a network resource and to receive a billing profile for each of said plurality of devices; and a processor connected to said network interface and configured to generate a prioritization list defining an order of said plurality of devices, based on said billing profiles and on a billing history for each of said plurality of devices; said processor further configured to repeat: receiving traffic profiles over said network resource for said plurality of devices; managing said network resource according to said service profile and said billing profile if said network resource is fully utilized by said traffic profiles; and, selecting at least one of said devices based on said prioritization list and dynamically modifying at least one of said service profile and said billing profile for said selected devices, if said network resource is under- utilized by said traffic profile or if said network resource would be over-utilized by said traffic profiles; until said plurality of devices no longer continue to share said network resource; and said processor further configured, when said plurality of devices are no longer sharing said network resource, to clear said prioritization list. (Id. at 15:19–48.) The parties dispute the scope of nine terms or phrases. With regard to three terms—“service profile,” “billing profile,” and “traffic profile”—the parties effectively dispute the meaning of “profile.” As to three other terms, they dispute what it means to over-, under-, or fully utilize a network resource. They also dispute the scope of “billing history.” Finally, the parties dispute whether the same processor or processors perform all recited functions attributed to “a processor” in Claims 10 and 37.

II. GENERAL LEGAL STANDARDS “[T]he 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). As such, if the parties dispute the scope of the claims, the court must determine their meaning. See, e.g., Verizon Servs. Corp. v. Vonage Holdings Corp., 503 F.3d 1295, 1317 (Fed. Cir. 2007); see also Markman v. Westview Instruments, Inc., 517 U.S. 370, 390 (1996), aff’g, 52 F.3d 967, 976 (Fed. Cir. 1995) (en banc). Claim construction, however, “is not an obligatory exercise in redundancy.” U.S. Surgical Corp. v. Ethicon, Inc., 103 F.3d 1554, 1568 (Fed. Cir. 1997). Rather, “[c]laim construction is a

matter of [resolving] disputed meanings and technical scope, to clarify and when necessary to explain what the patentee covered by the claims . . . .” Id. A court need not “repeat or restate every claim term in order to comply with the ruling that claim construction is for the court.” Id. When construing claims, “[t]here is a heavy presumption that claim terms are to be given their ordinary and customary meaning.” Aventis Pharm. Inc. v. Amino Chems. Ltd., 715 F.3d 1363, 1373 (Fed. Cir. 2013) (citing Phillips, 415 F.3d at 1312–13). Courts must therefore “look to the words of the claims themselves . . . to define the scope of the patented invention.” Id. (citations omitted). The “ordinary and customary meaning of a claim term is the meaning that the term would have to a person of ordinary skill in the art in question at the time of the invention, i.e., as of the

effective filing date of the patent application.” Phillips, 415 F.3d at 1313. This “person of ordinary skill in the art is deemed to read the claim term not only in the context of the particular claim in which the disputed term appears, but in the context of the entire patent, including the specification.” Id. Intrinsic evidence is the primary resource for claim construction. See Power-One, Inc. v. Artesyn Techs., Inc., 599 F.3d 1343, 1348 (Fed. Cir. 2010) (citing Phillips, 415 F.3d at 1312). As to certain claim terms, “the ordinary meaning of claim language as understood by a person of skill in the art may be readily apparent even to lay judges, and claim construction in such cases involves little more than the application of the widely accepted meaning of commonly understood words.” Phillips, 415 F.3d at 1314; see also Medrad, Inc. v. MRI Devices Corp., 401 F.3d 1313, 1319 (Fed.

Cir. 2005) (“We cannot look at the ordinary meaning of the term . . . in a vacuum. Rather, we must look at the ordinary meaning in the context of the written description and the prosecution history.”). As for claim terms with less apparent meanings, courts consider “those sources available to the public that show what a person of skill in the art would have understood disputed claim language to mean . . . [including] the words of the claims themselves, the remainder of the specification, the prosecution history, and extrinsic evidence concerning relevant scientific principles, the meaning of technical terms, and the state of the art.” Id. III. THE LEVEL OF ORDINARY SKILL IN THE ART The level of ordinary skill in the art is the skill level of a hypothetical person who is presumed to have known the relevant art at the time of the invention. In re GPAC, 57 F.3d 1573, 1579 (Fed. Cir. 1995). In resolving the appropriate level of ordinary skill, courts consider the types and solutions to problems encountered in the art, the speed of innovation, the sophistication of the technology, and the education of workers active in the field. Id. Importantly, “[a] person of ordinary

skill in the art is also a person of ordinary creativity, not an automaton.” KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 421 (2007). Here, neither party proffers a level of ordinary skill at the time of the invention directly in their briefing. However, TNS’s expert contends a skilled artisan at the time of invention “would be a person with a bachelor’s degree in electrical engineering, computer engineering, computer science, or related field, as well as two or more years of relevant professional experience, including in wireless communication networks.” (Dkt. No. 99-1 ¶ 17.) Defendants’ expert proposes a similar level of skill: [A skilled artisan] in December 2009 would have at least a bachelor’s degree in electrical engineering or a closely-related field, such as computer engineering or computer science. In addition, a POSA would have several years of experience in designing and developing telecommunications networks, systems, equipment, and/or components. (Dkt. No. 99-2 ¶ 22.) The Court sees no material differences between these levels of skill, nor does any party contend the Court must resolve any such differences to arrive at the correct constructions of the disputed terms. IV. THE DISPUTED TERMS A. “service profile” (Claims 1, 2, 10, 11, 18, 25, 27, 32, 34, 35, 37, 41, 42) TNS’s Construction Defendants’ Construction “a set of one or more traffic parameters or “the set of parameters or attributes that attributes that regulate traffic to and/or from a regulates traffic to and from a device” device” Collectively, the parties brief three disputes about this term. First, must a “service profile” have multiple parameters or attributes that regulate traffic? (See Dkt. No. 99 at 4–6.) Second, must the “service profile” parameters regulate traffic both to and from a device? (Id. at 6–7.) Third, can a device have more than one service profile? (Dkt. No. 106 at 5.) As to the first two disputes, which TNS presents, “Defendants agree that, theoretically, the claims permit a service profile with only one parameter that regulates traffic to or from a device.” (Id. at 6) (emphasis added). Such statement resolves the dispute between the parties about the direction of traffic to be regulated. The third issue, raised by Defendants and having to do with the number of service profiles per device, is more involved. Defendants contend that, “[w]hen a service profile has more than one parameter that regulates traffic to and from a device, all of those parameters constitute the service profile.” (Dkt. No. 106 at 6–7.) This means, they say, each device is associated with a unique “service” and “billing” profile. (Id. at 1; see also id. at 4 (“a service profile 96 for regulating device traffic, unique to each device, is stored in policy server 70”).) Resolving this issue requires resolving the difference, if any, between “profile” and “one or more parameters.” To start, the extrinsic evidence supports Defendants’ position that a service parameter is not per se a “service profile.” According to technical dictionaries submitted by Defendants, a profile is “[d]ata that describes the significant characteristics of . . . one or more computer resources.” (IBM Dict. of Comput., Dkt. No. 106-1 at 534 (emphasis added); see also Newton’s Telecom Dict., Dkt. No. 106-2 at 482 (defining “profile” as “[a] set of parameters defining the way a device acts.”).) Thus, the plain and ordinary technical meaning of “profile”—a t least outside the context of the ’813 Patent and to those who would consult such dictionaries— includes the relevant characteristics of the “profiled” resource or device. Notably,

that understanding is consistent with the lay understanding of a “profile”: “an overview about a person or thing.” (See, e.g., https://www.yourdictionary.com/profile (last visited Feb. 9, 2023).) As to “service profile” specifically, the evidence is consistent with such understanding. The specification does not define what a profile must be, but instead enumerates various parameters it can include. (See ’813 Patent at 5:46–47 (noting “[e]ach service profile 96 can thus include any traffic parameter that regulates traffic to and from device 54”); see also id. at 6:64–66 (noting “a plurality of different attributes can be used to define various service profiles”).) In fact, TNS cites extrinsic evidence that further supports this idea. (See Dkt. No. 99 at 7 (citing Identity Mgm’t, Dkt. No. 99-7 at 155).) Specifically, the cited document explains “[e]ach IMPU gets allocated exactly one Service Profile” and “the Service Profile defines the services a

user may currently use.” (Identity Mgm’t, Dkt. No. 99-7 at 155.) That each device gets allocated exactly one service profile runs counter to TNS’s contention that relevant parameters or attributes may be distributed across multiple profiles. (See ’813 Patent at Abstract (describing “a plurality of electronic devices having unique service profiles and unique billing profiles”).) Such understanding is also consistent with the presumption that different claim terms have different meanings, as “attribute” is used elsewhere in the claims with “profile.” (See, e.g., ’813 Patent at 16:23–25 (reciting, in Claim 17, “determining and receiving traffic profiles indicating attributes of current traffic activity over said network resource by said plurality of devices”); see also id. at 17:17–21 (reciting similar language in Claim 27); id. at 18:11–13 (Claim 34); id. at 19:34–36 (Claim 41); id. at 20:24–23 (Claim 42).) In its brief, TNS asserts Claim 18 and Claim 27 only require the “service profile” to include one parameter or attribute, but TNS misreads those claims. (See Dkt. No. 99 at 4–5.) At most, Claim 18 requires the service profile to include a “guaranteed bit rate” parameter. (’813 Patent at

16:35–37.) Similarly, Claim 27 requires the service profile to include a “restriction on communication” parameter, but does not limit the service profile to only that parameter. (Id. at 17:31–33.) As further support, TNS points to the specification’s statement that “[e]ach service profile 96 can thus include any traffic parameter that regulates traffic.” (Dkt. No. 99 at 5 (quoting ’813 Patent at 5:46–47).) However, nothing about that statement requires limiting “service profile” to a single parameter or suggests a device can have multiple service profiles. Regardless, Defendants concede there are situations in which the service profile consists of one parameter. TNS makes two similar arguments in its reply, but neither is persuasive. First, TNS notes that Claim 1 recites “receiving a service profile for each of a plurality of devices,” and contends

that because “a” means “one or more,” the claims allow multiple service profiles per device. (Dkt. No. 109 at 1.) Second, TNS argues Defendants’ construction excludes a preferred embodiment because “the default service profile(s) [can] be re-established for each device,” which suggests a single device can have multiple profiles. (Id. (citing ’813 Patent at 9:29–30).) Neither statement, however, speaks to what a “service profile” is, and nothing about Defendants’ position is inconsistent with the claim language. Defendants’ position does not exclude service profiles from being re-established, replaced, or amended, but there is only one service profile active for a device at any time. In sum, the Court agrees with Defendants that a “service profile” for a device is the set of parameters and attributes that regulate traffic with that device, regardless of how many such parameters or attributes there may be. Further, the Court agrees with Defendants that a parameter or attribute is not per se a “profile.” That said, the claims do not exclude receiving multiple profiles for a device, such as if the same service profile were to be received more than once. Accordingly,

the Court construes “service profile” as “a set of one or more traffic parameters or attributes that regulates traffic to and/or from a device.” B. “billing profile” (Claims 1, 10, 18, 27, 34, 37, 41, 42) TNS’s Construction Defendants’ Construction “a set of one or more billing parameters or “the set of billing parameters or attributes that attributes that regulates rating or charging or regulates rating or charging or both of traffic to both of traffic to and/or from a device” and from a device” The parties’ arguments regarding this term track those made with respect to “service profile.” (See Dkt. No. 99 at 8–9; Dkt. No. 106 at 7.) For the same reasons set forth supra in Part IV.A, and following the same reasoning, the Court construes “billing profile” as “a set of one or more billing parameters or attributes that regulates rating or charging or both of traffic to and/or from a device.” C. “billing history” (Claims 1, 10, 18, 27, 34, 37, 41, 42) TNS’s Construction Defendants’ Construction “historical charges, usage and payments for a “past charges, usage and/or payments” device” Claim 1 requires “generating a prioritization list defining an order of said plurality of devices, based on said billing profiles and on a billing history for each of said plurality of devices.” (’813 Patent at 14:36–28) (emphasis added). The other independent claims have similar limitations. (See, e.g., id. at 15:25–29 (reciting, in Claim 10, an apparatus configured to generate a priority list based in part on “a billing history for each of said plurality of devices”).) The ’813 Patent uses this term only in two paragraphs near the end of the specification. In those paragraphs, which reference FIG. 1 and FIG. 6, the ’813 Patent explains: Block 415 comprises receiving billing profile and billing history information for the currently indexed device. . . . The billing history can span any predefined prior period—in months or years. Typically, more recent billing history will be selected. The billing history identifies historical charges, usage and payments (either post- paid or pre-paid) for device 54-1. . . . Block 420 comprises generating a metric for the currently indexed device. . . . The metric is based on a meta-analysis of the billing history, and, where provided, also the billing profile 100 and service profile 96 for the device 54. A higher metric can be generated where a device 54 shows a billing history consistent with prompt payments, or payments that exceed a certain threshold, or indicative of a longer billing history. Conversely a lower metric can be generated for a billing history consistent with slow payments, or payments below a certain threshold, or indicative of a shorter billing history. . . . A higher metric can be applied where a billing history indicates a usage of a particular service that is above a certain threshold. (’813 Patent at 11:17–54) (emphasis added). In other words, devices associated with prompt payments, large payments, or long-term customers get priority over devices associated with slow payments, small payments, or new customers. The parties have two disputes regarding this term. First, they dispute whether “billing history” requires an actual bill. Second, they dispute whether “billing history” requires all of “charges, usage and payments.” 1. Whether “billing history” excludes charges or usage not yet been billed Defendants accuse TNS of ignoring the plain language of the term and expanding its meaning to include usage that has not yet been billed. (Dkt. No. 106 at 7.) Defendants also contend that the specification defines this term as “historical charges, usage and payments,” and that “historical” in this supposed definition requires the “billing history” to “relate[] to time periods that actually have been billed and money (paid in advance or after billing) that has been applied to the usage.” (Id. at 8 (citing ’813 Patent at 11:25–27).) TNS stresses that there no mention of a “billing cycle” in the specification, and argues that nothing in the intrinsic record prohibits billing history from including charges, usage, or payments in a current billing cycle. (Dkt. No. 109 at 3.)

The Court agrees with TNS for two reasons. First, the language at column 11, lines 25–27 is not lexicography. To define a term, the application must clearly set forth a definition. Thorner v. Sony Comput. Entm’t Am. LLC, 669 F.3d 1362, 1365 (Fed. Cir. 2012). Here, the cited excerpt only refers to a specific device in an exemplary embodiment. Thus, the excerpt does not clearly show intent to define the term for all embodiments. Second, a skilled artisan at the time of invention would not understand “billing history” in the limited manner suggested by Defendants. Given the field’s highly technical nature, it would have been known to track real time usage, payments, and charges regardless of whether bills had yet been sent. Accordingly, the Court remains unconvinced the plain and ordinary meaning of “billing history” at the time of invention required actual bills. (See, e.g., PACER User Manual

(Apr. 2022),2 at 5 (showing a user of the system can login and review recent charges that will appear on the next bill, which falls under the system’s “Billing History” heading).) The Court therefore concludes “billing history” does not exclude charges, usage, or payments that have not yet been billed. 2. Whether “billing history” must include each of charges, usage, and payments Again relying on the alleged definition at column 11, lines 25–27, Defendants argue that

2 Available at https://pacer.uscourts.gov/sites/default/files/files/PACER-User-Manual.pdf (last visited Feb. 9, 2023). “billing history” requires charges, usage, and payments. (Dkt. No. 106 at 9.) The Court disagrees for two reasons. First, as noted supra, this excerpt is not definitional. Second, as the specification explains, prioritization of devices could be based on “prompt payments, or payments that exceed a certain threshold, or . . . a longer billing history.” (’813 Patent at 11:31–54) (emphasis added).

Such suggests that any billing history that provides the information necessary for determining prioritization is sufficient, provided it is actually connected to billing. There is no technical reason why priority based only on promptness of payment must include, for example, usage. The Court adopts TNS’s construction with one caveat. While “charges” and “payments” are inherently part of “billing history,” “usage” is not. An application may, for example, record usage history even if it is not necessary for or otherwise associated with billing. The Court therefore clarifies the proper interpretation of the disputed term excludes any “usage” untethered from billing. D. “traffic profile” (Claims 1, 4, 7, 9, 10, 13, 14, 18, 21, 26, 27, 29, 33, 34, 36, 37, 40–42) TNS’s Construction Defendants’ Construction “a set of one or more parameters or attributes “the set of parameters or attributes of traffic of traffic activity over the network resource” activity” The parties have two disputes about the “traffic profile” term. First, unlike their position concerning the other “profile” terms, Defendants argue a “traffic profile” must include more than one parameter. (Dkt. No. 106 at 10.) To support their argument, Defendants first rely on the specification’s explaination that: [W]here service profile 96 data includes restrictions on access to a given type of content 92, then traffic profile information at block 325 will include an identification of a type of content 92 that is being requested. Traffic profile data also includes more than the type of content 92 that is being requested, but also includes the actual data volumes, data rates and content being carried . . . . (Dkt. No. 106 at 10–11 (quoting ’813 Patent at 7:66–8:7).) The quoted language, however, refers to a specific embodiment in which the “traffic profile” content types are a function of the “service profile” content types. Thus, this excerpt does not require “traffic profile” in all embodiments to

always include multiple parameters. Defendants next rely on the same technical definitions cited for support of their constructions of the other “profile” terms. (Dkt. No. 106 at 11.) However, such definitions do not clearly exclude embodiments in which only one significant characteristic defines how a device acts. Finally, during the hearing, Defendants argued that the claims themselves require multiple parameters. In Claim 1, for example, Defendants argued that the “managing” step requires the traffic profiles to provide actual utilization, and the “dynamically modifying” step requires the traffic profiles to provide the requested utilization. (Dkt. No. 127 at 27:17–30:5; see also Dkt. No. 116 at 11.) While that may be correct, the issue before the Court is the plain meaning of “traffic

profile” without regard to how it may be further limited by the claim language. The second dispute about this term concerns the “over the network” language in TNS’s proposed construction. Defendants suggest that TNS is attempting to exclude limitations, and that “over the network” should be omitted or “for said plurality of devices” should be included. (Dkt. No. 106 at 11–12.) During the hearing, however, Defendants represented there is no dispute that the traffic profiles refer to the traffic activity regarding the shared resource. (Dkt. No. 127 at 30:7– 21.) Given the apparent lack of dispute about scope on this issue, the Court finds little potential for confusion from including “over the network.” The Court rejects the notion a “traffic profile” must have multiple parameters or attributes. Accordingly, the Court adopts TNS’s construction for this term—“a set of one or more parameters or attributes of traffic activity over the network resource”—but reiterates that a parameter or attribute is not per se a “profile.” E. “is fully utilized by” / “fully utilizes” / “full utilization” (Claims 1, 6, 9, 10, 18, 27, 34, 37, 41, 42) “would be over-utilized by” (Claims 1, 7, 10, 13, 18, 26, 27, 33, 34, 36, 37, 40–4 2) “is under-utilized by” / “would be under-utilized by” (Claims 1, 4, 10, 14, 18, 27, 33, 34, 36, 37, 41, 42) TNS’s Construction Defendants’ Construction “is fully utilized by” / “fully utilizes” / “full utilization”: “has no additional capacity due to”

“would be over-utilized by”: “will exceed maximum capacity in the future due to”

No construction necessary beyond plain and “is under-utilized by”: “has some capacity ordinary meaning remaining due to”

“would be under-utilized by”: “will have some capacity remaining in the future due to”

If Defendants’ constructions are not adopted, these terms are indefinite. Claim 1 recites “managing said network resource according to said service profile and said billing profile if said network is fully utilized by said traffic profiles,” but “dynamically modifying at least one of said service profile and said billing profile for selected devices, if said network resource is under-utilized . . . or if said network resource would be over-utilized by said traffic profiles.” (’813 Patent at 14:42–51.) Each independent claim includes similar language. The parties dispute what constitutes full, over-, and under-utilization and how such utilization must be measured. More specifically, the parties dispute whether the proper measure of “utilization” is “capacity” or “contention.” Defendants claim utilization must be measured by capacity. Citing to various excerpts from the specification, Defendants contend “[i]f no extra

capacity is available, then the resource is ‘fully utilized.’” (Dkt. No. 106 at 12–13.) TNS, on the other hand, argues for a construction based on “contention” between devices for the resource. (Dkt. No. 99 at 17–18 (citing technical dictionaries defining “contention” as the point where there is competition for network resources).) TNS criticizes Defendants’ construction for conflating “fully utilized” with “100% capacity.” (Id.) The ’813 Patent references “contention” only a handful of times. When describing FIG. 1, the specification explains that the system “can be scaled to hundreds or thousands of base stations 58 or other network access points where a plurality of links, such as links 84, share a common physical network resource, such that contention for that resource between a plurality of devices 54 is possible.” (’813 Patent at 7:22–27) (emphasis added). When describing FIG. 4, the ’813

Patent explains that “contention will not exist” when the base station can provide the full demanded bit rate required by the service profiles. (Id. at 8:21–32.) However, “contention will exist” if the base station cannot provide the full demanded bit rate. (Id. at 8:54–67.) If the traffic profiles cannot be accommodated, the method dynamically modifies the service profiles “to accommodate contentions,” such as by “automatically reducing the maximum guaranteed bit rate . . . to a lower maximum guaranteed bit rate such that the contention is resolved.” (Id. at 9:1–9) (emphasis added). Finally, the ’813 Patent provides an example with reference to FIG. 1 and FIG. 5 in which the method decides whether extra capacity is available: [A]ssume that device 54-1 and device 54-2 has requested content 92 that fully consumes the maximum bit rate of five megabits per second. Now assume that device 54-n has requested content 92 that is best provided at a rate of seven megabits per second. In this example, no contention will strictly exist, as base station 58 will have excess capacity according to the service profile 96 but at the same time base station 58 will have capacity to provide seven megabits per second for device 54-n, even though device 54-n is not, by default entitled to it. (Id. at 9:58–10:6) (emphasis added). The specification uses the term “capacity” more frequently than the term “contention,” often in connection with “use” or “utilization.” For example, the Summary section explains: The dynamically modifying can also comprise increasing an overall bit-rate cap or data volume cap for the one of the devices at the first end of the list. . . . The increasing can be configured to fully utilize a remainder of a capacity of the network resource. (Id. at 2:4–11) (emphasis added). Similarly: The dynamically modifying can comprise decreasing an overall bit-rate cap or data volume cap for the one of the devices at the first end of the list. The decreasing can be configured to bring the traffic profiles into alignment with full utilization of a capacity of the network resource. (Id. at 2:16–21.) When describing FIG. 4, the ’813 Patent explains: In general, block 335 includes an assessment as to whether the overall capacity of the shared network resource between devices 54 and base station 58 (or any other shared resource or network element in network or link 66-1 that supports the delivery of services to devices 54) can actually accommodate the traffic profiles in a manner 20 consistent with the service profiles. (Id. at 8:13–20) (emphasis added). For example, a given network resource such as a media server can be determined 40 to have a maximum capacity of supporting twenty video streaming sessions simultaneously to devices 54 irrespective of the absolute aggregate bandwidth in megabits per second. (Id. at 8:38–42) (emphasis added). Further, when discussing FIG. 5, the ’813 Patent explains that “[a] ‘yes’ determination at block 331a leads to block 332a, which comprises modifying the service or billing profile or both to utilize the extra available capacity.” (Id. at 10:23–25) (emphasis added).

From these excerpts, the Court concludes that a construction based on “capacity” is better than one based on “contention.” The ’813 Patent consistently associates “use” and “utilization” with “capacity” rather than “contention.” It explains the methodology assesses (i.e., measures) the overall capacity of the resource. (Id. at 8:13–20 (noting “block 335 includes an assessment as to whether the overall capacity of the shared network resource between devices 54 and base station 58”).) In contrast, the specification and extrinsic evidence show that “contention” is a state or characteristic of the devices rather than the shared resource. (See, e.g., Microsoft Comput. Dict., Dkt. No. 99-9 (defining “contention” on a network as “competition among nodes for the opportunity to use a communications line or network resource”); Commc’ns Standard Dict., Dkt. No. 99-10 (defining “contention” as “competition by users of a system for the use of the same

facility at the same time”); Modern Dict. of Elecs., Dkt. No. 99-11 (defining “contention” as “competition for use of the same communication facilities”).) TNS makes several arguments against a “capacity”-based construction, but they are not persuasive. First, TNS argues that Defendants’ construction wrongly conflates “fully utilized” with “100% capacity,” by explaining that networks are not intended to regularly reach absolute physical capacity where 100% of the network’s resources are used. (Dkt. No. 99 at 19 (noting “network operators reserve a certain amount of capacity for high-priority traffic”).) However, nothing in the claims requires an assessment of “physical capacity.” Instead, the utilization state is based on service profiles for the devices, and nothing in the patent suggests the “service profiles” must be at the “physical capacity” of the network. TNS also argues a lay person would understand the meaning of “fully utilized.” (Dkt. No. 99 at 19.) TNS analogizes to a briefcase that may be considered full even if it can accommodate more paper, and a glass of water that may be considered full even though it may be able to hold

more water. (Id.) These analogies ignore the context provided by the specification and the highly technical field to which it pertains. Here, the claimed inventions must decide when to undertake the recited “dynamic modification” according to some objective threshold like bit rate, the number of available streams, or a data cap. In short, “capacity” is a measure of the network resource, whereas “contention” is a state of the devices competing for that resource. The Court therefore adopts Defendants’ constructions for these terms. F. “dynamically modifying . . . if . . . or if” (Claims 1, 4, 7, 10, 13, 14, 18, 27, 34, 37, 41, 42) TNS’s Construction Defendants’ Construction Ordinary and customary meaning, i.e., the No construction necessary beyond plain and over-utilization or under-utilization of the ordinary meaning shared network resource causes an active step of dynamically modifying Each of the independent claims recites “dynamically modifying” service profiles and billing profiles “if said network resource is under-utilized by said traffic profile or if said network resource would be over-utilized by said traffic profile.” (See, e.g., ’813 Patent at 14:47–51 (Claim 1).) The apparatus claims recite this limitation in connection with a specifically configured processor: 10. An apparatus for dynamic allocation of network resources comprising: a network interface configured to receive a service profile [and a billing profile] for each of a plurality of devices sharing a network resource . . . ; and a processor connected to said network interface . . . ; said processor further configured to repeat: . . . selecting at least one of said devices . . . and dynamically modifying at least one of said service profile and said billing profile for said selected devices, if said network resource is under-utilized by said traffic profile or if said network resource would be over-utilized by said traffic profiles . . . . Id. at 15:19–43 (emphasis added). There are two disputes about this language. The first dispute relates to Defendants’ inclusion of “an active step” in their proposed construction. Defendants intended this language to address TNS’s possible argument that “the claims may be satisfied so long as dynamic modification occurs at the same time as a claimed condition, even if the dynamic modification occurs coincidentally and in a manner completely untethered from the presence of the condition.” (Dkt. No. 106 at 20–21.) However, TNS “does not contend this limitation can be satisfied merely by dynamic modification coincidentally occurring at the same time as a claimed condition.” (Dkt. No. 109 at 8.) During the hearing, TNS suggested Defendants might be attempting to limit the type of causation, which Defendants denied. (See generally Dkt. No. 127 at 84:24–87:21; see also id. at 93:10–94:1.) Given the parties’ statements both in the briefing and at the hearing, the Court sees no dispute regarding this limitation and thus no need to include Defendants’ “active step” language in any construction. The second dispute concerns whether an apparatus covered by the claims must be capable of “dynamically modifying” under both stated conditions. Defendants first raised the issue when attacking a claim differentiation argument made by TNS: TNS’s claim differentiation arguments are based on a mischaracterization of Defendants’ position and are irrelevant. Defendants’ construction does not require that dynamic modification must occur in every instance in which the network resource is over- or under-utilized. Rather, for the apparatus claims, the claims require the apparatus have the capability to both: (1) dynamically modify the service/billing profiles if the network resource is under-utilized; and (2) dynamically modify the service/billing profiles if the network resource would be over-utilized. For the method claims, the claims require actual performance of each claimed method step. (Dkt. No. 106 at 23) (internal citations omitted). To support their argument, Defendants rely on Interdigital Tech. Corp. v. Lenovo Holding Co., 2021 WL 1856937 (D. Del. May 10, 2021), and Lincoln Nat. Life Ins. Co. v. Transamerica Life Ins. Co., 609 F.3d 1364, 1370 (Fed. Cir. 2010). In its reply, TNS apparently disagrees, although it presents the issue as ancillary to the underlying question of whether Defendants’ “active step” language should be adopted. (Dkt. No. 109 at 9.) TNS contends the apparatus claims cover a device with a processor configured to dynamically modify service and billing profiles even if only one of the conditions is met. As an example, in TNS’s view, Claim 10 would read on an apparatus with a processor configured to perform the dynamic modification if the network resource is over-utilized but not configured to perform the dynamic modification if the resource is under-utilized. At the hearing, TNS criticized Defendants’ position as treating the “or” in the disputed phrase as “and.” (Dkt. No. 127 at 88:19–92:11.) In response, Defendants cited Hytera Commc’n Co. v. Motorola Sols. Inc., 841 Fed. App’x 210 (Fed. Cir. 2021). In Hytera, the claim at issue recited “if the timeslot is the current desired timeslot, selecting a synchronization pattern selected from the first set of synchronization patterns . . . ; otherwise selecting a synchronization pattern selected from the second set of synchronization patterns[.]” Hytera, 841 Fed. App’x at 215. The Federal Circuit characterized this limitation as having “two alternative conditions and corresponding responses[.]” Id. The court explained “the ‘selecting’ step in claim 7 is not met unless the [claimed] system is configured to perform each claimed responsive action in response to each corresponding claimed prerequisite condition.” Id. at 216.

The disputed phrase here is similar. There are two claimed prerequisite conditions: under- and “would be” over-utilization of the network resource. Each prerequisite condition has a responsive action: dynamically modifying at least one of the service profile and the billing profile. There are also differences—the order in which the prerequisite conditions and responsive actions are recited, that the responsive actions are the same for each prerequisite, and the disputed language contemplates a third option of doing nothing—but none of these differences undercut the reasoning of Hytera. TNS stresses a fourth difference—namely, the Hytera claims use “and” whereas the disputed language recites “or.” (Dkt. No. 109 at 9.) Using “or” in this manner merely simplifies the claim language given the same responsive action to each recited condition. By phrasing the

claim language with the conditional statements at the end of the limitation, joined by “or,” the applicants avoided drafting a longer claim with two “dynamically modifying” steps and unnecessarily repeated language, such as: if the network resource is under-utilized, dynamically modifying the service/billing profiles; and if the network resource would be over-utilized, dynamically modifying the service/billing profiles. In fact, if the limitation as written recited “and” instead of “or,” the claim would arguably require an impossible condition—simultaneous under-utilization and “would be” over-utilization of the network resource—to trigger the “dynamically modifying” step. TNS also asserts that Defendants’ reading of the claim would exclude the embodiment depicted in FIG. 4. (Dkt. No. 109 at 9.) However, it would clearly include the embodiment shown in FIG. 5. (See ’813 Patent at FIG. 5 (item 332a).) “[T]he claims of the patent need not encompass all disclosed embodiments.” TIP Sys., LLC v. Phillips & Brooks/Gladwin, Inc., 529 F.3d 1364,

1373 (Fed. Cir. 2008) (“Our precedent is replete with examples of subject matter that is included in the specification, but is not claimed.”); see also Baran v. Med. Device Techs., 616 F.3d 1309, 1316 (Fed. Cir. 2010) (“It is not necessary that each claim read on every embodiment.”). Finally, during the hearing, TNS argued Defendants’ interepretation of the disputed phrase would mean that Claim 40 is impermissably broader than Claim 37. (Dkt. No. 127 at 90:41–19.) The Court, however, must not “put the validity cart before the claim construction horse.” Nazomi Commc’ns, Inc. v. ARM Holdings, PLC, 403 F.3d 1364, 1369 (Fed. Cir. 2005). Moreover, TNS points to no reason why that negates the reasoning of Hytera to this limitation. Accordingly, the Court agrees the plain and ordinary meaning of this term requires an infringing apparatus to have the capability to both (1) dynamically modify the service/billing

profiles if the network resource is under-utilized; and (2) dynamically modify the service/billing profiles if the network resource would be over-utilized. G. “a processor . . . said processor” (Claims 10, 37, 40) TNS’s Construction Defendants’ Construction The same processor(s) perform all of the No construction necessary beyond plain and recited functions attributed to the ordinary meaning “processor.” These claims require “a processor” “configured to” undertake certain steps. Claim 10, for example, requires: a processor connected to [a] network interface and configured to generate a prioritization list defining an order of [a] plurality of devices . . . ; said processor further configured to repeat: receiving traffic profiles over said network resource for said plurality of devices; managing said network resource according to said service profile and said billing profile if said network resource is fully utilized by said traffic profiles; and, selecting at least one of said devices based on said prioritization list and dynamically modifying at least one of said service profile and said billing profile for said selected devices, if said network resource is under-utilized by said traffic profile or if said network resource would be over- utilized by said traffic profiles; until said plurality of devices no longer continue to share said network resource; and said processor further configured, when said plurality of devices are no longer sharing said network resource, to clear said prioritization list. (’813 Patent at 15:19–48; see also id. at 18:52–19:11 (Claim 37); id. at 16–19 (dependent Claim 40).) The parties dispute whether the claims’ recitation of “said processor” refers back to the same processor or processors configured to perform the earlier-recited functions. TNS makes two arguments against any such requirement. First, applying the general rule that “a” means “one or more,” TNS suggests that Defendants’ construction goes against the plain meaning of “one or more processors.” (Dkt. No. 99 at 27–28 (citing 01 Communique Lab., Inc. v. LogMeIn, Inc., 687 F.3d 1292 (Fed. Cir. 2012); Convolve, Inc. v. Compaq Comput. Corp., 812 F.3d 1313 (Fed. Cir. 2016)).) Second, TNS argues that Defendants’ construction would exclude a preferred embodiment. (Dkt. No. 99 at 28–29.) According to Defendants, the claims’ use of “said processor” “unequivocally indicates that the same ‘one or more processors’ configured to ‘generate a prioritization list’ must also be configured to ‘repeat,’ and ‘clear said priority list.’” (Dkt. No. 106 at 28.) Defendants concede that “a processor” means “one or more processors.” Further, Defendants acknowledge the specification of the ’813 Patent has embodiments in which a server with multiple processors or separate servers

carry out the claimed functions, but they argue the claim language itself is unambiguous. (Id. at 30.) Reference to the Traxcell case resolves the issue: As a matter of plain language, reciting “a computer” (or a “first computer”) that performs a function, and then further reciting that “the computer” (or “said first computer”) performs multiple additional functions, suggests that such “computer” must be tied to all those functions. And it would make little sense—indeed, it would defy the concept of antecedent basis—for the claims to recite “the computer” or “said first computer” being “further” programmed to do a second set of tasks if a different computer were to do those tasks instead. Traxcell Techs., LLC v. Nokia Sols. & Networks Oy, 15 F.4th 1136, 1139–40 (Fed. Cir. 2021). Here, Defendants concede “a processor” means “one or more processors” Thus, the claims’ later reference to “said processor” refers back to the previously recited “one or more processors.” The Court therefore adopts Defendants’ position. V. CONCLUSION Disputed Term The Court’s Construction “service profile” “a set of one or more traffic parameters or (Claims 1, 2, 10, 11, 18, 25, 27, 32, 34, 35, 37, attributes that regulates traffic to and/or from 41, 42)” a device” “a set of one or more billing parameters or “billing profile(s)” attributes that regulates rating or charging or (Claims 1, 10, 18, 27, 34, 37, 41, 42) both of traffic to and/or from a device” “billing history” “past charges, usage, and/or payments” (Claims 1, 10, 18, 27, 34, 37, 41, 42) “traffic profile(s)” “a set of one or more parameters or attributes (Claims 1, 4, 7, 9, 10, 13, 14, 18, 21, 26, 27, of traffic activity over the network resource” 29, 33, 34, 36, 37, 40, 41, 42) “is fully utilized by” / “fully utilizes” / “full utilization” “has no additional capacity due to” (Claims 1, 6, 9, 10, 18, 27, 34, 37, 41, 42) “would be over-utilized by” “will exceed maximum capacity in the (Claims 1, 7, 10, 13, 18, 26, 27, 33, 34, 36, 37, future due to” 40–42) “is under-utilized by” / “would be under- “has some capacity remaining due to” / utilized by” “will have some capacity remaining in the (Claims 1, 4, 10, 14, 18, 27, 33, 34, 36, 37, 41, future due to” 42) “dynamically modifying . . . if . . . or if” (Claims 1, 4, 7, 10, 13, 14, 18, 27, 34, 37, 41, Plain and ordinary meaning. 42) “a processor . . . said processor” The same processor(s) perform all of the (Claims 10, 37, 40) recited functions attributed to the “processor.” The Court ORDERS each party not to refer, directly or indirectly, to its own or any other party’s claimconstruction positions in the presence of the jury. Likewise, the Court ORDERS the parties to refrain from mentioning any part of this opinion, other than the actual positions adopted by the Court, in the presence of the jury. Neither party may take a position before the jury that contradicts the Court’s reasoning in this opinion. Any reference to claim construction proceedings is limited to informing the jury of the positions adopted by the Court. So ORDERED and SIGNED this 22nd day of February, 2023.

RODNEY GILSTRAP \ UNITED STATES DISTRICT JUDGE