DCT
2:17-cv-05887
Blue Spike LLC v. Visual Land Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Blue Spike, LLC (Texas)
- Defendant: Visual Land Inc. (California)
- Plaintiff’s Counsel: Garteiser Honea, PLLC
- Case Identification: Blue Spike, LLC v. Visual Land Inc., 2:17-cv-05887, C.D. Cal., 08/08/2017
- Venue Allegations: Venue is alleged to be proper because Defendant is incorporated in California and maintains its principal place of business within the Central District of California.
- Core Dispute: Plaintiff alleges that Defendant’s Android-based electronic devices, which utilize Address Space Layout Randomization (ASLR), infringe patents related to methods for protecting software from reverse engineering and unauthorized modification.
- Technical Context: The technology at issue involves dynamically randomizing the memory locations of software components during execution to act as a security measure against analysis and tampering.
- Key Procedural History: The complaint alleges that Defendant was notified of the patents-in-suit via a prior lawsuit filed by Plaintiff against Defendant in the Eastern District of Texas on October 11, 2016. The complaint also references prior litigation initiated by the Plaintiff against other technology companies involving the '719 patent.
Case Timeline
| Date | Event |
|---|---|
| 1996-01-17 | ’569 Patent Priority Date |
| 1998-03-24 | ’719 Patent Priority Date |
| 1998-04-28 | ’569 Patent Issue Date |
| 2011-10-19 | Approximate launch of Android 4.0, the earliest accused OS version |
| 2015-01-06 | ’719 Patent Issue Date |
| 2016-10-11 | Prior complaint filed against Defendant, alleged to provide notice |
| 2017-08-08 | Complaint Filing Date |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 5,745,569 - Method for Stega-Cipher Protection of Computer Code, issued April 28, 1998
The Invention Explained
- Problem Addressed: The patent addresses the problem of software piracy and the ease with which unauthorized parties can analyze a program's object code in memory to "patch" it, thereby bypassing copy protection or other licensing mechanisms ('569 Patent, col. 1:12-25). A specific threat identified is the analysis of memory snapshots to understand and defeat a program's functionality ('569 Patent, col. 7:21-29).
- The Patented Solution: The patent proposes making software analysis difficult by disrupting the predictability of code locations in memory. One described method involves a "memory scheduler," which is a special code resource that, during the program's execution, "intentionally shuffles the other code resources randomly in memory" ('569 Patent, col. 8:1-8). This constant relocation makes it difficult for an attacker to analyze a consistent memory state ('569 Patent, col. 7:21-30).
- Technical Importance: This approach represented a shift from static protection to dynamic, run-time obfuscation, aiming to create a moving target for would-be reverse engineers. ('569 Patent, col. 7:39-44).
Key Claims at a Glance
- The complaint asserts independent claim 16 (Compl. ¶25).
- The essential elements of claim 16 are:
- A method for copy protecting a software application which includes a plurality of executable code resources loaded in memory.
- Determining an address in memory associated with each of the executable code resources.
- Intermittently relocating each of the executable code resources to a different memory address during the software application's execution.
- The complaint alleges infringement of "one or more claims" (Compl. ¶23).
U.S. Patent No. 8,930,719 - Data Protection Method and Device, issued January 6, 2015
The Invention Explained
- Problem Addressed: As a continuation of the '569 patent's family, the '719 patent addresses the same fundamental problem: protecting software from unauthorized analysis and modification by making its memory structure unpredictable ('719 Patent, col. 2:40-44).
- The Patented Solution: The patent claims a computing device having a "memory scheduler code resource" that not only "functions to shuffle said other code resources in said memory," but is also specifically "designed to modify a stack frame in said memory" ('719 Patent, col. 16:12-17). The specification, through its incorporation of related patents, describes this process as modifying the program counter and stack frame to allow the scheduler to jump to a new location while ensuring the program can return to the correct calling frame ('719 Patent, col. 1:15-18; '569 Patent, col. 8:12-20).
- Technical Importance: This invention refines the memory-shuffling concept by integrating it with the manipulation of the stack frame, a fundamental component that manages the execution flow of a program, thereby creating a potentially more deeply embedded security mechanism. ('719 Patent, col. 15:45-54).
Key Claims at a Glance
- The complaint asserts independent claim 1 (Compl. ¶35).
- The essential elements of claim 1 are:
- A computing device with an operating system and memory storing application software.
- The application software comprises a "memory scheduler code resource" and "other code resources."
- The application software is designed to call the memory scheduler.
- When called, the memory scheduler functions to shuffle the other code resources in memory.
- The memory scheduler is also designed to modify a stack frame in memory.
- The complaint alleges infringement of "one or more claims" (Compl. ¶33).
III. The Accused Instrumentality
Product Identification
- Defendant's A-, LA-, LC-, LR-, M-, and Q-series of devices that utilize various versions of the Android Operating System, beginning with version 4.0 (Compl. ¶4, ¶17).
Functionality and Market Context
- The core accused functionality is Address Space Layout Randomization (ASLR) as implemented in the Android OS (Compl. ¶16). The complaint describes ASLR as a security technique that "protects software by shuffling it in computer memory" to "reduce predictability" (Compl. ¶15). It alleges that Android implements ASLR by randomizing the memory locations for various components, such as the stack, heap, and libraries, when a process is initiated (Compl. ¶16, ¶25). The complaint alleges the Accused Products are sold through numerous resellers, distributors, and websites (Compl. ¶6).
IV. Analysis of Infringement Allegations
'569 Patent Infringement Allegations
| Claim Element (from Independent Claim 16) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| determining an address within the memory of the computer system associated with each of the plurality of executable code resources | The Android OS with ASLR determines the addresses for memory areas like the stack, heap, and libraries that are part of a process. | ¶25 | col. 8:14-19 |
| intermittently relocating each of the plurality of executable code resources to a different address within the memory of the computer during execution of the software application | The ASLR feature gives each instance of an executable a "randomized address space layout at execution time," shuffling where memory areas are mapped. A referenced exhibit states ASLR "randomizes where various areas of memory (e.g. stack, heap, libs, etc.) are mapped." | ¶25, citing Ex. G, H | col. 8:6-8 |
Identified Points of Contention
- Scope Questions: A central question may be whether the claim preamble, "copy protecting a software application," limits the claim to technologies designed for that explicit purpose, or if it can read on general security features like ASLR which have the effect of making software analysis more difficult.
- Technical Questions: The infringement theory may face questions regarding whether ASLR, which primarily randomizes memory locations at the time a program is loaded, satisfies the claim limitation of "intermittently relocating...during execution." The court may have to determine if "during execution" encompasses load-time or requires repeated shuffling after the program is already running.
'719 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A computing device for running application software, comprising: an operating system... | The Accused Products are devices that run the Android OS, described in a referenced exhibit as a "Linux based OS." | ¶35, citing Ex. I | col. 11:13-17 |
| wherein said application software comprises (1) a memory scheduler code resource and (2) other code resources | The Android OS with ASLR is alleged to be the "memory scheduler code resource," and the various memory areas it shuffles (stack, heap, libraries) are alleged to be the "other code resources." | ¶35, citing Ex. G, J | col. 16:6-9 |
| wherein said memory scheduler code resource, when called, functions to shuffle said other code resources in said memory | The ASLR feature is alleged to "randomize[] the base points of the stack, heap, shared libraries, and base executables." | ¶35, citing Ex. J | col. 16:12-14 |
| wherein said memory scheduler code resource is designed to modify a stack frame in said memory | The complaint alleges the Accused Products meet this limitation through the use of ASLR, but provides no specific factual detail on how ASLR modifies a stack frame. | ¶35 | col. 16:15-17 |
Identified Points of Contention
- Scope Questions: The claim requires the "application software" to comprise the "memory scheduler." A point of contention may be whether the ASLR functionality, an operating system-level feature, can be considered part of the "application software" when the claim lists the "operating system" as a separate and distinct component.
- Technical Questions: The complaint's allegation for the "modify a stack frame" limitation appears conclusory. A key technical question will be what evidence, if any, demonstrates that the accused ASLR implementation performs this specific, claimed function.
V. Key Claim Terms for Construction
The Term: "intermittently relocating... during execution of the software application" ('569 Patent, Claim 16)
- Context and Importance: This term's construction is critical because ASLR typically acts at program load-time, not continuously thereafter. Whether a one-time randomization upon loading qualifies as "intermittently relocating...during execution" will likely be a central point of dispute.
- Intrinsic Evidence for a Broader Interpretation: A party could argue that the entire lifecycle of a running program, including its loading phase, constitutes "execution." The specification uses the term "run-time" ('569 Patent, col. 5:9), which could be interpreted broadly.
- Intrinsic Evidence for a Narrower Interpretation: The specification describes the "memory scheduler" being called "periodically, or at random or pseudo random intervals" ('569 Patent, col. 8:5-6), which suggests a repeated action after the program has already started, not a single event at load-time.
The Term: "application software" ('719 Patent, Claim 1)
- Context and Importance: The claim requires the "application software" to comprise the memory scheduler. Since ASLR is a feature of the Android OS, the defendant will likely argue it is part of the "operating system," which the claim lists as a separate element. Practitioners may focus on this term because its definition could render the claim's structure inapplicable to the accused OS-level functionality.
- Intrinsic Evidence for a Broader Interpretation: A party could argue that from a functional perspective, when an application is executed, it utilizes OS services like ASLR, and the combination forms the running "application software" system.
- Intrinsic Evidence for a Narrower Interpretation: The claim's plain language explicitly distinguishes between "an operating system" and "application software." This structure suggests they are mutually exclusive components, and a feature of one (the OS) cannot be a sub-component of the other (the application).
VI. Other Allegations
Indirect Infringement
- The complaint alleges both induced and contributory infringement, asserting that the Accused Products are "especially made and adapted to infringe" and have "no substantial non-infringing uses" (Compl. ¶26, ¶36). It further alleges Defendant induces its customers and partners to infringe by selling the products (Compl. ¶26, ¶36).
Willful Infringement
- The willfulness allegation is primarily based on alleged pre-suit knowledge. The complaint asserts that Defendant knew of the patents-in-suit as of October 11, 2016, the date of a prior infringement complaint filed by Blue Spike against it (Compl. ¶29a, ¶39a). It further alleges knowledge of the '719 patent from widely publicized litigation against other smartphone manufacturers (Compl. ¶39b).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of temporal scope: can the phrase "intermittently relocating...during execution" from the '569 patent be construed to cover the one-time, load-time address randomization performed by the accused ASLR technology, or does the claim require repeated shuffling after execution has commenced?
- A key architectural question will be one of component definition: does the accused ASLR functionality, a feature of the operating system, reside within the "application software" as required by the structure of the '719 patent's claims, or are these mutually exclusive components, placing ASLR outside the claim scope?
- A central evidentiary question will be one of functional proof: what specific evidence will be presented to demonstrate that the accused ASLR system performs the explicit function of "modify[ing] a stack frame in said memory" as claimed in the '719 patent, a technical limitation for which the complaint currently provides no detailed support?