Mod Stack LLC v. Fuze Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Mod Stack LLC (Texas)
  • Defendant: Fuze, Inc. (Delaware)
  • Plaintiff’s Counsel: Stamoulis & Weinblatt LLC
• Case Identification: 1:20-cv-00152, D. Del., 01/30/2020
• Venue Allegations: Venue is alleged to be proper in the District of Delaware because Defendant is incorporated in Delaware, has committed acts of infringement in the district, and maintains an established place of business there.
• Core Dispute: Plaintiff alleges that Defendant’s unified communications products infringe a patent related to methods for managing voice-band calls across different types of telecommunication networks.
• Technical Context: The technology concerns voice gateways that allow interoperability between traditional circuit-switched telephone networks (like the PSTN) and modern packet-switched networks (like those using VoIP).
• Key Procedural History: The complaint notes that the patent-in-suit was assigned to the Plaintiff, Mod Stack LLC. No other significant procedural events are mentioned.

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 Dec. 2, 2008)

The Invention Explained

• Problem Addressed: The patent describes the technical challenge faced during the telecommunications industry's transition from legacy circuit-switched networks to "converged" packet-switched networks. A key problem was creating a "voice gateway" that could simultaneously interface with different types of call controllers (e.g., traditional telephony switches and modern softswitches), each using its own distinct communication protocol (’520 Patent, col. 1:46-56).
• The Patented Solution: The invention proposes an apparatus, or gateway, that uses a modular architecture to solve this interoperability problem. It features multiple "protocol endpoints" and a central "protocol adapter" (’520 Patent, Fig. 7). Each protocol endpoint is designed to communicate using one specific external protocol, translating messages from that protocol into a common, standardized "internal call control message." The protocol adapter then receives these internal messages and routes them to the appropriate destination endpoint, which translates the internal message back into the target system's native protocol. This architecture allows the gateway to act as a universal translator between otherwise incompatible systems (’520 Patent, col. 9:13-51).
• Technical Importance: This approach provided a method for telecommunication providers to gradually migrate their infrastructure to packet-based systems without losing connectivity to the large, existing base of circuit-switched equipment and customers (’520 Patent, col. 1:46-53).

Key Claims at a Glance

• The complaint alleges infringement of "exemplary claims" without specifying claim numbers (Compl. ¶11). Independent claim 1 is a representative apparatus claim.
• Independent Claim 1, Key Elements:
  • An apparatus that connects a local packet network (LPN) and a circuit-switched network.
  • A "first protocol endpoint" configured to receive a "first external call control message" from a first call controller (e.g., a circuit-switched controller) and map it to a "first internal call control message."
  • A "second protocol endpoint" configured to receive a "second external call control message" from an integrated access device (IAD) on the packet network and map it to a "second internal call control message."
  • A "protocol adapter" configured to receive these internal messages and route them between the first and second endpoints.
  • The claim further requires the endpoints to perform the reverse mapping for messages flowing in the opposite direction.
• The complaint does not explicitly reserve the right to assert dependent claims.

III. The Accused Instrumentality

Product Identification

• The complaint accuses "at least the Fuze products identified in the charts incorporated into this Count" (Compl. ¶11). As these charts were not included with the complaint, the specific accused products are not identified in the provided documents.

Functionality and Market Context

• The complaint does not provide specific details on the functionality of the accused products. It alleges in general terms that Defendant makes, uses, sells, and imports infringing products (Compl. ¶11) and that its employees internally test and use them (Compl. ¶12).

IV. Analysis of Infringement Allegations

The complaint references claim charts in an unprovided Exhibit 2 (Compl. ¶17). Accordingly, the infringement allegations are summarized below in prose based on the complaint’s narrative.

