1 

UNITED STATES DISTRICT COURT 

FOR THE WESTERN DISTRICT OF TEXAS 

WACO DIVISION 

COMMSTECH LLC, 

 Plaintiff, 

 v. 

MELLANOX TECHNOLOGIES, INC., 

 Defendant. 

Case No. 6:20-cv-00208 

COMPLAINT FOR PATENT 

INFRINGEMENT 

JURY TRIAL DEMANDED

COMPLAINT FOR PATENT INFRINGEMENT 

Plaintiff Commstech LLC (“Commstech” or “Plaintiff”) hereby asserts the following 

claims for patent infringement against Defendant Mellanox Technologies, Inc., (“Defendant”), 

and alleges as follows: 

SUMMARY 

1. Commstech owns United States Patent Nos. 6,349,340 (the “’340 Patent”). 

2. Defendant infringes the ’340 Patent by implementing, without authorization, 

Commstech’s proprietary technologies in a number of its commercial networking products and 

related software including, inter alia, Defendant’s managed aggregation switch products (e.g., 

SN2000 Series and SN3000 Series switches) that support the RFC 4607 specification related to 

“Source-Specific Multicast for IP” (including but not limited to products such as the SN2000 

Series and SN3000 Series switches). 

3. By this action, Commstech seeks to obtain compensation for the harm Commstech 

has suffered as a result of Defendant’s infringement of the ‘340 Patent. 

Case 6:20-cv-00208 Document 1 Filed 03/20/20 Page 1 of 16
2 

NATURE OF THE ACTION 

4. This is a civil action for patent infringement arising under the patent laws of the 

United States, 35 U.S.C. § 1 et seq. 

5. Defendant has infringed and continues to infringe, and at least as early as the filing 

and/or service of this Complaint, has induced and continues to induce infringement of, and has 

contributed to and continues to contribute to infringement of, at least one or more claims of 

Commstech’s ‘340 Patent at least by making, using, selling, and/or offering to sell its products and 

services in the United States, including in this District. 

6. Commstech is the legal owner by assignment of the ‘340 Patent, which were duly 

and legally issued by the United States Patent and Trademark Office (“USPTO”). Commstech 

seeks monetary damages for Defendant’s infringement of the ‘340 Patent. 

THE PARTIES 

7. Plaintiff Commstech LLC is a Texas limited liability company with its principal 

place of business at 1708 Harrington Dr., Plano, Texas 75075. Commstech is the owner of 

intellectual property rights at issue in this action. 

8. On information and belief, Defendant Mellanox Technologies, Inc. is a California 

corporation with a principal place of business at 350 Oakmead Pkwy., Ste. 100, Sunnyvale, CA 

94085. On information and belief, Defendant maintains an office in this District 10801 N. MoPac 

Expwy., Bldg. 1, Ste. 300, Austin, TX 78759. 

9. On information and belief, Defendant directly and/or indirectly develops, designs, 

manufactures, distributes, markets, offers to sell and/or sells infringing products and services in 

the United States, including in the Western District of Texas, and otherwise directs infringing 

activities to this District in connection with its products and services. 

Case 6:20-cv-00208 Document 1 Filed 03/20/20 Page 2 of 16
3 

JURISDICTION AND VENUE 

10. As this is a civil action for patent infringement arising under the patent laws of the 

United States, 35 U.S.C. § 1 et seq., this Court has subject matter jurisdiction over the matters 

asserted herein under 28 U.S.C. §§ 1331 and 1338(a). 

11. This Court has personal jurisdiction over Defendant, in part because Defendant 

does continuous and systematic business in this District, including by providing infringing 

products and services to the residents of the Western District of Texas that Defendant knew would 

be used within this District, and by soliciting business from the residents of the Western District 

of Texas. For example, Defendant is subject to personal jurisdiction in this Court because, inter 

alia, and on information and belief, Defendant has a regular and established place of business at 

its offices in the Western District of Texas (and elsewhere in the State of Texas), and directly and 

through agents regularly does, solicits, and transacts business in the Western District of Texas (and 

elsewhere in the State of Texas), including, for example, through its www.mellanox.com website. 

