PTAB

IPR2015-01979

Palo Alto Networks, Inc. v. Finjan, Inc.

Log In

1. Case Identification

2. Patent Overview

  • Title: System and Method for Inspecting Dynamically Generated Executable Code
  • Brief Description: The ’154 patent relates to a computer security method for protecting a computer from dynamically generated malicious content. The core of the invention is a system that intercepts a call to an original software function, sends its input variables to a remote security computer for inspection at run-time, and only allows the original function to execute if the remote computer indicates the input is safe.

3. Grounds for Unpatentability

Ground 1: Claims 1-5 are obvious over Khazan in view of Sirer.

  • Prior Art Relied Upon: Khazan (Application # 2005/0108562) and Sirer (a 1999 article titled “Design and Implementation of a Distributed Virtual Machine for Networked Computers”).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Khazan taught most elements of the claims, including a security system that detects malicious code by instrumenting an application. This instrumentation replaces a call to an original function (the claimed "second function") with a call to a wrapper function (the claimed "first function"), which then performs security analysis on the function's inputs. However, Petitioner contended that Khazan primarily disclosed performing this analysis on the local client computer. Sirer was introduced to supply the missing element of performing this analysis remotely, as it explicitly taught factoring out security services like run-time verification from the client and distributing them onto "powerful network servers."
    • Motivation to Combine: A Person of Ordinary Skill in the Art (POSA) would combine Khazan and Sirer to gain the known benefits taught by Sirer for remote security analysis. These benefits included using a more powerful network processor, centralizing security policies for consistent application across many clients, and providing stronger security through the physical isolation of the analysis from the client machine being protected.
    • Expectation of Success: Petitioner asserted that a POSA would have a high expectation of success in making this combination. The proposed modification involved substituting one known mode of instrumentation (local) for another (remote) to achieve the predictable result of an instrumented application. This was argued to be a common and well-understood practice in the field due to the modular nature of software and standardized network protocols.

Ground 2: Claims 6-8, 10, and 11 are obvious over Khazan in view of Sirer and further in view of Ben-Natan.

  • Prior Art Relied Upon: Khazan (Application # 2005/0108562), Sirer (a 1999 article), and Ben-Natan (Patent 7,437,362).
  • Core Argument for this Ground:
    • Prior Art Mapping: This ground built on the combination of Khazan and Sirer to address claims requiring a "modified input variable." Petitioner argued that while Khazan and Sirer teach identifying a malicious input and deciding whether to block or allow the original function call, they do not explicitly teach modifying the input itself. Ben-Natan, which relates to nonintrusive database security, was introduced to teach this concept. Ben-Natan disclosed intercepting a database query (a function call), and if its parameters (input) violated a security policy, the system could modify the parameters (e.g., by narrowing a search query) to create a safe "result data access statement" that could then be executed. This, Petitioner argued, taught the claimed "modified input variable."
    • Motivation to Combine: A POSA would be motivated to incorporate Ben-Natan's input-modification technique into the remote security framework established by combining Khazan and Sirer. Modifying an unsafe input to render it safe was a known alternative to simply blocking execution. This combination would provide a more nuanced and flexible security response, allowing an application to proceed safely with a modified input rather than halting execution entirely, which was presented as a clear and predictable improvement.
    • Expectation of Success: Petitioner argued success would be expected because the combination involved implementing a known technique (modifying unsafe inputs) into an existing security framework to achieve its known, predictable benefit (allowing safe execution). This was presented as a combination of known elements for their known purposes to achieve a predictable result.

4. Key Claim Construction Positions

  • "first function": Petitioner proposed this term be construed as "substitute function" or "wrapper function." This construction was central to the invalidity arguments, as it allowed Petitioner to map the claims onto prior art that instruments original code by replacing calls to it with calls to a new wrapper/substitute function that performs security checks.
  • "second function": Correspondingly, Petitioner construed this term as "original function." This refers to the function that is being wrapped and is only invoked by the "first function" if the security check passes.
  • "transmitter" / "receiver": Petitioner proposed construing these terms based on standard dictionary definitions as "a circuit or electronic device designed to send/accept electrically encoded data." This allowed Petitioner to argue that conventional network hardware disclosed in the prior art, such as standard network interface cards, satisfies these functional claim limitations.

5. Relief Requested

  • Petitioner requested institution of an inter partes review and cancellation of claims 1-8, 10, and 11 of Patent 8,141,154 as unpatentable.