PTAB
IPR2017-01738
ESET LLC v. Finjan Inc
Key Events
Petition
Table of Contents
petition
1. Case Identification
- Case #: IPR2017-01738
- Patent #: 7,975,305
- Filed: July 4, 2017
- Petitioner(s): ESET, LLC and ESET spol s.r.o
- Patent Owner(s): FINJAN, Inc.
- Challenged Claims: 1-25
2. Patent Overview
- Title: Method and System for Adaptive Rule-Based Content Scanners for Desktop Computers
- Brief Description: The ’305 patent describes anti-virus software that analyzes downloaded executable program code using a rule-based lexical analysis. Instead of relying on traditional virus signatures, the system uses adaptable rule files corresponding to specific languages (e.g., HTML, JavaScript) to identify malicious exploits by analyzing grammar, punctuation, and patterns of code "tokens."
3. Grounds for Unpatentability
Ground 1: Claims 1-25 are anticipated by Chandnani under 35 U.S.C. §102.
- Prior Art Relied Upon: Chandnani (Patent 7,636,945).
- Core Argument for this Ground:
- Prior Art Mapping: Petitioner argued that Chandnani teaches every limitation of the challenged claims. Chandnani discloses a system for detecting polymorphic script viruses using "data driven lexical analysis." This system functions as the claimed "security system for scanning content," utilizing a "detection engine" that performs the role of the claimed "rule-based content scanner." Chandnani’s system is based on rules stored in databases, specifically a "Script Language Rule Base" (disclosing parser rules) and a "Code Detection Database" (disclosing analyzer rules), which correspond to the claimed database of parser and analyzer rules. Petitioner asserted that Chandnani’s disclosure of analyzing code "constructs"—such as identifiers, keywords, and delimiters—inherently teaches the claimed "patterns of types of tokens" including punctuation, identifier, and function types. Furthermore, Chandnani was argued to teach a network traffic probe by selectively diverting certain content for analysis and a "learning component" that fortifies the rule base, satisfying the "rule update manager" limitation.
Ground 2: Claims 1-25 are obvious over Freund in view of Chandnani under 35 U.S.C. §103.
- Prior Art Relied Upon: Freund (Patent 5,987,611) and Chandnani (Patent 7,636,945).
- Core Argument for this Ground:
- Prior Art Mapping: Petitioner contended that Freund discloses a comprehensive client-server security system that anticipates or renders obvious most claim limitations. Freund teaches a "client-based filter application" that scans incoming internet content by parsing it to detect malicious "syntax elements." This system uses a "rules database or knowledgebase" to check if components like embedded scripts are permissible, mapping to the claimed rule-based scanner and database. Freund’s "Client Monitor" selectively diverts incoming content to a "content driver" for parsing, functioning as the claimed network traffic probe. Freund also discloses a rule update manager that downloads revised rules from a supervisor module. Petitioner argued that to the extent Freund does not explicitly detail the specific token types recited in the claims (punctuation, identifier, function), Chandnani provides this missing element. Chandnani expressly teaches a lexical analysis system that tokenizes data streams and identifies constructs like identifiers, keywords (functions), and delimiters (punctuation).
- Motivation to Combine: A POSITA would combine Freund’s robust security framework with Chandnani’s advanced lexical analysis techniques to improve the detection of malicious exploits. The ’305 patent’s prosecution history shows that the claims were allowed over Freund based on the addition of the specific token types. Petitioner argued that since Chandnani explicitly teaches these very token types for the same purpose of detecting malicious code, it would have been a simple and obvious modification for a POSITA to incorporate Chandnani's token-based analysis into Freund's system to enhance its capabilities.
- Expectation of Success: A POSITA would have reasonably expected success in combining these references, as it involved applying a known and well-documented analysis technique (Chandnani's tokenization) to a compatible security architecture (Freund's filtering system), both operating in the same technical field to solve the same problem.
4. Key Claim Construction Positions
- "database": Petitioner noted agreement with the Patent Owner in co-pending litigation that this term means "a collection of interrelated data organized according to a database schema to serve one or more applications."
- "parser rules": Petitioner proposed this term means "rules that identify patterns of tokens," based on the specification's description of using parsing rules to "identify groups of tokens as a single pattern."
- "analyzer rules": Proposed construction was "rules that provide 'a generic syntax pattern of tokens that indicates a potential exploit.'" This was based on the specification and the claim language requiring these rules to describe exploits as patterns of tokens.
- "function type": Petitioner argued this term means an "identity token that represents a function name." It was contended that while the patent does not explicitly define a "function type" token, it discloses identity tokens for functions, and a POSITA would understand the term in this context.
5. Relief Requested
- Petitioner requested institution of an inter partes review and cancellation of claims 1-25 of the ’305 patent as unpatentable.
Analysis metadata