12. In particular, Defendant has committed and continues to commit acts of 

infringement in violation of 35 U.S.C. § 271, and has made, used, marketed, distributed, offered 

for sale, sold, and/or imported infringing products in the State of Texas, including in this District, 

and engaged in infringing conduct within and directed at or from this District. For example, 

Defendant has purposefully and voluntarily placed the Accused Products into the stream of 

commerce with the expectation that the Accused Products will be used in this District. The 

Accused Products have been and continue to be distributed to and used in this District. 

Defendant’s acts cause and have caused injury to Commstech, including within this District. 

13. Venue is proper in this District under the provisions of 28 U.S.C. §§ 1391 and 

1400(b) at least because a substantial part of the events or omissions giving rise to the claims 

Case 6:20-cv-00208 Document 1 Filed 03/20/20 Page 3 of 16
4 

occurred in this District, and because Defendant has committed acts of infringement in this District 

and has a regular and established place of business in this District. 

THE ‘340 PATENT 

14. U.S. Patent No. 6,349,340 (“the ‘340 Patent”) is entitled “Data multicast 

channelization,” and was issued on February 19, 2002. A true and correct copy of the ‘340 Patent 

is attached as Exhibit A. 

15. The ‘340 Patent was filed on January 13, 2000 as U.S. Patent Application No. 

09/482,496. 

16. Commstech is the owner of all rights, title, and interest in and to the ‘340 Patent, 

with the full and exclusive right to bring suit to enforce the ‘340 Patent, including the right to 

recover for past infringement. 

17. The ‘340 Patent is valid and enforceable under United States Patent Laws. 

18. The ‘340 Patent recognized several problems with existing high-speed network data 

distribution technology, such as multicast technology. Notably, the ‘340 Patent recognized that 

“[m]anagement of high-speed data across distributed data networks can involve two basic 

approaches,” both of which have several drawbacks. Exhibit A at 1:32-33. 

19. For instance, the ‘340 Patent recognized problems with a “more common approach” 

referred to as the “client-based” approach, where “client nodes notify server nodes of their interest 

in certain desired data,” and the “servers can individually distribute data packets to each interested, 

subscribing client.” Exhibit A at 1:33-39. In this respect, the ‘340 Patent recognized that this 

“client-based” approach “tends to overburden the server as network demands grow.” Id. at 1:30-

41. In particular, the ‘340 Patent discloses that “as additional client nodes are added to the network, 

the server not only must individually distribute the data packets to each interested client node, but 

Case 6:20-cv-00208 Document 1 Filed 03/20/20 Page 4 of 16
5 

also the server must individually distribute the data packets to each additional subscribing client 

node,” and thus, “as the client node list grows, so does the server’s workload.” Id. at 1:41-47. 

20. The ‘340 Patent also recognized problems with another approach referred to as the 

“server-based” approach that uses multicast technology, in which “the server transmits the data 

packet to a multicast destination address identifying a particular multicast session,” and 

“[i]nterested client nodes merely subscribe to the multicast address, rather than the server, in order 

to receive the broadcast data.” Exhibit A at 1:48-58. However, the ‘340 Patent recognized that 

“because all client nodes receive each broadcast data packet, regardless of the content of the data 

packet, each client node must filter unwanted data upon receipt of each data packet,” but “[c]lient 

nodes generally are uninterested in most of the broadcast data and, as a result, client nodes expend 

substantial processor resources identifying and discarding unwanted data packets.” Id. at 1:54-

2:4. Further, the ‘340 Patent recognized that, although these existing approaches “allow[ ] a server 

to provide data at high data transmission rates to more client[ ] nodes,” these approaches can “limit 

the client node’s ability to filter unwanted data packets” given the client node’s “processor 

overhead.” Id. at 2:7-11. 

21. To address one or more shortcomings of existing high-speed network data 

distribution technology, such as existing multicast technology that “challeng[ed] the client node’s 

ability to filter the unwanted data packets,” the ‘340 Patent discloses, inter alia, a “method for 

