DCT

1:19-cv-01046

Rapiddeploy Inc v. Rapidsos Inc

Key Events
Complaint

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 1:19-cv-01046, D. Del., 06/06/2019
  • Venue Allegations: Venue is alleged to be proper in the District of Delaware because the Defendant, RapidSOS, Inc., is a Delaware corporation and therefore resides in the district.
  • Core Dispute: Plaintiff alleges that Defendant’s prototype emergency data gateway devices infringe a patent related to technology for integrating legacy 9-1-1 call-handling equipment with modern, cloud-based computer-aided dispatch systems.
  • Technical Context: The technology addresses the public safety sector, specifically by creating a hardware interface to bridge the data format gap between older, on-premise emergency call equipment and next-generation, cloud-based dispatch platforms.
  • Key Procedural History: The complaint alleges that Plaintiff disclosed its technology and its pending patent application to Defendant in January 2019. It further alleges that Defendant issued a press release on May 7, 2019, that acknowledged Plaintiff's "patented Emergency Data Gateway," less than a month after the patent-in-suit issued. These allegations form the basis for the claim of willful infringement.

Case Timeline

Date Event
2018-01 Plaintiff began developing its EDG technology
2018-05-31 '122 Patent Priority Date
2018-08 AT&T partners with Plaintiff to provide its CAD platform
2019-01 Plaintiff allegedly describes EDG technology to Defendant
2019-03 Plaintiff wins contract with California Office of Emergency Services
2019-04-16 '122 Patent Issue Date
2019-05-01 Plaintiff meets with third-party vendor AK Associates (approx.)
2019-05-02 Plaintiff observes alleged prototype at a Florida PSAP (approx.)
2019-05-07 Defendant press release allegedly acknowledges Plaintiff's patent
2019-06-06 Complaint Filing Date

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

U.S. Patent No. 10,264,122 - "Emergency Data Gateway Device" (issued Apr. 16, 2019)

The Invention Explained

  • Problem Addressed: The patent’s background section describes the significant challenge of integrating modern, cloud-based Computer-Aided Dispatch (CAD) systems with the thousands of legacy Public Safety Answering Points (PSAPs) across the U.S. These legacy systems use a wide variety of proprietary, non-standardized data formats, making integration costly, time-consuming, and requiring custom, on-site solutions for each deployment (’122 Patent, col. 1:35-51).
  • The Patented Solution: The invention is a physical "gateway device" that acts as an intermediary. It connects locally to the legacy Call Handling Equipment (CHE) and receives emergency call data in its native, proprietary format. The gateway then communicates with a central, cloud-based processing system. The cloud system, which stores parsing instructions for various CHE formats, sends the correct instructions to the gateway. The gateway uses these instructions to parse and reformat the data into a standardized structure (e.g., JSON) and transmits the clean data back to the cloud CAD platform. This allows for remote, rapid, and scalable configuration without manual programming at each PSAP (’122 Patent, col. 2:14-30; Fig. 1).
  • Technical Importance: This solution provides a standardized bridge to modernize emergency response infrastructure, allowing advanced cloud-based analytics and dispatch tools to be deployed quickly to agencies still reliant on older, non-IP-based equipment (’122 Patent, col. 1:41-51).

Key Claims at a Glance

  • The complaint asserts independent Claim 1 (Compl. ¶31).
  • The essential elements of Claim 1 are:
    • A gateway device comprising:
    • a call handling equipment (CHE) listener interface configured to form a communication channel with a CHE and receive call event data from the CHE;
    • an Internet Protocol (IP) interface configured to communicate with a cloud-based processing system;
    • a provisioning engine configured to receive, from the cloud-based processing system via the IP interface, instructions for parsing data from a data output format of the CHE; and
    • a message parsing engine configured to: parse the call event data received from the CHE via the CHE listener interface according to the instructions, and format the call event data according to a consistent data format;
    • wherein the gateway device is configured to transmit the formatted call event data to the cloud-based processing system via the IP interface.
  • The complaint does not explicitly reserve the right to assert dependent claims, but states the selection of Claim 1 is "exemplary" and not "limiting" (Compl. ¶31).

III. The Accused Instrumentality

Product Identification

  • The accused products are "prototype gateway devices" that Defendant RapidSOS allegedly developed, distributed, and deployed to multiple PSAPs in the United States (Compl. ¶3, ¶30). The complaint alleges these were developed on a Raspberry Pi platform (Compl. ¶17).

Functionality and Market Context

  • The complaint alleges, based on third-party conversations and direct observation, that the accused prototype gateway is deployed at PSAPs, including one in St. Johns County, Florida (Compl. ¶17, ¶19). The device is alleged to connect to legacy call handling equipment (specifically, a "Solacom CHE device"), receive call event data (including ANI/ALI and dispatcher position data), parse and format this data, and transmit it over the internet to RapidSOS's cloud-based servers. The data is then allegedly displayed in a RapidSOS browser-based tool called "RapidLite" (Compl. ¶20).

IV. Analysis of Infringement Allegations

No probative visual evidence provided in complaint.

