OptiMorphix Inc v. Salesforce Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: OptiMorphix, Inc. (Delaware)
  • Defendant: Salesforce, Inc.; Slack Technologies, LLC; and MuleSoft, LLC (Delaware)
  • Plaintiff’s Counsel: Berger & Hipskind LLP; Bayard, P.A.
• Case Identification: 1:24-cv-01278, D. Del., 11/21/2024
• Venue Allegations: Venue is asserted in the District of Delaware on the basis that each Defendant is a Delaware entity organized and existing under the laws of the State of Delaware.
• Core Dispute: Plaintiff alleges that Defendant’s Salesforce Lightning Platform, Slack Communication Platform, and MuleSoft Anypoint Platform infringe seven patents related to content adaptation for mobile devices, adaptive bitrate management for streaming media, and TCP packet burst avoidance.
• Technical Context: The technologies at issue address challenges in delivering data-intensive content over networks with variable capacity and to devices with limited resources, a critical function in the modern mobile and cloud computing landscape.
• Key Procedural History: The complaint notes that the asserted patents originate from technology developed at Bytemobile, Inc. and Citrix Systems, Inc. It also highlights that the patent portfolio has been widely cited by numerous technology companies, which may be presented to suggest the patents’ significance in the field.

Case Timeline

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

U.S. Patent No. 9,275,167 - "Content Adaptation," Issued March 1, 2016

The Invention Explained

• Problem Addressed: The patent addresses the challenge of managing data in distributed storage systems, which can suffer from inefficiencies, data loss upon node failure, uneven data distribution, and slow retrieval (Compl. ¶¶18-19).
• The Patented Solution: The invention provides a method for adapting webpage content for mobile devices by traversing an initial Document Object Model (DOM) of a webpage, transforming it into a second, adapted DOM based on device characteristics (e.g., screen size), and then generating a new webpage from this second DOM ('167 Patent, Abstract; col. 10:1-25). This process aims to make webpages more suitable for mobile viewing without losing essential content or structure (Compl. ¶75).
• Technical Importance: This approach provided a systematic way to reformat complex webpages for the constrained screens and processing power of early mobile devices, improving user experience and data efficiency (Compl. ¶20).

Key Claims at a Glance

• The complaint asserts at least dependent claim 14, which depends from independent claim 1 (Compl. ¶85).
• Independent Claim 1 (Method):
  • Identifying content sections during a traversal of a first Document Object Model (DOM) representing a webpage.
  • Transforming the first DOM to a second DOM based on an adaptation parameter that describes features of a mobile device.
  • Serializing the second DOM by converting it into adapted markup language source code.
  • Constructing an adapted webpage from the markup language source code, wherein the adapted webpage is provided to the mobile device for downloading.

U.S. Patent No. 9,292,618 - "Content Adaptation," Issued March 22, 2016

The Invention Explained

• Problem Addressed: The patent identifies shortcomings in conventional web browsing techniques when applied to mobile devices, which have limited resources. These shortcomings include slow load times, poor support for rich media, and usability issues on small screens (Compl. ¶25).
• The Patented Solution: The invention describes a method for adapting a webpage by extracting "essential style data" from the webpage's data structure, discarding layout-specific style data, comparing styles between parent and child nodes, and then encapsulating nodes with identical styles within a common "enclosure tag." This process is used to reconstruct an adapted webpage for a mobile device ('618 Patent, Abstract; col. 10:29-57). The system is intended to simplify the webpage's styling for mobile rendering while preserving its core visual identity (Compl. ¶¶26-27).
• Technical Importance: This method offers a way to reduce the complexity and data overhead of webpage styling (e.g., CSS) for mobile delivery, which can improve rendering speed and reduce data consumption on mobile networks (Compl. ¶27).

Key Claims at a Glance

• The complaint asserts at least dependent claim 7, which depends from independent claim 1 (Compl. ¶106).
• Independent Claim 1 (Method):
  • Extracting style data from a data structure representing a webpage, wherein the extracted style data includes a subset of style properties defined as being essential style data.
  • Discarding, from the subset of style properties, layout-specific style data.
  • Comparing a parent node's essential style data with the essential style data of one or more child nodes.
  • Wrapping one or more nodes that share the same essential style data into an enclosure tag.
  • Reconstructing an adapted webpage based on the essential style data provided by the enclosure tag.

Multi-Patent Capsule: U.S. Patent No. 9,191,664

• Patent Identification: U.S. Patent No. 9,191,664, “Adaptive Bitrate Management for Streaming Media Over Packet Networks,” Issued November 17, 2015.
• Technology Synopsis: The patent addresses the difficulty of delivering consistent, high-quality streaming media over capacity-limited and fluctuating wireless networks (Compl. ¶31). The solution involves an adaptive bitrate manager that monitors network feedback to estimate conditions and adjusts the media encoding bitrate accordingly to optimize the user experience and avoid buffering issues (Compl. ¶33).
• Asserted Claims: At least claim 1 is asserted (Compl. ¶124).
• Accused Features: The complaint alleges that the Slack Communication Platform (including Slack Huddles) infringes by receiving audio and video data, receiving feedback (e.g., jitter, packet loss), estimating network conditions, determining optimal bitrates, and encoding the media streams at those bitrates (Compl. ¶¶113-118).