efficient filtering of unwanted data in a multicast network environment” that “satisfies the longfelt need of the prior art by applying a combination hardware and software solution which 

selectively filters multicast data by selectively disabling channels containing unwanted data.” 

Exhibit A at 2:14-25. The ‘340 Patent’s “inventive arrangements” have “advantages over all other 

data distribution methods” and provide “a novel and nonobvious method for receiving the benefits 

Case 6:20-cv-00208 Document 1 Filed 03/20/20 Page 5 of 16
6 

of multicasting while avoiding the drawbacks associated with such systems.” Id. at 2:26-30. 

22. Indeed, the inventions of the ‘340 Patent improved the functionality of “client” 

computers operating in a multicast network environment by reducing the “substantial processor 

resources” expended by “client” computers using existing data filtering mechanisms, such as by 

reducing the resources expended by a “client” computer’s “network applications software.” 

Exhibit A at 6:9-47. In this respect, the inventions of the ‘340 Patent allow a “client” computer to 

“avoid excessive software filtering” that leads to “performance gain” that can be “significant.” Id.

at 10:21-31. 

The Inventions Claimed in the ‘340 Patent Improved Technology & 

Were Not Well-Understood, Routine, or Conventional 

23. Given the state of the art at the time of the inventions of the ‘340 Patent, including 

the deficiencies in network data distribution systems of the time, the inventive concepts of the ‘340 

Patent cannot be considered to be conventional, well-understood, or routine. See, e.g., Exhibit A 

at 1:32-2:17. Indeed, there was a long-felt need in the art at the time of the inventions of the ‘340 

Patent that the claimed inventions of the ‘340 Patent addressed. See, e.g., id at 2:20-26. In this 

respect, the ‘340 Patent discloses, among other things, an unconventional solution to problems 

arising in the context of network data distribution systems, namely, that “client” computers in such 

systems “expend[ed] substantial processor resources” filtering multicast data and this “processor 

overhead” inhibited the “client” computers’ ability to handle the increasing user demands for 

network data distribution systems to broadcast more data. See, e.g., id at 2:1-17. 

24. The inventions of the ‘340 Patent offered an unconventional, technological solution 

to such problems resulting in a “novel and nonobvious method for receiving the benefits of 

multicasting while avoiding the drawbacks associated with such [existing] systems.” Exhibit A at 

2:25-30; see also, e.g., id. at 10:21-26 (“The inventive multicast channelization strategy can 

Case 6:20-cv-00208 Document 1 Filed 03/20/20 Page 6 of 16
7 

increase the bandwidth available to the expanding client node base by distributing the broadcast 

data across multiple channels,” such that “client nodes can selectively filter unwanted broadcast 

data within the network interface circuitry of each client node.”). In this respect, the inventions of 

the ‘340 Patent improved the functionality of “client” computers operating in a multicast network 

environment. See, e.g., id. at 6:9-47, 10:21-31. 

25. Indeed, it was not well-understood, routine, or conventional at the time of the 

inventions of the ‘340 Patent to perform the following functions, alone and/or in combination with 

one another: (i) selecting from among a plurality of multicast communications channels a source 

communications channel for receiving requested multicast data, (ii) enabling the selected source 

communications channel, (iii) receiving the requested multicast data through the enabled source 

communications channel, (iv) forwarding the requested multicast data to requesting processes, and 

(v) disabling the selected source communications channel when the requesting processes indicate 

that no further data is requested to be received over the selected source communications channel. 

See, e.g., Exhibit A at Claims 1, 8, 14. Moreover, it was not well-understood, routine, or 

conventional at the time of the inventions of the ‘340 Patent to perform one or more of the 

following functions alone and/or in combination with one or more of the preceding functions: (i) 

receiving from one or more processes in a client node a request for multicast data, (ii) identifying 

a multicast data source for each requested data, and (iii) disabling an enabled selected source 

communications channel when the requesting client node process indicates that no further data is 

requested to be received from the identified multicast data source over the selected source 

communications channel and no other requesting client node processes have indicated a continuing 

need for further data to be received from the identified multicast data source over the selected 

