Kojicast LLC v. FUNimation Productions LLC

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Kojicast, LLC (Texas)
  • Defendant: Funimation Productions, LLC (Delaware)
  • Plaintiff’s Counsel: ETHERIDGE LAW GROUP, Group
• Case Identification: 2:19-cv-00132, E.D. Tex., 04/24/2019
• Venue Allegations: Venue is based on Defendant’s principal place of business being located in Flower Mound, Texas, which is within the Eastern District of Texas.
• Core Dispute: Plaintiff alleges that Defendant’s FunimationNow video delivery platform infringes a patent related to methods for streaming media from a server and switching the streaming destination between a mobile device and a separate media playback device.
• Technical Context: The technology, commonly known as "casting," addresses the user experience of seamlessly transferring media playback from a portable device to a stationary one (e.g., a TV) while using the portable device as a remote control that displays playback progress.
• Key Procedural History: The complaint notes that the patent-in-suit was examined and granted after the Supreme Court's Alice decision on patent eligibility. It also highlights that the inventor, Koji Yoden, prosecuted the patent pro se and overcame rejections based on prior art from Lee, Klein, and Nakamura by adding new claims. The complaint preemptively argues that Google's Chromecast and Apple's Airplay are not prior art to the patent.

Case Timeline

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

U.S. Patent No. 9,037,683 - "MEDIA ASSET STREAMING OVER NETWORK TO DEVICES", issued May 19, 2015

The Invention Explained

• Problem Addressed: The patent addresses the cumbersome process a user faced when wanting to switch media playback from a portable device, with its small screen and speakers, to a home television or audio system, which required manually stopping playback on one device, then finding and restarting it on another. (Compl. ¶¶12-13; ’683 Patent, col. 1:33-40).
• The Patented Solution: The invention describes a coordinated system of three distinct devices: a server, a mobile device, and a media playback device. A user selects content from a list on the mobile device and chooses a streaming destination. If the media playback device is chosen, the server streams the content directly to it while simultaneously sending playback progress information to the mobile device. This allows the mobile device to function as a remote control, displaying playback status even though it is no longer the primary recipient of the media stream. (Compl. ¶¶15-16; ’683 Patent, Abstract, FIG. 15).
• Technical Importance: This approach, now widely known as "casting," unified the user experience across personal and shared devices, making media consumption more flexible and seamless. (Compl. ¶18).

Key Claims at a Glance

• The complaint asserts independent claims 1 (method), 9 (computer product), and 16 (media playback device). (Compl. ¶71).
• Independent Claim 1 (Method) requires:
  • Providing a database associating a mobile device with media playback device(s) via discrete IP addresses on the Internet.
  • Listing media thumbnails on the mobile device’s graphical user interface (GUI).
  • In response to user input selecting a thumbnail, determining a streaming destination (either the mobile device or a playback device).
  • If the playback device is chosen, streaming media content to it from the server while in parallel streaming progress information from the server to the mobile device.
  • Displaying the progress on the mobile device's GUI while the media plays back on the playback device.
• Independent Claim 9 (Computer Product) requires:
  • A non-transitory computer-readable medium with instructions for a mobile device to perform operations that largely mirror the steps of method claim 1, including holding a device database, listing thumbnails, and, in response to user input, requesting the server to direct the media and progress streams accordingly.
• Independent Claim 16 (Media Playback Device) requires:
  • A media playback device comprising circuitry, a processor, and memory to perform operations.
  • The operations include receiving a streaming request generated by a mobile device, establishing a connection with the server, playing back the streamed content, and forwarding progress information to the mobile device in parallel to the playback.
• The complaint reserves the right to assert dependent claims 2-3, 6-7, 12-13, and 16-17. (Compl. ¶71).

III. The Accused Instrumentality

Product Identification

• The "FunimationNow" video delivery platform, which includes applications for Apple iOS and Android operating systems. (Compl. ¶70).

Functionality and Market Context