Multi-Patent Capsule: U.S. Patent No. 7,987,285

• Patent Identification: U.S. Patent No. 7,987,285, “Adaptive Bitrate Management for Streaming Media Over Packet Networks,” Issued July 26, 2011.
• Technology Synopsis: The patent is directed to solving problems with delivering bandwidth-intensive content over capacity-limited shared links, particularly wireless networks (Compl. ¶40). The disclosed method involves receiving a receiver report, estimating network conditions, determining an optimal session bitrate, and providing media data at that optimal bitrate (Compl. ¶39).
• Asserted Claims: At least claim 2 is asserted (Compl. ¶143).
• Accused Features: The Slack Communication Platform is accused of infringing by receiving receiver reports from a client during a WebRTC session, using those reports to estimate network conditions (e.g., packet loss, jitter, round-trip time), and applying stability criteria to determine and adjust an optimal session bitrate (Compl. ¶¶131-137).

Multi-Patent Capsule: U.S. Patent No. 7,991,904

• Patent Identification: U.S. Patent No. 7,991,904, “Adaptive Bitrate Management for Streaming Media Over Packet Networks,” Issued August 2, 2011.
• Technology Synopsis: The patent addresses the problem of rate control for media streaming in wireless environments, particularly the limitations of protocols like TCP for pseudo-streaming (Compl. ¶¶48-49). The invention provides a framework for adjusting the bitrate of streaming sessions based on instantaneous network capacity, including adjusting allocation between audio and video streams (Compl. ¶47).
• Asserted Claims: At least claim 11 is asserted (Compl. ¶164).
• Accused Features: The Slack Communication Platform is accused of using TCP acknowledgment feedback (via RTCP-FB for transport congestion control) to dynamically adjust session bitrates, including allocating bitrate between audio and video to prioritize one stream over the other based on network conditions (Compl. ¶¶153-157).

Multi-Patent Capsule: U.S. Patent No. 8,230,105

• Patent Identification: U.S. Patent No. 8,230,105, “Adaptive Bitrate Management for Streaming Media Over Packet Networks,” Issued July 24, 2012.
• Technology Synopsis: The patent addresses challenges in delivering optimized streaming media over wireless networks, such as buffer overflow and playback stall (Compl. ¶55-56). It teaches a method of receiving a receiver report, estimating network conditions, determining an optimal session bitrate, and then providing media data based on that bitrate, with a focus on joint management of audio and video streams (Compl. ¶¶54, 57).
• Asserted Claims: At least claim 16 is asserted (Compl. ¶186).
• Accused Features: The Slack Communication Platform is accused of receiving an optimal session bitrate based on network conditions, allocating this bitrate between audio and video streams based on a selected metric (e.g., privileging one type of data), and compressing the streams according to the determined bitrates (Compl. ¶¶172-179).

Multi-Patent Capsule: U.S. Patent No. 8,521,901

• Patent Identification: U.S. Patent No. 8,521,901, “TCP Burst Avoidance,” Issued August 27, 2013.
• Technology Synopsis: The patent addresses the problem of TCP packet bursts in high-speed data networks, which can cause packet loss and inefficient bandwidth use (Compl. ¶¶64-65). The solution involves implementing a packet scheduler layer between the network and transport layers to smooth the delivery of TCP packets by strategically delaying them (Compl. ¶66).
• Asserted Claims: At least claim 1 is asserted (Compl. ¶205).
• Accused Features: The MuleSoft Anypoint Platform and Cloudhub 2.0 are accused of infringing by receiving TCP packets, determining if a packet is part of a bursty transmission by checking if a burst count exceeds a threshold, calculating a delay time, and delivering the packet based on that delay (Compl. ¶¶193-200).

III. The Accused Instrumentality

• Product Identification: Salesforce Lightning for the Salesforce Platform (including Lightning Web Components or LWC), the Slack Communication Platform (including Slack Huddles), and the MuleSoft Anypoint Platform and MuleSoft Cloudhub 2.0 (Compl. ¶¶71, 90, 111, 129, 148, 169, 190).
• Functionality and Market Context:
  • Salesforce Lightning Platform: This is a component-based framework for building web applications. The complaint focuses on its use of Lightning Web Components (LWC), which employ Document Object Model (DOM) variations (shadow and light DOM) to structure and render webpages (Compl. ¶¶73, 76). The technology is alleged to use templates and screen-responsive properties to construct webpages dynamically for different devices, such as mobile phones (Compl. ¶¶80, 25).
  • Slack Communication Platform: This is a communication tool that includes "Slack Huddles," a feature for audio and video media streaming (Compl. ¶111). The complaint alleges this platform uses adaptive bitrate management, receiving feedback reports on network quality (e.g., jitter, packet loss) during WebRTC sessions to dynamically adjust audio and video bitrates for optimal performance (Compl. ¶¶113-115, 131-134).
  • MuleSoft Anypoint Platform: This product is described as technology for a data packet scheduler that reduces packet bursts (Compl. ¶191). It allegedly manages TCP traffic by determining if incoming packets are part of a bursty transmission (e.g., by checking against a request-per-second limit) and managing packet delivery accordingly (Compl. ¶¶195, 199-200).