source communications channel. See, e.g., id. at Claims 1, 8, 14. 

Case 6:20-cv-00208 Document 1 Filed 03/20/20 Page 7 of 16
8 

26. Further, it was not well-understood, routine, or conventional at the time of the 

inventions of the ‘340 Patent to perform one or more of the following functions alone and/or in 

combination with one or more of the unconventional functions set forth in paragraph number 25: 

(i) filtering, from multicast data received through an enabled source communications channel, 

unwanted/unrequested multicast data, (ii) discarding the unwanted/unrequested multicast data, and 

(ii) forwarding the filtered multicast data to one or more requesting processes. See, e.g., Exhibit 

A at Claims 3, 9, 15. 

27. These are just exemplary reasons why the inventions claimed in the ‘340 Patent 

were not well-understood, routine, or conventional at the time of the invention of the ‘340 Patent. 

28. Consistent with the problems addressed by the ‘340 Patent being rooted in network 

data distribution systems, the ‘340 Patent’s inventions naturally are also rooted in that same 

technology that cannot be performed solely with pen and paper or in the human mind. Indeed, 

using pen and paper or a human mind would not only ignore, but would run counter to, the stated 

technical solution of the ‘340 Patent noted above and the technical problems that the ‘340 Patent 

was specifically designed to address. Likewise, at least because the ‘340 Patent’s claimed 

inventions address problems rooted in network data distribution systems, these inventions are not 

merely drawn to longstanding human activities. 

COUNT I: INFRINGEMENT OF U.S. PATENT NO. 6,349,340 

29. Commstech incorporates by reference and re-alleges paragraphs 14-28 of this 

Complaint as if fully set forth herein. 

30. Defendant has infringed and is infringing, either literally or under the doctrine of 

equivalents, the ‘340 Patent in violation of 35 U.S.C. § 271 et seq., directly and/or indirectly, by 

making, using, offering for sale, or selling in the United States, and/or importing into the United 

Case 6:20-cv-00208 Document 1 Filed 03/20/20 Page 8 of 16
9 

States without authority or license, products that support the RFC 4607 specification related to 

“Source-Specific Multicast for IP” (e.g., Mellanox devices that operate with the Mellanox Onyx 

OS software, such as SN2000 Series and SN3000 Series switches) (collectively referred to herein 

as the “Accused ‘340 Products”). See, e.g., https://www.mellanox.com/relateddocs/prod_eth_switches/BR_SN2000series.pdf; See also http://www.mellanox.com/relateddocs/prod_eth_switches/BR_SN3000_Series.pdf. 

31. As just one non-limiting example, set forth below (with claim language in bold and 

italics) is exemplary evidence of infringement of Claim 1 of the ‘340 Patent in connection with the 

Accused ‘340 Products. This description is based on publicly available information. Commstech 

reserves the right to modify this description, including, for example, on the basis of information 

about the Accused ‘340 Products that it obtains during discovery. 

1(a): A method for receiving requested multicast data over a plurality of multicast 

communications channels comprising:—Defendant makes, uses, sells, and/or offers to sell a 

device or system that practices the method of receiving requested multicast data over a plurality 

of multicast communications channels in accordance with Claim 1. 

For instance, Mellanox devices that operate with the Mellanox Onyx OS software (e.g., 

SN2000 Series and SN3000 Series switches) support the RFC 4607 specification related to 

“Source-Specific Multicast for IP” that discloses the method recited in Claim 1. See, e.g., 

https://www.mellanox.com/related-docs/prod_switch_software/Onyx_ETH_UM.pdf (expressly 

disclosing PIM-SSM and RFC 4607 as being used by Mellanox Onyx OS software); Holbrook, 

Source-specific multicast for IP, RFC 4607 (2006), pp. 3-5, available at 

https://tools.ietf.org/pdf/rfc4607.pdf. In particular, RFC 4607 defines a “source-specific multicast 

service” (“SSM”) as “[a] datagram sent with source IP address S and destination IP address G in 

Case 6:20-cv-00208 Document 1 Filed 03/20/20 Page 9 of 16
10 

