Wiremed Tech LLC v. Adobe Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Wiremed Tech LLC (Texas)
  • Defendant: Adobe Systems Incorporated (Delaware)
  • Plaintiff’s Counsel: Stamoulis & Weinblatt LLC
• Case Identification: 1:18-cv-01066, D. Del., 07/18/2018
• Venue Allegations: Venue is asserted in the District of Delaware based on Defendant’s incorporation in that state.
• Core Dispute: Plaintiff alleges that Defendant’s Adobe Character Animator software infringes two patents related to real-time multimedia visual programming systems.
• Technical Context: The technology concerns visual programming interfaces that allow users, including those with no programming skills, to link various data inputs to control real-time multimedia outputs.
• Key Procedural History: The complaint notes that U.S. Patent No. 6,944,825 is a continuation of the application that led to U.S. Patent No. 6,331,864. It also mentions that a prior owner of the patents, Onadime, Inc., implemented the patented method in a product called Onamation.

Case Timeline

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

U.S. Patent No. 6,331,864 - Real-Time Multimedia Visual Programming System

Issued December 18, 2001

The Invention Explained

• Problem Addressed: The patent identifies a deficiency in prior art visual programming systems, stating they were not well-suited for exploring real-time data streams because they required expert programming knowledge and lacked essential interactive capabilities for manipulating data during the data flow (Compl. ¶14; ’864 Patent, col. 1:51-62).
• The Patented Solution: The invention provides a visual programming interface that allows a user with little or no programming skill to create real-time multimedia programs (Compl. ¶16). It achieves this by representing input and output functions as graphical "interface leads" that can be visually linked. A key aspect is the use of a universal, normalized data layer, which translates raw data from any input into a common format, allowing disparate input and output types to be linked without concern for their underlying data structures or ranges (’864 Patent, col. 4:49-52).
• Technical Importance: This approach aimed to democratize multimedia content creation by enabling users to build and test complex, interactive audio-visual programs in real-time without writing traditional code (Compl. ¶16; ’864 Patent, col. 2:9-21).

Key Claims at a Glance

• The complaint asserts independent claims 3 and 15, and dependent claims 4, 5, and 8 (Compl. ¶28).
• Independent Claim 3, a method claim, includes these essential elements:
  • defining input functions based on the data inputs;
  • defining output functions based on the data outputs;
  • linking at least one input function to at least one output function to indicate the output function will change as the input function changes, and without determining if the type of data input is compatible with the type of data output; and
  • dynamically controlling the output function by changing the input function, where the changing and controlling occur simultaneously.

U.S. Patent No. 6,944,825 - Real-Time Multimedia Visual Programming System

Issued September 13, 2005

The Invention Explained

• Problem Addressed: As a continuation of the ’864 Patent, the ’825 Patent addresses the same problem of enabling users without programming expertise to create interactive, real-time multimedia experiences (’825 Patent, col. 1:55-62).
• The Patented Solution: The invention describes an animation program on a computer-readable medium that uses "transmit controls" (representing inputs) and "receive controls" (representing outputs) (’825 Patent, Abstract). A user can define a relationship between these controls without the system needing to determine if the underlying data types are compatible, enabling dynamic, real-time generation of the animated output based on changes to the input (’825 Patent, col. 10:9-24).
• Technical Importance: The invention provides a framework for software that allows for flexible, real-time character animation and multimedia control driven by a variety of user inputs, such as audio, motion, or mouse movements (’825 Patent, col. 10:10-12).

Key Claims at a Glance

• The complaint asserts independent claims 9 and 15, and dependent claim 11 (Compl. ¶42).
• Independent Claim 9, a claim for an animation program on a computer-readable medium, includes these essential elements:
  • representing input to the animation program with at least one transmit control;
  • representing the output of the animation program with at least one receive control;
  • defining a relationship between the transmit and receive controls without determining if the input data type is compatible with the output type; and
  • dynamically generating the program's output in real-time by changing the input represented by the transmit control.

III. The Accused Instrumentality

Product Identification