• The complaint alleges that the FunimationNow system provides "casting features." (Compl. ¶70). This functionality allegedly enables a user to select a media item on a mobile device and "cast" it for playback on one or more separate media playback devices. (Compl. ¶70). The complaint does not provide specific technical details about the operation of the FunimationNow platform beyond this general description of its casting capability. No probative visual evidence provided in complaint.

IV. Analysis of Infringement Allegations

'683 Patent Infringement Allegations

Identified Points of Contention

• Scope Questions: The claims require a specific three-party architecture where the server, mobile device, and playback device are identified by "discrete IP addresses on the Internet." A potential issue is whether Funimation's system, which may heavily utilize a local area network (LAN) for communication between the mobile device and the playback device, meets this "on the Internet" limitation for all three components.
• Technical Questions: A key factual question is whether the FunimationNow system implements the specific data flow required by the claim, namely that the server actively streams progress information to the mobile device in parallel with the media stream. The defense may argue that the system uses an alternative, unclaimed method, such as the mobile device polling the playback device directly for status updates over a local network, which would not involve the server in the manner claimed.

V. Key Claim Terms for Construction

The Term: "discrete IP addresses on the Internet"

• Context and Importance: This term is foundational to the claimed system architecture. The infringement analysis depends on whether the accused system's components (mobile device, server, playback device) are configured in this specific network topology. Practitioners may focus on this term because modern casting systems often rely on local network discovery and communication (e.g., via private IP addresses), which may not align with a strict reading of "on the Internet."
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The specification states that the "network 400 can be the Internet, a LAN (Local Area Network), the WiMAXTM, or other one or a combination of communication platforms." (’683 Patent, col. 6:57-62). Plaintiff may argue this supports interpreting "on the Internet" broadly to include devices on an internet-connected LAN.
  • Evidence for a Narrower Interpretation: The claim language itself explicitly recites "on the Internet," which is more specific than the specification's description of "network 400." A defendant could argue that this choice of words in the claim deliberately limits its scope to systems where all three devices have distinct, publicly routable Internet Protocol addresses, as distinguished from private addresses on a LAN. The complaint's own emphasis on three discrete IP addresses reinforces the centrality of this limitation. (Compl. ¶¶28, 43).

The Term: "streaming progress information from the server to the mobile device in parallel"

• Context and Importance: This limitation defines the specific data flow for keeping the mobile device synchronized. Whether the accused system infringes may turn on whether it is the server that sends this information and whether it does so "in parallel."
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: Plaintiff may argue "in parallel" simply means "concurrently," covering any implementation where the mobile device receives updates from the server while the playback device receives the media stream. The flowchart in FIG. 15 shows the "Cloud Server Computer 500" sending "Progress Info." (S2065) to the "Computing Device 100" after initiating the stream to the "Media Playing Device 200." (’683 Patent, FIG. 15).
  • Evidence for a Narrower Interpretation: A defendant may argue this requires a specific server-side function that actively pushes two separate, simultaneous streams. If the accused system operates differently—for example, if the mobile app simply polls the server for status in a standard request-response cycle or gets status from the playback device—it may not meet the "streaming...in parallel" requirement.

VI. Other Allegations

• Indirect Infringement: The complaint alleges active inducement, stating that Funimation provides its FunimationNow app and instructs users on how to use the infringing "casting" functionality through materials like training videos and user guides. (Compl. ¶73). It also alleges contributory infringement, asserting the FunimationNow system is a material component of the patented invention and not a staple article of commerce. (Compl. ¶74).
• Willful Infringement: Willfulness is alleged based on Defendant’s knowledge of the '683 patent from, at the latest, the date of service of the complaint, supporting a claim for post-filing willfulness. (Compl. ¶76).

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

• A core issue will be one of architectural scope: Does the FunimationNow system, which likely operates across both a private LAN and the public internet, satisfy the claim limitation requiring a server, mobile device, and media playback device to each be identified by "discrete IP addresses on the Internet"?
• A key evidentiary question will be one of data-flow mechanics: Does the accused system practice the specific three-party data path recited in the claims, where the server pushes a media stream to the playback device while simultaneously pushing a parallel progress stream to the mobile device, or does it achieve a similar result through a different, non-infringing technical implementation?