the SSM range [that] is delivered to each host socket that has specifically requested delivery of 

datagrams sent by S to G, and only to those sockets.” Holbrook, Source-specific multicast for IP, 

RFC 4607 (2006), p.5, available at https://tools.ietf.org/pdf/rfc4607.pdf. 

1(b): selecting from among the plurality of multicast communications channels a source 

communications channel for receiving said requested multicast data;—Defendant makes, uses, 

sells, and/or offers to sell a device or system that selects from among the plurality of multicast 

communications channels a source communications channel for receiving said requested multicast 

data. 

For instance, Mellanox devices that operate with the Mellanox Onyx OS software (e.g., 

SN2000 Series and SN3000 Series switches) support the RFC 4607 specification, which discloses 

a plurality of multicast communication channels, where each “channel is identified (addressed) by 

the combination of a unicast source address and a multicast destination address in the SSM range” 

(e.g., “S, G = (192.0.2.1, 232.7.8.9),” “S, G = (192.0.2.2, 232.7.8.9)”). Id. at p. 6; see also, e.g., 

id. at pp. 3-4 (“The network service identified by (S,G), for SSM address G and source host address 

S, is referred to as a ‘channel’”); id. at p. 6 (“We use the term ‘channel’ to refer to the service 

associated with an SSM address,” and “[a] channel is identified by the combination of an SSM 

destination address and a specific source, e.g., an (S,G) pair.”). In particular RFC 4607 discloses 

that “[t]he IP module interface to upper-layer protocols is extended to allow a socket to ‘Subscribe’ 

to . . . a particular channel identified by an SSM destination address and a source IP address.” Id. 

at p. 5; see also, e.g., id. at p. 6 (“The receiver operations allowed on a channel are called 

‘Subscribe (S,G)’ and ‘Unsubscribe (S,G)’”); id. at p. 7 (“If reception of the same channel is 

desired on multiple interfaces, Subscribe is invoked once for each”); id. at p. 8 (“An incoming 

datagram destined to an SSM address MUST be delivered by the IP module to all sockets that have 

Case 6:20-cv-00208 Document 1 Filed 03/20/20 Page 10 of 16
11 

indicated (via Subscribe) a desire to receive data that matches the datagram’s source address, 

destination address, and arriving interface.”). 

1(c): enabling said selected source communications channel;—Defendant makes, uses, 

sells, and/or offers to sell a device or system that enables the selected source communications 

channel. 

For instance, Mellanox devices that operate with the Mellanox Onyx OS software (e.g., 

SN2000 Series and SN3000 Series switches) support the RFC 4607 specification, which discloses 

that “[t]he IP module interface to upper-layer protocols is extended to allow a socket to ‘Subscribe’ 

to . . . a particular channel identified by an SSM destination address and a source IP address,” and 

subscribing to a particular channel comprises selecting a source communications channel and also 

enabling the selected source communications channel. Id. at p. 5; see also, e.g., id. at p. 6 (“The 

receiver operations allowed on a channel are called ‘Subscribe (S,G)’ and ‘Unsubscribe (S,G)’”); 

id. at p. 7 (“If reception of the same channel is desired on multiple interfaces, Subscribe is invoked 

once for each”); id. at p. 8 (“An incoming datagram destined to an SSM address MUST be 

delivered by the IP module to all sockets that have indicated (via Subscribe) a desire to receive 

data that matches the datagram’s source address, destination address, and arriving interface.”). 

Indeed, RFC 4607 discloses that “‘interface’ is a local identifier of the network interface on which 

reception of the channel identified by the (source-address, group-address) pair is to be enabled

[e.g., subscribed] or disabled [e.g., unsubscribed].” Id. at p. 7 (emphasis added). 

1(d): receiving said requested multicast data through said enabled source 

communications channel;—Defendant makes, uses, sells, and/or offers to sell a device or system 

that receives the requested multicast data through the enabled source communications channel. 

For instance, Mellanox devices that operate with the Mellanox Onyx OS software (e.g., 

Case 6:20-cv-00208 Document 1 Filed 03/20/20 Page 11 of 16
12 

SN2000 Series and SN3000 Series switches) support the RFC 4607 specification, which discloses 

