Mod Stack LLC v. Raisecom Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Mod Stack LLC (Texas)
  • Defendant: Raisecom Inc. (Delaware)
  • Plaintiff’s Counsel: Stamoulis & Weinblatt LLC; Direction IP Law (Of Counsel)
• Case Identification: 1:19-cv-00575, D. Del., 03/27/2019
• Venue Allegations: Venue is alleged to be proper in the District of Delaware because Defendant is a Delaware corporation and has allegedly committed acts of infringement in the district.
• Core Dispute: Plaintiff alleges that Defendant’s TDMoverIP Gateway products infringe a patent related to voice gateways that manage calls between different types of telecommunication networks.
• Technical Context: The technology addresses the challenge of interoperability between legacy circuit-switched telephone networks (like the PSTN) and modern packet-switched networks (like Voice over IP) during the industry's migration to "converged" networks.
• Key Procedural History: The complaint references the patent's prosecution history, arguing that the claimed invention was distinguished from prior art that used only a single link protocol. The applicant argued its invention was unconventional because it uses an "internal call control protocol" to map messages between two different external protocols, a feature the prior art allegedly lacked.

Case Timeline

II. Technology and Patent(s)-in-Suit Analysis

U.S. Patent No. 7,460,520 - “Apparatus and Method for Using Multiple Call Controllers of Voice-Band Calls,” issued December 2, 2008

The Invention Explained

• Problem Addressed: As telecommunications networks evolved from traditional circuit-switched systems to packet-switched ("converged") networks, a technical challenge arose: enabling seamless communication between them. These disparate networks use different, incompatible call control protocols, creating a need for a "voice gateway" that can simultaneously interface with multiple types of controllers (e.g., traditional telephony switches and modern softswitches) (’520 Patent, col. 1:19-56; Compl. ¶14).
• The Patented Solution: The patent describes a voice gateway apparatus with a specific software architecture designed for protocol translation. The core of the solution is abstracting protocol-specific functions into discrete software objects called "Protocol Endpoints" (PEPs). Each PEP handles one external protocol. A central "Protocol Adapter" routes messages between the PEPs by first mapping the external protocol messages into a common "internal protocol" and then re-mapping them to the target external protocol at the other end (’520 Patent, Abstract; col. 10:46-50; Fig. 7). This architecture allows the gateway to connect different network types without either endpoint needing to understand the other's native protocol (Compl. ¶21).
• Technical Importance: This design provided a flexible and scalable solution for bridging legacy and next-generation telecommunication networks, a critical function for network operators during the multi-year transition to IP-based infrastructure (’520 Patent, col. 1:46-56).

Key Claims at a Glance

• The complaint asserts independent Claim 1 (Compl. ¶36).
• Claim 1 is directed to an apparatus (a voice gateway) comprising three key components:
  • A first protocol endpoint configured to receive a first external call control message from a circuit-switched network controller, map it to a first internal call control message, and map a second internal message back to a third external message.
  • A second protocol endpoint configured to receive a second external call control message from a packet network device (IAD), map it to a second internal call control message, and map the first internal message back to a fourth external message.
  • A protocol adapter configured to receive the first and second internal call control messages and route them to the opposing protocol endpoint.
• The complaint does not explicitly reserve the right to assert dependent claims but requests judgment that "one or more claims" have been infringed (Compl. ¶V.a).

III. The Accused Instrumentality

Product Identification

• The complaint identifies the "RC1201-2GE16E1T1 TDMoverIP Gateway" and related devices in the RC1201 series as the "Accused Instrumentality" (Compl. ¶36).

Functionality and Market Context

• The Accused Instrumentality is alleged to be an apparatus that connects a local packet network and a circuit-switched network (Compl. ¶37). Its function is described as providing an "interconnect between PSTN and various IP endpoints" and bridging circuit- and packet-based networks to support call routing such as "PSTN-to-IP and IP-to-PSTN" (Compl. ¶37). The complaint includes a diagram from the patent, Figure 1, which illustrates a voice gateway (101) connecting a telephony device on a local packet network to a Class 5 switch on the PSTN (Compl. ¶15, p. 5). Another referenced visual, Figure 2, shows the gateway connecting to a softswitch, illustrating its ability to handle different controller types (Compl. ¶16, p. 6).

