PTAB

IPR2017-02155

Cisco Systems Inc v. Finjan Inc

Log In
Key Events
Petition
petition

1. Case Identification

2. Patent Overview

  • Title: Malicious Mobile Code Runtime Monitoring System and Methods
  • Brief Description: The ’494 patent relates to systems for protecting computers from malicious or suspicious software, referred to as "Downloadables." The system involves receiving a Downloadable, deriving a "Downloadable security profile" that identifies potentially harmful operations, and storing this profile in a database for later use.

3. Grounds for Unpatentability

Ground 1: Claims 10, 11, 14, 15, and 16 are obvious over [Shear](https://ai-lab.exparte.com/case/ptab/IPR2017-02158/doc/1004) in view of [Kerchen](https://ai-lab.exparte.com/case/ptab/IPR2017-02158/doc/1019).

  • Prior Art Relied Upon: Shear (Patent 6,157,721) and Kerchen (Static Analysis Virus Detection Tools for Unix Systems, a 1990 conference proceeding).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Shear taught the core system of claim 10: a verifying authority (a "receiver") receives a "load module" (a "Downloadable"), analyzes it using computer-based testing techniques to generate a "specification" (a "security profile"), and provides it to an end-user. The specification describes the executable's operations and functions. Shear further disclosed storing this specification in a structured data file, which Petitioner contended is equivalent to a database, and using a commercially available database manager. To the extent Shear was not explicit about the scanning process or the "list of suspicious computer operations," Kerchen supplied the missing detail. Kerchen described specific "static analysis" tools for identifying suspicious code in a program, such as a "detector tool" that flags duplicate operating system calls (e.g., "read," "write") as suspicious. The combination of Shear's framework with Kerchen's specific analysis tools allegedly rendered claim 10 obvious. The dependent claims were also obvious, as adding a date/time stamp (claim 11), identifying the source URL (claim 16), recognizing common malware operations like calls to a file or network system (claim 15), and applying the method to program scripts (claim 14) were all well-known, conventional features in the art.
    • Motivation to Combine: A Person of Ordinary Skill in the Art (POSA) would combine Shear and Kerchen because they addressed the same problem of protecting against malicious downloaded code. Shear expressly taught using "conventional" and "computer-based software testing techniques" to analyze executables but did not detail them. Kerchen provided specific, well-known examples of such conventional techniques. A POSA would have been motivated to implement Shear’s general system using the specific, practical tools described by Kerchen to create a comprehensive security solution.
    • Expectation of Success: A POSA would have had a high expectation of success because the combination involved applying Kerchen's well-understood static analysis tools to implement the security framework proposed by Shear. Both references used established computer security principles to achieve the common goal of protecting a computer network.

Ground 2: Claims 10, 11, 14, 15, and 16 are obvious over [Crawford '91](https://ai-lab.exparte.com/case/ptab/IPR2017-02158/doc/1011) in view of Knowledge of a POSA.

  • Prior Art Relied Upon: Crawford ’91 (A Testbed for Malicious Code Detection: A Synthesis of Static and Dynamic Analysis Techniques, a 1991 conference proceeding).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner asserted that Crawford ’91 disclosed a "Malicious Code Testbed" (MCT), a computer-based system for managing Downloadables. The MCT received an executable program ("incoming Downloadable") and used static and dynamic analysis techniques (a "scanner") to identify "suspicious code" and summarize its properties, thereby deriving "security profile data." Crawford '91 explicitly mentioned using scanners to search for malicious bitstring patterns and storing analysis results—including memory addresses and operations like READ/WRITE—in an "elaborate data structure" or "table," which a POSA would understand to be a database. This system was intended to assist a user in determining if code was malicious. Petitioner argued that this single reference taught every element of independent claim 10. The teachings of Crawford '91 also rendered the dependent claims obvious, as it described analyzing Lisp-like language (a "program script" per claim 14), identified READ/WRITE operations to memory (suspicious operations per claim 15), and discussed the importance of identifying trusted sources, which would motivate a POSA to include a source URL (claim 16). Adding a date/time stamp (claim 11) was argued to be a common and obvious practice for data management.
    • Motivation to Combine (with POSA knowledge): The motivation was to implement the system fully described in Crawford '91. To the extent any minor element, such as a "database manager," was not explicitly named, a POSA would have been motivated by routine knowledge and common sense to use one for managing the storage and retrieval of data in the "table" or "elaborate data structure" described. No combination of references was necessary; only the application of ordinary skill to the teachings of Crawford '91 was required.
    • Expectation of Success: A POSA would have expected success in implementing the MCT system as described in Crawford '91. The methods discussed, such as static analysis and storing data in structured tables, were routine and predictable in their application.

4. Key Claim Construction Positions

  • "a list of suspicious computer operations" (Claim 10): Petitioner argued this term should be given its plain and ordinary meaning and not be narrowly construed to only list suspicious operations. Petitioner contended that the transitional phrase "comprising" means the list is inclusive, not exclusive, and could contain other information. This construction was central to preventing the Patent Owner from arguing that prior art showing a profile with both suspicious and non-suspicious operations failed to meet the limitation.

5. Key Technical Contentions (Beyond Claim Construction)

  • "Security Profile" as a "Specification": A central contention was that the ’494 patent’s "Downloadable security profile" was not a novel concept. Petitioner argued it was simply a new name for what the prior art already referred to as a "specification"—a file describing a program's content, functions, and operations.
  • "Conventional" Analysis Techniques: Petitioner asserted that the ’494 patent and its priority applications admit that the methods for deriving the security profile data rely on "conventional parsing techniques" and "conventional" software testing. This admission was used to justify combining primary references like Shear, which describe a general framework, with secondary references like Kerchen, which detail those very conventional techniques.

6. Relief Requested

  • Petitioner requested institution of an inter partes review and cancellation of claims 10, 11, 14, 15, and 16 of the ’494 patent as unpatentable.