that “[a]n incoming datagram destined to an SSM address MUST be delivered by the IP module 

to all sockets that have indicated (via Subscribe) a desire to receive data that matches the 

datagram’s source address, destination address, and arriving interface.” Id. at p. 8; see also, e.g., 

id. (“When the first socket on host H subscribes to a channel (S,G) on interface I, the host IP 

module on H sends a request on interface I to indicate to neighboring routers that the host wishes 

to receive traffic sent by source S to source-specific multicast destination G.”). 

1(e): forwarding said requested multicast data to requesting processes; and,—Defendant 

makes, uses, sells, and/or offers to sell a device or system that forwards the requested multicast 

data to requesting processes. 

For instance, as noted above, Mellanox devices that operate with the Mellanox Onyx OS 

software (e.g., SN2000 Series and SN3000 Series switches) support the RFC 4607 specification, 

which discloses that “[a]n incoming datagram destined to an SSM address MUST be delivered by 

the IP module to all sockets that have indicated (via Subscribe) a desire to receive data that matches 

the datagram’s source address, destination address, and arriving interface.” Id. at p. 8 (emphasis); 

see also, e.g., id. (“When the first socket on host H subscribes to a channel (S,G) on interface I, 

the host IP module on H sends a request on interface I to indicate to neighboring routers that the 

host wishes to receive traffic sent by source S to source-specific multicast destination G.”). In 

particular, RFC 4607 defines a “socket” as “an implementation-specific parameter used to 

distinguish among different requesting entities (e.g., programs or processes or communication 

end-points within a program or process) within the requesting host.” Id. at p. 5. 

1(f): disabling said selected source communications channel when said requesting 

processes indicate that no further data is requested to be received over said selected source 

Case 6:20-cv-00208 Document 1 Filed 03/20/20 Page 12 of 16
13 

communications channel.—Defendant makes, uses, sells, and/or offers to sell a device or system 

that disables the selected source communications channel when the requesting processes indicate 

that no further data is requested to be received over the selected source communications channel. 

For instance, Mellanox devices that operate with the Mellanox Onyx OS software (e.g., 

SN2000 Series and SN3000 Series switches) support the RFC 4607 specification, which discloses 

that “[t]he IP module interface to upper-layer protocols is extended to allow a socket to . . . 

‘Unsubscribe’ from a particular channel identified by an SSM destination address and a source IP 

address,” and unsubscribing from a particular channel disables the particular channel to indicate 

that no further data is requested to be received over the particular channel. Id. at p. 5; see also, 

e.g., id. at p. 8 (disclosing that “[a]n incoming datagram destined to an SSM address MUST be 

delivered by the IP module to all sockets that have indicated (via Subscribe) a desire to receive 

data that matches the datagram’s source address, destination address, and arriving interface,” but 

“MUST NOT be delivered to other sockets” (e.g., sockets that have Unsubscribed)). Indeed, as 

noted above, RFC 4607 discloses that “‘interface’ is a local identifier of the network interface on 

which reception of the channel identified by the (source-address, group-address) pair is to be 

enabled [e.g., subscribed] or disabled [e.g., unsubscribed].” Id. at p. 7 (emphasis added). 

32. Additionally, Defendant has been and/or currently is an active inducer of 

infringement of the ‘340 Patent under 35 U.S.C. § 271(b) and contributory infringer of the ‘340 

Patent under 35 U.S.C. § 271(c). 

33. Defendant knew of the ‘340 Patent, or at least should have known of the ‘340 

Patent, but was willfully blind to its existence. On information and belief, Defendant has had actual 

knowledge of the ‘340 Patent since at least as early as the filing and/or service of this Complaint. 

34. Defendant has provided the Accused ‘340 Products to its customers and, on 

Case 6:20-cv-00208 Document 1 Filed 03/20/20 Page 13 of 16
14 

information and belief, instructions to use the Accused ‘340 Products in an infringing manner 

while being on notice of (or willfully blind to) the ‘340 Patent and Defendant’s infringement. 

