Savannah Licensing LLC v. Envoy Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Savannah Licensing LLC (Texas)
  • Defendant: Envoy, Inc. (Delaware)
  • Plaintiff’s Counsel: The Mort Law Firm, PLLC
• Case Identification: 6:22-cv-00553, W.D. Tex., 05/31/2022
• Venue Allegations: Venue is alleged on the basis that Defendant has committed acts of patent infringement within the district and maintains a regular and established business in Texas.
• Core Dispute: Plaintiff alleges that Defendant’s unnamed products infringe a patent related to receiving and acting upon data packages that indicate user frustration with an electronic device.
• Technical Context: The technology involves monitoring user interactions with electronic devices to detect signs of frustration, correlating them with specific device operations, and using this data to improve network or service performance.
• Key Procedural History: The complaint does not mention any prior litigation, Inter Partes Review (IPR) proceedings, or licensing history related to the patent-in-suit.

Case Timeline

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

U.S. Patent No. 9,454,777 - Measuring and Improving the Quality of a User Experience Upon Receiving a Frustration Event Package

• Patent Identification: U.S. Patent No. 9,454,777, Measuring and Improving the Quality of a User Experience Upon Receiving a Frustration Event Package, issued September 27, 2016.

The Invention Explained

• Problem Addressed: The patent identifies a need for better methods to evaluate user experience, noting that the "increased adoption of new mobile devices and services may depend on the quality of experience perceived by users" and that existing evaluation methods "may be delayed from the user's experience" (ʼ777 Patent, col. 1:23-27).
• The Patented Solution: The invention proposes a system that receives a "frustration event package" containing both an indicator of user frustration (e.g., data from an accelerometer detecting a device shake) and an indicator of an associated device event (e.g., a slow software operation). This package is then used to determine feedback and implement a "network action" to improve performance, as conceptually illustrated by the system modules in Figure 1 (ʼ777 Patent, Abstract; Fig. 1; col. 4:41-54).
• Technical Importance: This approach sought to provide a more immediate and automated way to diagnose and respond to poor user experiences on mobile devices, moving beyond delayed, high-level network analysis (ʼ777 Patent, col. 3:22-30).

Key Claims at a Glance

• The complaint asserts independent claim 1 (Compl. ¶11).
• The essential elements of Claim 1, a method claim, are:
  • Receiving a "frustration event package" that includes a "user frustration event indicator" and an "associated event indicator," where the user frustration event is linked to an active device operation.
  • Determining feedback based on these indicators.
  • Implementing a "network action" based on the determined feedback.

III. The Accused Instrumentality

Product Identification

• The complaint does not specifically name the accused products or services, referring to them generally as "Exemplary Defendant Products" (Compl. ¶11). It states these products are identified in an external document, Exhibit 2, which was not filed with the complaint (Compl. ¶13).

Functionality and Market Context

• The complaint does not provide sufficient detail for analysis of the accused product's functionality or market context, as all technical allegations of infringement are incorporated by reference from the unprovided Exhibit 2 (Compl. ¶14).

IV. Analysis of Infringement Allegations

The complaint incorporates its infringement allegations by reference to an exhibit (Exhibit 2) that was not provided with the publicly filed document (Compl. ¶¶ 13-14). Therefore, a detailed claim chart summary cannot be constructed based on the available information.

No probative visual evidence provided in complaint.

• Identified Points of Contention: Based on the claim language and the general nature of the allegations, the infringement analysis may raise several questions:
  • Scope Questions: Does the accused system's response to user data qualify as "implementing a network action" as required by claim 1? The claim requires an active, implemented response, not merely the collection of data for later offline analysis. The court may need to determine if the accused system takes a responsive step, such as "increasing a network service" as contemplated by the patent, to meet this limitation ('777 Patent, col. 16:51-53, 59-62).
  • Technical Questions: Does the accused system's architecture involve receiving a pre-formed "frustration event package" as a discrete data object? The claim is structured around receiving such a package, which suggests a particular system design where user frustration and device events are associated and packaged on the user's device before transmission. A central factual question may be whether the accused system operates this way or uses a different process, such as independently collecting sensor data and system logs that are correlated later on a server ('777 Patent, col. 16:42-44).

V. Key Claim Terms for Construction

• The Term: "network action"

  • Context and Importance: This term is critical as it defines the final, active step of the claimed method, potentially distinguishing the invention from a passive data-collection system. The outcome of the infringement analysis will depend heavily on whether the functionality of the accused system is found to perform such an "action."
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The patent does not provide a formal definition of "network action," which a plaintiff may argue supports a broad interpretation covering any action taken over a network in response to the determined feedback ('777 Patent, col. 8:25-36).
    • Evidence for a Narrower Interpretation: Dependent claim 2 recites the specific action of "increasing a network service in a local area." The specification also provides concrete examples like "increasing a power modulation in an area... or beam steering." A defendant may argue these specific embodiments narrow the term's scope to actions that directly modify real-time network performance parameters for the user's device ('777 Patent, col. 8:28-30; col. 16:59-62).

• The Term: "frustration event package"

  • Context and Importance: The structure of this "package" is fundamental to claim 1, which requires the system to receive it. This framing implies the package is a discrete data unit containing pre-associated indicators. Whether the accused system uses such a "package" or employs a different data-handling architecture will likely be a central point of dispute.
  • Intrinsic Evidence for Interpretation:
    • Evidence for a Broader Interpretation: The patent describes the package in general terms as including an "indicator or indicators" for the frustration and device events, which could be argued to encompass a wide variety of data structures and formats ('777 Patent, col. 5:10-14).
    • Evidence for a Narrower Interpretation: The specification describes a "package formation module" that formats the package for "successful transmission in a packet network," which a defendant could argue implies a specifically constructed, purpose-built data object rather than a loose aggregation of log files or data streams ('777 Patent, col. 5:18-24).

VI. Other Allegations

The complaint does not contain allegations of indirect infringement or willful infringement.

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

• A central issue will be one of functional scope: does the accused system merely collect and analyze user data for subsequent, non-real-time improvements, or does it "implement a network action" as required by claim 1? The case may turn on evidence demonstrating whether the defendant's system takes a concrete, responsive step to modify a network service for the user based on detected frustration.
• A key architectural question will be one of definitional structure: does the accused system's data-handling method meet the "frustration event package" limitation? The dispute is likely to focus on whether the system receives a pre-compiled package containing associated frustration and device event indicators from a user device, or if it utilizes a different architecture where such data is collected and correlated centrally.