The complaint identifies Adobe Character Animator as the Accused Instrumentality (Compl. ¶28).

Functionality and Market Context

• Adobe Character Animator is described as a program that allows a user to control the movement and expression of an animated character in real-time (Compl. ¶29). It achieves this by accepting simultaneous inputs from various sources, such as a webcam (for face tracking), a microphone (for lip-sync), a mouse, and a keyboard (Compl. ¶30).
• The complaint alleges that user inputs are mapped to "behaviors" (e.g., "Face," "Lip Sync," "Dragger") that control the character's animation (Compl. ¶30, ¶32). A screenshot from an Adobe tutorial shows a user interface with a webcam feed, an animated character, and a properties panel listing different types of inputs available to control the character (Compl. p. 10).

IV. Analysis of Infringement Allegations

'864 Patent Infringement Allegations

'825 Patent Infringement Allegations

Identified Points of Contention

• Scope Questions: A primary issue may be whether the architectural concepts in Adobe Character Animator (e.g., "behaviors," "triggers," "layers") fall within the scope of the patents' terminology (e.g., "transmit/receive controls," "forms," "interface leads"). The court will need to determine if a "behavior" in the accused product is the legal equivalent of a "form" or "control" as defined by the patents.
• Technical Questions: The infringement theory hinges on the allegation that the accused software links inputs and outputs "without determining" compatibility, a function the patent enables via a "normalized data" layer. A key technical question is whether the complaint provides sufficient evidence that the accused software actually operates this way. The defense may argue that input flexibility is achieved through a different, non-infringing technical architecture that does not rely on the specific normalization method taught in the patents.

V. Key Claim Terms for Construction

• The Term: "without determining if the type of data input... is compatible with the type of data output"

  • Context and Importance: This negative limitation is central to the plaintiff's infringement theory. Practitioners may focus on this term because its construction will dictate what level of proof is required to show infringement. The plaintiff's case relies on interpreting the product's external flexibility (accepting various inputs for one output) as evidence of this internal lack of a compatibility check.
  • Intrinsic Evidence for a Broader Interpretation: The specification supports this by teaching "the use of normalized data which allows the linking of leads without concern for raw data types or raw data numerical ranges" ('864 Patent, col. 5:19-22). This suggests the system is architected to be agnostic by design.
  • Intrinsic Evidence for a Narrower Interpretation: The specification also discloses that a "skilled programmer" first determines raw data ranges and creates translation calculations before an "unskilled user" interacts with the system ('864 Patent, col. 3:62-65, col. 4:3-16). A party could argue this constitutes a form of compatibility determination, just one that occurs at a different stage.

• The Term: "transmit control" and "receive control"

  • Context and Importance: The complaint maps these terms to the "behaviors" and animation outputs of the accused software (Compl. ¶44-45). The viability of the infringement case depends on whether these software components in Adobe Character Animator meet the patent's definition of these controls.
  • Intrinsic Evidence for a Broader Interpretation: The patent defines an "input device function" simply as an "operation or function performed by an input" ('864 Patent, col. 3:35-37), suggesting "transmit control" could be construed broadly to cover any software object representing such a function.
  • Intrinsic Evidence for a Narrower Interpretation: The preferred embodiment consistently depicts these controls as specific graphical user interface elements called "interface leads" within rectangular "forms" (’864 Patent, Fig. 3, Fig. 6). A party could argue that the terms should be limited to this more specific graphical implementation, rather than covering any abstract software component.

VI. Other Allegations

The complaint does not contain specific counts for indirect or willful infringement.

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

This case will likely turn on two central questions for the court's determination:

• A question of architectural equivalence: Does the accused Adobe Character Animator software, with its system of "behaviors," "triggers," and "layers," implement the specific architecture claimed in the patents, which is described in terms of graphical "forms" containing "transmit" and "receive" interface leads?
• A question of evidentiary proof: Can the plaintiff demonstrate that the accused product's internal operation functions "without determining" input/output compatibility by using a normalization method as taught in the patents, or can the defendant show that its system's input flexibility is achieved through a different, non-infringing technical mechanism?