Therefore, on information and belief, Defendant knew or should have known of the ‘340 Patent 

and of its own infringing acts, or deliberately took steps to avoid learning of those facts. 

35. Defendant knowingly and intentionally encourages and aids at least its end-user 

customers to directly infringe the ‘340 Patent. 

36. Defendant’s end-user customers directly infringe at least one or more claims of the 

‘340 Patent by using the Accused ‘340 Products in their intended manner to infringe. Defendant 

induces such infringement by providing the Accused ‘340 Products and instructions to enable and 

facilitate infringement, knowing of, or being willfully blind to the existence of, the ‘340 Patent. 

On information and belief, Defendant specifically intends that its actions will result in 

infringement of one or more claims of the ‘340 Patent, or subjectively believe that their actions 

will result in infringement of the ‘340 Patent, but took deliberate actions to avoid learning of those 

facts, as set forth above. 

37. Additionally, Defendant contributorily infringes at least one or more claims of the 

‘340 Patent by providing the Accused ‘340 Products and/or software components thereof, that 

embody a material part of the claimed inventions of the ‘340 Patent, that are known by Defendant 

to be specially made or adapted for use in an infringing manner, and are not staple articles with 

substantial non-infringing uses. The Accused ‘340 Products are specially designed to infringe at 

least one or more claims of the ‘340 Patent, and their accused components have no substantial noninfringing uses. In particular, on information and belief, the software modules and code that 

implement and perform the infringing functionalities identified above are specially made and 

adapted to carry out said functionality and do not have any substantial non-infringing uses. 

Case 6:20-cv-00208 Document 1 Filed 03/20/20 Page 14 of 16
15 

38. At least as early as the filing and/or service of this Complaint, Defendant’s 

infringement of the ‘340 Patent was and continues to be willful and deliberate, entitling 

Commstech to enhanced damages. 

39. Additional allegations regarding Defendant’s knowledge of the ‘340 Patent and 

willful infringement will likely have evidentiary support after a reasonable opportunity for 

discovery. 

40. Defendant’s infringement of the ‘340 Patent is exceptional and entitles Commstech 

to attorneys’ fees and costs incurred in prosecuting this action under 35 U.S.C. § 285. 

41. Commstech is in compliance with any applicable marking and/or notice provisions 

of 35 U.S.C. § 287 with respect to the ‘340 Patent. 

42. Commstech is entitled to recover from Defendant all damages that Commstech has 

sustained as a result of Defendant’s infringement of the ‘340 Patent, including, without limitation, 

a reasonable royalty. 

PRAYER FOR RELIEF 

WHEREFORE, Commstech respectfully requests: 

A. That Judgment be entered that Defendant has infringed at least one or more 

claims of the ‘340 Patent, directly and/or indirectly, literally and/or under the doctrine 

of equivalents; 

B. An award of damages sufficient to compensate Commstech for Defendant’s 

infringement under 35 U.S.C. § 284, including an enhancement of damages on account 

of Defendant’s willful infringement; 

C. That the case be found exceptional under 35 U.S.C. § 285 and that 

Commstech be awarded its reasonable attorneys’ fees; 

Case 6:20-cv-00208 Document 1 Filed 03/20/20 Page 15 of 16
16 

D. Costs and expenses in this action; 

E. An award of prejudgment and post-judgment interest; and 

F. Such other and further relief as the Court may deem just and proper. 

DEMAND FOR JURY TRIAL 

Pursuant to Rule 38(b) of the Federal Rules of Civil Procedure, Commstech respectfully 

demands a trial by jury on all issues triable by jury. 

Respectfully submitted, 

Dated: March 20, 2020 /s/ Raymond W. Mort, III 

Raymond W. Mort, III 

Texas State Bar No. 00791308 

raymort@austinlaw.com 

THE MORT LAW FIRM, PLLC 

100 Congress Ave, Suite 2200 

Austin, Texas 78701 

Tel/Fax: (512) 865-7950 

Attorney for Plaintiff 

Commstech Holdings LLC

Case 6:20-cv-00208 Document 1 Filed 03/20/20 Page 16 of 16