IV. Analysis of Infringement Allegations

’520 Patent Infringement Allegations

• Identified Points of Contention:
  • Architectural Questions: The complaint's allegations track the claim language but provide limited detail on the internal architecture of the Accused Instrumentality. A central question will be whether the accused TDMoverIP Gateway actually contains the claimed three-part software structure: two distinct "protocol endpoints" and a "protocol adapter." The court will need to determine if the accused device's components meet these structural limitations.
  • Technical Questions: A key factual dispute may arise over the "mapping... to an... internal protocol" limitations. The analysis will require evidence of how the accused device actually translates between protocols. Does it use a common, intermediate message set as described in the patent, or does it perform a more direct, state-based conversion that might not meet the "mapping" requirement as construed by the court? The complaint's allegations on this point are conclusory.

V. Key Claim Terms for Construction

• The Term: "internal protocol"

• Context and Importance: This term is the technological core of the claimed invention and was a focus of arguments during prosecution to distinguish the invention as "unconventional" (Compl. ¶¶21, 23). Its construction will be dispositive. If construed narrowly to require a specific, defined message set, infringement may be harder to prove. If construed broadly to mean any intermediate layer of abstraction for protocol conversion, the claim scope would be wider.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent summary describes a "common representation" that protocols are adapted to, suggesting a functional rather than strictly structural definition (’520 Patent, col. 4:29-32).
  • Evidence for a Narrower Interpretation: The specification discloses a specific set of "internal messages 703" (LINESTATUS, LINECONTROL, etc.) and shows them being used in detailed sequence diagrams (e.g., Figs. 9-13), which could support an argument that the "internal protocol" is limited to this disclosed set or a close equivalent (’520 Patent, col. 9:35-40).

• The Term: "protocol endpoint"

• Context and Importance: The claims require two distinct "protocol endpoints." The infringement analysis will depend on whether the functional blocks within the accused gateway can be separately identified as meeting this definition. Practitioners may focus on this term because the defendant may argue its product uses a monolithic architecture rather than the claimed modular endpoint-based design.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The term could be interpreted functionally as any software module that terminates an external protocol and interfaces with a translation layer. The patent states that PEPs "represent unique call processing entities" corresponding to a port or controller (Compl. ¶20; '520 Patent, col. 9:15-18).
  • Evidence for a Narrower Interpretation: The patent depicts "Protocol Endpoints" (e.g., 701, 702 in Fig. 7) as specific software objects that "map each external (protocol-specific) message to an appropriate internal message" (’520 Patent, col. 9:31-34). This could be read to require a specific mapping function within the defined endpoint object.

VI. Other Allegations

• Indirect Infringement: The complaint does not plead a separate count for indirect infringement. However, it alleges that Defendant "has promoted the infringing use... for example through advertising" (Compl. ¶43), which are facts that could potentially support an inducement theory.
• Willful Infringement: The complaint does not allege willful infringement or pre-suit knowledge of the patent. It asserts that Defendant has had "at least constructive notice of the ‘520 patent by operation of law" (Compl. ¶46).

VII. Analyst’s Conclusion: Key Questions for the Case

The resolution of this case will likely depend on the answers to two central questions:

1. A core issue will be one of architectural correspondence: Does the accused gateway’s software architecture embody the specific three-part structure recited in Claim 1—a first protocol endpoint, a second protocol endpoint, and a protocol adapter—or does it achieve protocol conversion through a technically different, more integrated design that falls outside the claim's structural limitations?
2. A critical claim construction question will be one of definitional substance: What precisely constitutes an "internal protocol" as claimed? Will the court define it narrowly as a concrete set of internal messages, as exemplified in the patent's figures, or more broadly as any functional abstraction layer that facilitates translation, a determination that will significantly impact the infringement analysis.