'122 Patent Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
a call handling equipment (CHE) listener interface configured to form a communication channel with a CHE and receive call event data from the CHE The accused prototype gateway allegedly includes a listener interface that receives call event data, such as ANI/ALI and dispatcher position data, over a communication channel with a CHE, such as a Solacom device. ¶33 col. 7:7-14
an Internet Protocol (IP) interface configured to communicate with a cloud-based processing system The accused prototype gateway is alleged to include an "internet port" that communicates with RapidSOS's cloud-based servers over the internet. ¶34 col. 8:45-54
a provisioning engine configured to receive, from the cloud-based processing system via the IP interface, instructions for parsing data from a data output format of the CHE The accused prototype gateway is alleged to include a "provisioning engine" that receives instructions for parsing CHE call event data from RapidSOS's cloud-based servers through its internet port. ¶35 col. 8:59-9:4
a message parsing engine configured to: parse the call event data received from the CHE...according to the instructions, and format the call event data according to a consistent data format The accused prototype gateway allegedly includes a "message parsing engine" that parses received call data (ANI/ALI, etc.) according to the received instructions and formats it for transmission to RapidSOS's cloud servers. ¶36 col. 8:49-61
wherein the gateway device is configured to transmit the formatted call event data to the cloud-based processing system via the IP interface The accused prototype gateway allegedly transmits the formatted CHE call event data to RapidSOS's cloud-based servers over the internet. ¶37 col. 2:45-49

Identified Points of Contention

  • Technical Questions: The infringement allegations regarding the "provisioning engine" and "message parsing engine" are made on "information and belief" (Compl. ¶35-36). A central factual question is what evidence exists to show that the accused prototype contains these specific, separate software engines and, crucially, that the "provisioning engine" actually receives parsing instructions from a remote cloud server as required by the claim. The complaint's allegations are based on observing the system's inputs and outputs, not its internal architecture (Compl. ¶19-20).
  • Scope Questions: The case may turn on the scope of "provisioning engine." Does the term, as used in the patent, require the specific, dynamic, cloud-driven configuration described in the specification (e.g., '122 Patent, col. 12:25-41), or could it be read more broadly to cover a device that receives its parsing logic via a one-time software load or a general update, rather than as part of a specific call-data-format-identification process?

V. Key Claim Terms for Construction

The Term: "provisioning engine configured to receive ... instructions for parsing data"

  • Context and Importance: This element appears central to the patent's claimed novelty, which is automating the configuration of the gateway device to avoid manual, on-site programming. The infringement case hinges on whether the accused device performs this specific function of receiving parsing instructions from the cloud. Practitioners may focus on this term because it defines the core mechanism of the invention's "plug-and-play" capability.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The term "provisioning engine" is not explicitly defined with a precise structural meaning. A party could argue that any software module that prepares or configures the device for operation, including one that receives its logic as part of a general software update, meets this definition.
    • Evidence for a Narrower Interpretation: The specification repeatedly describes a specific, interactive process where the cloud system determines the output format of a specific CHE and then transmits the appropriate parsing instructions to the gateway (’122 Patent, col. 2:20-30; col. 12:25-50). This context suggests the "provisioning engine" is not just a passive recipient of software but an active participant in a dynamic configuration loop tied to the local CHE environment.

The Term: "parse the call event data... according to the instructions"

  • Context and Importance: This term is causally linked to the "provisioning engine". The dispute will likely focus on the source and timing of the "instructions." Infringement requires not just parsing, but parsing according to instructions received via the claimed provisioning process.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: A party might argue that once parsing logic is loaded onto the device, it constitutes "instructions," and any subsequent parsing is performed "according to" them, regardless of how or when they were loaded.
    • Evidence for a Narrower Interpretation: The claim structure links the parsing action of the "message parsing engine" to the instructions received by the "provisioning engine". The patent's detailed description of the process flow (e.g., Fig. 5) reinforces this sequence: receive data describing the environment (510), determine the format (520), retrieve instructions (530), and transmit them to the gateway (540). This suggests the "instructions" must originate from the cloud-based provisioning process, not from a static, pre-loaded configuration file.

VI. Other Allegations

Indirect Infringement

  • The complaint focuses on allegations of direct infringement by Defendant for making, using, and distributing the accused prototypes (Compl. ¶30, ¶38). No separate counts for indirect infringement are pleaded.

Willful Infringement

  • The complaint alleges willful infringement based on Defendant’s alleged pre-suit and post-issuance knowledge of the patent. Pre-suit knowledge is alleged to stem from a January 2019 meeting where Plaintiff discussed its technology and pending patent application with Defendant (Compl. ¶16). The complaint further alleges that Defendant's knowledge is evidenced by a May 7, 2019 press release in which Defendant purportedly acknowledged Plaintiff's "patented Emergency Data Gateway," which occurred after the patent had issued (Compl. ¶14, ¶39).

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

  1. A central issue will be one of evidentiary proof: The complaint’s allegations regarding the internal workings of the accused prototype are based on "information and belief." A key question for discovery will be whether the accused device's architecture actually includes a "provisioning engine" that dynamically receives parsing "instructions" from a cloud server, or if its functionality is achieved through a different, non-infringing technical method, such as being pre-configured with static parsing logic.

  2. The case will also likely involve a critical question of claim scope: Can the term "provisioning engine configured to receive...instructions", which underpins the patent's automation claims, be construed broadly to cover any method of software configuration? Or will the court, based on the patent's specification, construe it more narrowly to require the specific, interactive, cloud-driven configuration process described as the invention? The resolution of this construction will be pivotal to the infringement analysis.