IV. Analysis of Infringement Allegations

'167 Patent Infringement Allegations

A screenshot from Salesforce's developer guide shows how to declare a property as "screen-size responsive" in a component's configuration file to construct an adapted webpage (Compl. p. 25).

• Identified Points of Contention:
  • Scope Questions: A central question may be whether the process of rendering a component-based webpage in Salesforce LWC, which involves templates and shadow/light DOM, constitutes "transforming... a first DOM... to a second DOM" as contemplated by the patent. The defense may argue that LWC rendering is a standard web development practice, not the specific transformation method claimed.
  • Technical Questions: What evidence demonstrates that the accused products create a distinct "second DOM" that is then serialized, as opposed to simply rendering a single, responsive DOM based on device parameters? The complaint cites developer documentation, which may be framed by the defense as describing general capabilities rather than the specific, sequential process required by the claim.

'618 Patent Infringement Allegations

A Salesforce developer guide screenshot illustrates how CSS styles defined in a parent component can apply to a child component in light DOM, allegedly showing the wrapping of nodes with matching style data (Compl. p. 30).

• Identified Points of Contention:
  • Scope Questions: Does the term "essential style data" have a specific technical meaning in the patent that is narrower than the general style information (e.g., layout, spacing) managed by the accused SLDS grid utility? The defense may argue that the accused product performs standard responsive web design, not the claimed method of defining, extracting, and discarding a specific subset of "essential" styles.
  • Technical Questions: What is the evidence that the accused products perform an explicit, affirmative step of "discarding layout-specific style data"? The complaint points to adaptive styling hooks (Compl. p. 28), but it is a question for the court whether adapting styles for different screens is the same as the claimed "discarding" step.

V. Key Claim Terms for Construction

For the ’167 Patent

• The Term: "transforming the first DOM to a second DOM"
• Context and Importance: This term is central to the infringement analysis. The dispute may turn on whether Salesforce's use of LWC, templates, and shadow/light DOM constitutes the claimed "transformation" from a first, complete DOM into a second, distinct, and complete DOM before serialization, or if it is merely a dynamic rendering process that does not create a discrete "second DOM" intermediate.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The specification discusses the overall goal of adapting content for a mobile device, stating the invention relates to "adapting the response data based on the identification data" ('167 Patent, Abstract). This focus on the adaptive outcome could support a broader reading that covers any process achieving that result.
  • Evidence for a Narrower Interpretation: The claim uses sequential language ("identifying," then "transforming," then "serializing," then "constructing"). The detailed description discusses parsing an "original DOM tree structure" and creating "adapted sub-pages" ('167 Patent, col. 10:1-25). This may support a narrower construction requiring a specific, multi-step process where a complete and distinct second DOM is created as an intermediate work product.

For the ’618 Patent

• The Term: "essential style data"
• Context and Importance: The definition of this term is critical. Infringement depends on whether the accused products extract a specific subset of styles "defined as being essential" and then discard other, "layout-specific" styles from that subset. Practitioners may focus on this term because if it is construed to require a pre-defined or explicitly identified set of "essential" styles, infringement may be more difficult to prove than if it is construed to cover any generic process of simplifying styles for mobile viewing.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The patent's background describes the general problem of usability on small screens and slow load times (Compl. ¶25). This context could support a view that any style data retained to preserve the core look-and-feel while simplifying layout is "essential."
  • Evidence for a Narrower Interpretation: The claim language recites a specific action: extracting style data that includes a "subset of style properties that are defined as being essential style data" and then "discarding" layout-specific data "from the subset" ('618 Patent, col. 12:1-6). This phrasing suggests a two-step filtering process on a specifically "defined" category of data, not just a general adaptation of all styles.

VI. Other Allegations

No indirect or willful infringement is alleged in the complaint.

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

• A central issue for the content adaptation patents ('167 and '618) will be one of process specificity: do the accused Salesforce Lightning products, which use modern, component-based frameworks for responsive web design, perform the specific, sequential steps of DOM transformation and style-data filtering as recited in the claims, or do they achieve a similar outcome through fundamentally different technical means?
• For the adaptive streaming patents ('664, '285, '904, '105), a key evidentiary question will be one of functional mapping: can Plaintiff demonstrate that the data points and feedback mechanisms used in the accused Slack Huddles platform (e.g., WebRTC statistics) directly correspond to the specific inputs required by the claims, such as "receiver report" and "stability criterion," as those terms are defined and used within the patents?
• A core question for the '901 patent will be one of definitional scope: does the accused MuleSoft platform's alleged practice of rate-limiting based on a "burst count threshold" (Compl. ¶198) constitute the claimed "packet scheduler layer" that "smoothens the delivery" of TCP packets by "delaying" them, or is it a standard traffic management feature that operates differently from the specific layered architecture described in the patent?