The complaint alleges that the "Exemplary Fuze Products" practice the technology claimed in the ’520 Patent and that they "satisfy all elements of the Exemplary '520 Patent Claims" (Compl. ¶17). The core of the infringement theory is that Defendant’s products, which facilitate communication between different network types, necessarily perform the functions of receiving call control messages from one type of system, translating them, and forwarding them to another, thereby infringing the claims of the ’520 Patent (Compl. ¶11, ¶17). No probative visual evidence provided in complaint.

• Identified Points of Contention:
  • Structural Questions: A primary question will be whether the architecture of the accused Fuze products, likely modern cloud-based software platforms, can be mapped onto the specific structure of a "first protocol endpoint," "second protocol endpoint," and "protocol adapter" as recited in the claims. The defense may argue that its distributed, software-defined system does not contain the distinct modular components described in the patent, which was drafted in the context of a physical gateway device (’520 Patent, Fig. 1).
  • Evidentiary Questions: The complaint lacks factual detail to substantiate its claims. A key evidentiary issue will be whether Plaintiff can demonstrate that the accused Fuze products utilize a common "internal call control message" format as an intermediary for translating between disparate external protocols. The existence and function of such an internal protocol are central requirements of the asserted claims (’520 Patent, col. 9:32-39).

V. Key Claim Terms for Construction

• The Term: "protocol endpoint"

• Context and Importance: This term defines the core modules that handle protocol-specific communications. The outcome of the case may depend on whether the functional software modules or APIs within the accused Fuze platform meet the definition of a "protocol endpoint."

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent describes the endpoints as "unique call processing entities" that handle "external messages" which are "protocol-specific" and map them to "internal messages" (’520 Patent, col. 9:15-39). This functional description is not explicitly limited to hardware and could be argued to read on software modules that perform these mapping functions.
  • Evidence for a Narrower Interpretation: The patent’s diagrams consistently depict "protocol endpoints" as discrete blocks (e.g., PEP 701, 702) that interface with specific types of hardware, such as a "Class 5 switch" or an "IAD" (’520 Patent, Fig. 7, Fig. 8). A defendant could argue this context limits the term to modules within a gateway device architected in the manner shown, rather than any generic software API.

• The Term: "protocol adapter"

• Context and Importance: This term defines the central routing component of the claimed apparatus. Its construction is critical to determining whether the internal messaging architecture of the accused products infringes.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent states the adapter's function is "to route messages between" the protocol endpoints, allowing them to "exchange internal messages 703 indirectly" (’520 Patent, col. 9:42-46). This could be interpreted broadly as any message bus or routing logic that directs communications between different software components.
  • Evidence for a Narrower Interpretation: The specification notes that the correspondence between endpoints is "established when the Provisioning object 707 uses the services of Protocol Adapter 704 ... to map a pair of endpoints together" (’520 Patent, col. 9:48-51). This might support a narrower construction requiring a specific provisioning or configuration mechanism that actively maps endpoints, not just a passive message routing system.

VI. Other Allegations

• Indirect Infringement: The complaint alleges induced infringement, stating that Defendant distributes "product literature and website materials inducing end users and others to use its products in the customary and intended manner that infringes" (Compl. ¶14). It also alleges contributory infringement, claiming the products "are not a staple article of commerce suitable for substantial noninfringing use" (Compl. ¶16).
• Willful Infringement: Willfulness is predicated on alleged post-suit knowledge. The complaint asserts that its service "constitutes actual knowledge" and that Defendant's continued infringement thereafter is willful (Compl. ¶13-14). No allegations of pre-suit knowledge are made.

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

• A core issue will be one of structural correspondence: can the architecture of a modern, cloud-based unified communications platform be mapped onto the specific "protocol endpoint" and "protocol adapter" structure claimed in the ’520 Patent, or has the technology evolved such that the accused systems operate in a fundamentally different, non-infringing manner?
• The case will also present a key evidentiary question: can the plaintiff produce evidence that the accused Fuze system internally utilizes a common, standardized "internal call control message" as the intermediary for translating between different external communication protocols, a specific mechanism required by the patent's claims?