CrowdStrike Inc v. Taasera Licensing LLC

1. Case Identification

• Case #: IPR2024-00027
• Patent #: 7,673,137
• Petitioner(s): CrowdStrike, Inc.
• Patent Owner(s): Taasera Licensing LLC
• Challenged Claims: 1, 2, 6, 8, 9, 12, and 25

2. Patent Overview

• Title: System and Method for Implementing Computer Security
• Brief Description: The ’137 patent discloses a two-phased computer security system operating at the kernel level. A pre-execution phase validates a program as it is being loaded into memory; if validated, it executes normally. If not, the system enters an execution phase where additional security modules monitor the unvalidated program's behavior in real-time.

3. Grounds for Unpatentability

Ground 1: Obviousness over Dan and Lambert - Claims 6, 8, 9, 12, and 25 are obvious over Dan in view of Lambert.

• Prior Art Relied Upon: Dan (a 1997 IBM research paper titled "Chakravyuha (CV): A Sandbox Operating System Environment for Controlled Execution of Alien Code") and Lambert (Application # 2002/0099952).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that Dan taught a sandbox environment that monitors untrusted programs by modifying the operating system's kernel-level call interface, but inefficiently monitors all uncertified code. Lambert taught a more advanced pre-execution system that interrupts a program's loading process to validate it by comparing its hash value against a policy of known "good," "bad," or "untrusted" code. The proposed combination allegedly taught a method where a program is first interrupted and validated per Lambert. If validated as "good," it is permitted to execute without the costly kernel-level monitoring of Dan. If not validated, it is then monitored using Dan's kernel-level techniques.
  • Motivation to Combine: A POSITA would combine Lambert's efficient pre-execution validation with Dan's kernel monitoring to improve both performance and security. This combination would avoid the significant resource cost of monitoring known trusted applications while adding the capability to block known malicious code before execution, addressing key shortcomings in Dan's system.
  • Expectation of Success: Petitioner asserted that integrating these known security methods to achieve their respective, predictable benefits was a straightforward application of existing techniques for a POSITA.

Ground 2: Obviousness over Lambert, Dan, and Schmid - Claims 1 and 2 are obvious over Lambert in view of Dan and Schmid.

• Prior Art Relied Upon: Lambert (Application # 2002/0099952), Dan (the 1997 IBM research paper), and Schmid (Patent 7,085,928).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner contended that Lambert provided a high-level framework for a security system with pre-execution validation, a "detection module," and an "execution module," but lacked specific implementation details, leaving it vulnerable to being bypassed. Schmid taught a non-bypassable, kernel-level device driver for intercepting system service requests. Dan taught a specific method for kernel-level monitoring by modifying the OS call interface. The combination allegedly supplied the necessary implementation details for Lambert's framework: Schmid’s kernel driver was used to implement Lambert’s "detection module" robustly, while Dan's kernel monitoring system was used to implement Lambert's "execution module."
  • Motivation to Combine: A POSITA would recognize that Lambert's functionally-described system could be bypassed by malicious code making direct calls to the kernel. To create a robust and secure system, a POSITA would be motivated to implement Lambert's modules using the known kernel-level techniques taught by Schmid (for non-bypassable interception) and Dan (for effective kernel-level monitoring), thereby hardening the conceptual system disclosed in Lambert.
  • Expectation of Success: Petitioner argued that implementing functional security modules using well-documented kernel-level techniques like device drivers (taught by Schmid) and system call modification (taught by Dan) was a predictable and well-understood task for a POSITA at the time.

4. Key Claim Construction Positions

• “if the new program is validated...”: Petitioner argued this phrase should be construed to mean that if a program is validated, it is not monitored as it loads and executes. This construction was based on the patent's stated goal of creating an efficient system that minimizes interruptions and was used to map Lambert's teaching of "unrestricted" (i.e., unmonitored) execution for "good code" to the claim limitations.
• “an execution module”: Petitioner asserted this is a means-plus-function term under §112(6), with the recited function of "monitoring... the program in response to the trigger." The corresponding structure proposed was a module that monitors the program only if it was not validated, linking this term's operation directly to the outcome of the pre-execution validation step.

5. Arguments Regarding Discretionary Denial

• Petitioner argued against discretionary denial under §314(a), contending that no operative trial date was set in the parallel district court litigation due to its consolidation in a Multidistrict Litigation (MDL) proceeding, making the trial timeline highly uncertain. Petitioner also stipulated that, if the IPR is instituted, it will not pursue any invalidity ground in the district court that utilizes the same prior art references relied upon in the petition, thereby mitigating concerns of duplicative efforts and conserving judicial resources.

6. Relief Requested

• Petitioner requests institution of an inter partes review and cancellation of claims 1, 2, 6, 8, 9, 12, and 25 of the ’137 patent as unpatentable.