`By:
`Joseph J. Richetti
`Kevin E. Paganini
`Bryan Cave LLP
`1290 Avenue of the Americas
`New York, NY 10104
`Tel: (212) 541-2000
`Fax: (212) 541-4630
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`PROOFPOINT, INC. AND
`ARMORIZE TECHNOLOGIES, INC.
`Petitioner
`
`v.
`
`FINJAN, INC.
`Patent Owner
`
`IPR2016-00967
`U.S. Patent No. 8,225,408
`
`PETITION FOR INTER PARTES REVIEW
`PURSUANT TO 37 C.F.R. §42.100 et seq.
`
`
`
`Petition for Inter Partes Review of Patent No. 8.225,408
`
`Table of Contents
`INTRODUCTION ...........................................................................................1
`I.
`II. MANDATORY NOTICES - 37 C.F.R. § 42.8(A)(1).....................................1
`A.
`Real Party-ln-Interest - 37 C.F.R. § 42.8(b)(1 ......................................1
`B.
`Related Matters - 37 C.F.R. § 42.8(b)(2) ..............................................2
`C.
`Lead and Back-Up Counsel - 37 C.F.R. § 42.8(b)(3) ...........................2
`D.
`Service Information - 37 C.F.R. § 42.8(b)(4) .......................................2
`E.
`Power of Attorney .................................................................................3
`PAYMENT OF FEES - 37 C.F.R. § 42.103 ...................................................3
`III.
`IV. REQUIREMENTS FOR INTER PARTES REVIEW UNDER 37 C.F.R. §§
`42.104 AND 42.108.........................................................................................3
`A.
`Grounds for Standing Under 37 C.F.R. § 42.104(a).............................3
`B.
`Identification of Challenge Under 37 C.F.R. § 42.104(b) and
`Statement of Precise Relief Requested .................................................3
`Threshold Requirement for Inter Partes Review Under 37 C.F.R. §
`42.108(c)................................................................................................4
`BACKGROUND OF TECHNOLOGY RELATED TO THE ‘408 PATENT
`.........................................................................................................................4
`A. Malware Detection ................................................................................4
`B.
`Static Analysis Using Parse Trees.........................................................5
`C. Malware & Vulnerability Detection......................................................8
`SUMMARY OF THE ‘408 PATENT.............................................................8
`A.
`Brief Description of the ‘408 Patent .....................................................8
`B.
`Petitioned Claims of the ‘408 Patent.....................................................8
`C.
`Priority Date of the ‘408 Patent.............................................................9
`VII. CLAIM CONSTRUCTION UNDER 37 C.F.R. § 42.104(B)(3)..................10
`A.
`“Parse tree” (all claims).......................................................................11
`B.
`“Dynamically building . . . while said receiving receives the incoming
`stream” (variants in all claims)............................................................11
`“Dynamically detecting . . . while said dynamically building builds
`the parse tree” (variants in all claims).................................................12
`
`VI.
`
`C.
`
`V.
`
`C.
`
`i
`
`
`
`Petition for Inter Partes Review of Patent No. 8.225,408
`
`D.
`
`X.
`
`“Instantiating . . . a scanner for the specific programming language”
`(claims 1 and 22) .................................................................................13
`VIII. PERSON HAVING ORDINARY SKILL IN THE ART & STATE OF THE
`ART ...............................................................................................................14
`IX. CLAIMS 1, 9, 22, 23, 29, AND 35 OF THE ‘408 PATENT ARE
`UNPATENTABLE........................................................................................14
`A.
`Overview of Chandnani ......................................................................15
`B.
`Overview of Kolawa ...........................................................................16
`C.
`Overview of Walls...............................................................................16
`D.
`Chandnani, Kolawa, and Walls Are All Analogous Art.....................17
`E.
`General Motivations to Combine the Prior Art Teachings .................18
`CHANDNANI IN VIEW OF KOLAWA RENDERS THE PETITIONED
`CLAIMS INVALID AS OBVIOUS UNDER 35 U.S.C. § 103 (GROUND 1)
`.......................................................................................................................19
`A.
`Claim 1 ................................................................................................20
`1.
`Claim 1 – preamble...................................................................20
`2.
`Claim element 1[a] – receiving a stream of code .....................20
`3.
`Claim element 1[b] – determining a programming language...20
`4.
`Claim element 1[c] – instantiating a scanner............................21
`5.
`Claim element 1[d] – scanner with language-specific rules.....21
`a.
`Claim element 1[e] - parser rules ...................................22
`b.
`Claim element 1[f] - analyzer rules................................23
`Claim element 1[g] – identifying tokens ..................................24
`Claim element 1[h] – dynamically building a parse tree..........25
`a.
`Building a parse tree.......................................................25
`b.
`Dynamically building .....................................................29
`Claim element 1[i] – dynamically detecting exploits...............31
`a.
`Detecting potential exploits............................................31
`b.
`Dynamically detecting....................................................33
`Claim element 1[j] – indicating presence of exploits ...............34
`9.
`Claim 9 ................................................................................................34
`1.
`Claim 9 – preamble...................................................................35
`
`6.
`7.
`
`8.
`
`B.
`
`ii
`
`
`
`Petition for Inter Partes Review of Patent No. 8.225,408
`
`Claim element 9[a] – computer-readable storage medium.......36
`2.
`Claim element 9[b] – receiver...................................................36
`3.
`Claim element 9[c] – multi-lingual language detector .............37
`4.
`Claim element 9[d] – scanner instantiator................................37
`5.
`Claim element 9[e] – rules accessor .........................................38
`6.
`Claim elements 9[f]-[g] – parser and analyzer rules ................39
`7.
`Claim element 9[h] – tokenizer.................................................39
`8.
`Claim element 9[i] – parser.......................................................40
`9.
`10. Claim element 9[j] – analyzer...................................................40
`11. Claim element 9[k] – notifier....................................................41
`Claim 22 ..............................................................................................42
`1.
`Claim 22 – preamble.................................................................43
`2.
`Claim elements 22[a]-[e] and [g]-[j].........................................44
`3.
`Claim element 22[f] – analyzer rules........................................44
`Claim 23 ..............................................................................................44
`1.
`Claim elements 23[b], [c], [f], and [i].......................................45
`2.
`Claim element 23[a] – exploits as patterns of tokens & rules..45
`3.
`Claim element 23[d] – rules used to express exploits ..............46
`4.
`Claim element 23[g] – dynamically building a parse tree........47
`5.
`Claim element 23[h] – dynamically detecting exploits ............48
`Claim 29 ..............................................................................................48
`1.
`Claim 29 – limitations 29[a], [f], and [g]..................................50
`2.
`Claim elements 29[c]-[e] – exploits, tokens, and rules ............50
`3.
`Claim element 29[b] – accessor................................................51
`4.
`Claim element 29[h] – parser....................................................51
`5.
`Claim element 29[i] – analyzer.................................................52
`6.
`Claim element 29[k] – notifier..................................................53
`Claim 35 ..............................................................................................54
`1.
`Claim 35 – preamble.................................................................55
`2.
`Claim elements 35[b]-[f] and [h]-[i].........................................55
`
`C.
`
`D.
`
`E.
`
`F.
`
`iii
`
`
`
`Petition for Inter Partes Review of Patent No. 8.225,408
`
`Claim element 35[a] – expressing exploits...............................55
`3.
`Claim element 35[g] – dynamically building ...........................56
`4.
`XI. CHANDNANI IN VIEW OF KOLAWA AND WALLS RENDERS THE
`PETITIONED CLAIMS INVALID AS OBVIOUS UNDER 35 U.S.C. §
`103 (GROUND 2)..........................................................................................56
`A.
`Dynamically building a parse tree.......................................................56
`B.
`Dynamically detecting potential exploits............................................59
`XII. NO SECONDARY CONSIDERATIONS OF NON-OBVIOUSNESS
`EXIST ............................................................................................................60
`
`iv
`
`
`
`Petition for Inter Partes Review of Patent No. 8.225,408
`
`Exhibit
`No.
`1001
`1002
`1003
`1004
`1005
`1006
`1007
`
`1008
`1009
`1010
`
`1011
`1012
`1013
`
`1014
`1015
`1016
`
`1017
`1018
`
`List of Exhibits
`
`Description of Document
`
`U.S. Patent No. 8,225,408 (“the ‘408 patent”)
`Declaration of Dr. Aviel D. Rubin
`U.S. Patent No. 7,636,945 (“Chandnani”)
`U.S. Patent No. 5,860,011 (“Kolawa”)
`U.S. Patent No. 7,284,274 (“Walls”)
`U.S. Patent No. 7,437,362 (“Ben-Natan” or the “Ben-Natan Patent”)
`Ron Ben-Natan, “Protecting Your Payload,” SQL Server Magazine, Vol.
`5, No. 8 (August 2003) (the “Ben-Natan Article”)
`U.S. Patent No. 6,697,950 (“Ko”)
`U.S. Patent No. 7,210,041 (“Gryaznov”)
`Mihai Christodorescu & Somesh Jha, “Static Analysis of Executables to
`Detect Malicious Patterns,” Proc. of the 12th USENIX Security Sympo-
`sium (Aug. 7, 2003) (“Christodorescu”)
`U.S. Patent No. 7,185,003 (“Bayliss”)
`U.S. Patent No. 7,546,234 (“Deb”)
`David Wagner and Drew Dean, “Intrusion Detection via Static Analy-
`sis,” In Proc. IEEE Symposium on Security and Privacy (2001) (“Wag-
`ner”)
`Microsoft Press, Computer Dictionary, 3rd ed. (1997)
`U.S. Patent No. 7,950,059 (“Aharon”)
`Yichen Xie, et al., “ARCHER: Using Symbolic, Path-Sensitive Analysis
`to Detect Memory Access Errors,” Proc. of the 10th ACM SIGSOFT In-
`ternational Symposium on Foundations of Software Engineering (Sept.
`2003) (“ARCHER”)
`U.S. Patent No. 7,207,065 (“Chess”)
`James F. Power and Brian A. Malloy, “Program Annotation in XML: A
`Parse Tree-Based Approach,” 9th IEEE Working Conference on Reverse
`Engineering (Nov. 1, 2002) (“Power”)
`
`v
`
`
`
`Petition for Inter Partes Review of Patent No. 8.225,408
`
`Exhibit
`No.
`1019
`1020
`
`1021
`1022
`1023
`
`1024
`1025
`1026
`
`1027
`
`1028
`1029
`1030
`
`1031
`1032
`
`1033
`
`1034
`
`1035
`1036
`1037
`1038
`
`Description of Document
`
`U.S. Patent No. 6,061,513 (“Scandura”)
`Stephen C. Johnson, “YACC: Yet Another Compiler Computer,” Bell
`Laboratories, Murray Hill, NJ (1978) (“YACC”)
`File History of U.S. Patent No. 8,225,408 (“408 File History”)
`Curriculum Vitae of Dr. Aviel Rubin
`F-SCRIPT, F-Secure Script Viruses Detector and Eliminator, Version
`1.6, Data Fellows Corp. (1998-99)
`U.S. Patent Application Publication No. 2004/0181677 (“Hong”)
`Webster’s New World Computer Dictionary, 9th ed. (2001)
`David M. Chess and Steve R. White, “An Undetectable Computer Virus”
`(“Chess and White”)
`Symantec.com, “Updating virus definitions on a daily basis with Syman-
`tec AntiVirus”
`Wikipedia.org, “Lexical Analysis”
`Computer Desktop Encyclopedia, 2nd ed. (1999)
`David Patterson and John Hennessy, “Computer Organization & Design,
`The Hardware / Software Interface” (1994)
`U.S. Patent No. 5,996,059 (“Porten”)
`John Lockwood, “Internet Worm and Virus Protection for Very High-
`Speed Networks” (August 1998)
`Sebastian Gerlach and Roger D. Hersch, “DPS – Dynamic Parallel
`Schedules,” IEEE Press (2003)
`B. Ramakrishna Rau and Joseph A. Fisher, “Instruction-Level Parallel
`Processing: History, Overview, and Perspective,” The Journal of Super-
`computing (1993)
`U.S. Patent Application No. 08/964,388
`U.S. Patent Application No. 09/539,667
`Webster’s New World Dictionary of Computer Terms, 5th ed. (1994)
`J. Mark Smith, et al., “Protecting a Private Network: The AltaVista
`
`vi
`
`
`
`Petition for Inter Partes Review of Patent No. 8.225,408
`
`Exhibit
`No.
`
`Description of Document
`
`1039
`
`1040
`1041
`
`1042
`
`1043
`1044
`1045
`
`1046
`
`1047
`1048
`
`1049
`
`1050
`1051
`1052
`1053
`1054
`
`Firewall,” Digital Technical Journal (1997)
`Martin Hitz and Behzad Montazeri, “Measuring Coupling and Cohesion
`in Object-Oriented Systems” (“Hitz”)
`Dictionary.com, “vis-à-vis”
`Testimony of Stephen R. Malphrus, “The ‘I Love You’ computer virus
`and the financial services industry,” Before the Subcommittee on Finan-
`cial Institutions of the Committee on Banking, Housing, and Urban Af-
`fairs, U.S. Senate, May 18, 2000
`Jack D. Shorter, et al., “Aspects of Information Security: Penetration
`Testing Is Crucial for Maintaining System Security Viability,” Journal of
`Information Systems Technology and Planning, Volume 5, Issue 12
`(Spring 2012)
`ccm.net, “The Klez Virus” (September 2015)
`Jakob Nielsen, “100 Million Websites”
`Margrethe H. Olson, “Remote Office Work: Changing Work Patterns In
`Space and Time” (March 1983)
`“Intrusion Detection Systems,” Group Test (Edition 2), An NSS Group
`Report (December 2001)
`Carey Nachenberg, “The Evolving Virus Threat” (“Nachenberg”)
`Dmitry O. Gryaznov, “Scanners of the Year 2000: Heuristics,” Virus
`Bulletin (1995)
`Emin Gun Sirer, et al., “Design and Implementation of a Distributed Vir-
`tual Machine for Networked Computers,” 33 ACM SIGOPS Operating
`Systems Review 202 (Dec. 5, 1999) (“Sirer”)
`Frederick B. Cohen, “A Short Course on Computer Viruses” (1990)
`United States Patent No. 5,842,002 (“Schnurer”)
`Hal Berghel, “The Client Side of the Web” (April 8, 1996)
`w3schools.com, “My First JavaScript Tutorial”
`Sarah Gordon and David Chess, “Attitude Adjustment: Trojans and
`Malware on the Internet”
`
`vii
`
`
`
`Petition for Inter Partes Review of Patent No. 8.225,408
`
`Exhibit
`No.
`1055
`
`1056
`1057
`
`1058
`1059
`
`1060
`1061
`
`Description of Document
`
`Stephane Bressan and Thomas Lee, “Information Brokering on the
`World Wide Web” (June 1997)
`David M. Chess, “Security Issues in Mobile Code Systems”
`Andrew W. Appel and Jens Palsberg, “Modern Compiler Implementation
`in Java,” 2nd ed. (2002)
`Graham Hutton, “Higher-Order Functions for Parsing” (July 1992)
`John Lockwood, et al., “An Extensible, System-On-Programmable-Chip,
`Content-Aware Internet Firewall”
`“M86 Security Acquires Finjan,” Reuters Business Wire (Nov. 3, 2009)
`Final Office Action, Ex Parte Reexamination of U.S. Patent No.
`7,647,633 (May 22, 2015)
`
`viii
`
`
`
`Petition for Inter Partes Review of Patent No. 8,225,408
`
`I.
`
`INTRODUCTION
`
`Proofpoint, Inc. and Armorize Technologies, Inc. (“Petitioner”) petitions for
`
`inter partes review (“IPR”) under 35 U.S.C. §§ 311-319 and 37 C.F.R. § 42 of
`
`claims 1, 9, 22, 23, 29, and 35 (the “Petitioned Claims”) of U.S. Patent No.
`
`8,225,408 (“the ‘408 patent”) (Ex. 1001), assigned on its face to Finjan, Inc. based
`
`on the substantively identical grounds as instituted for the pending IPR2015-02001
`
`proceeding. For the exact same reasons previously considered by the Patent Trial
`
`and Appeal Board (“the Board”), Petitioner respectfully seeks to join IPR2015-
`
`02001. This Petition asserts substantively identical arguments in connection with
`
`the grounds already instituted in IPR2015-02001; it does not add to or alter any ar-
`
`gument that has already been considered by the Board, and this Petition does not
`
`seek to expand the grounds of unpatentability that the Board has already instituted.
`
`As explained below, there exists a reasonable likelihood that Petitioner will prevail
`
`in demonstrating unpatentability of at least one challenged claim. Because this Pe-
`
`tition is filed along with a Motion for Joinder within one month of the institution of
`
`IPR2015-02001, it is timely and proper under 35 U.S.C. § 315(c) and 37 C.F.R.
`
`§42.122(b).
`
`II. MANDATORY NOTICES - 37 C.F.R. § 42.8(a)(1)
`
`A.
`
`Real Party-ln-Interest - 37 C.F.R. § 42.8(b)(1
`
`Petitioner certifies that Proofpoint, Inc. and Armorize Technologies, Inc. are the
`
`real parties-in-interest.
`
`1
`
`
`
`Petition for Inter Partes Review of Patent No. 8,225,408
`
`B.
`
`Related Matters - 37 C.F.R. § 42.8(b)(2)
`
`Finjan, Inc. (“Patent Owner” or “Finjan”) has asserted the ‘408 patent in
`
`Finjan, Inc. v. Proofpoint, Inc., No. 3-13-cv-05808 (N.D. Cal.); Finjan, Inc. v. Pa-
`
`lo Alto Networks, Inc., No. 3-14-cv-04908 (N.D. Cal.); Finjan, Inc. v. FireEye,
`
`Inc., No. 4-13-cv-03113 (N.D. Cal.); and Finjan, Inc. v. Blue Coat Systems, Inc.,
`
`No. 5-15-cv-03295 (N.D. Cal.). The ‘408 patent is subject to IPR in IPR2015-
`
`02001 and IPR2016-00157 both of which were instituted and IPR2016-00955 and
`
`IPR2016-00956 both of which remain pending.
`
`C.
`
`Lead and Back-Up Counsel - 37 C.F.R. § 42.8(b)(3)
`
`Petitioner appoints Joseph J. Richetti (Reg. No. 47,024) of Bryan Cave LLP
`
`as lead counsel and Kevin Paganini (Reg. No. 66,286) of Bryan Cave LLP as back-
`
`up counsel.
`
`D.
`
`Service Information - 37 C.F.R. § 42.8(b)(4)
`
`Service of any documents to lead and back-up counsel can be made via
`
`hand-delivery to Bryan Cave LLP, 1290 Avenue of the Americas, New York, NY
`
`10104. Petitioner consents to service by email at joe.richetti@bryancave.com,
`
`kevin.paganini@bryancave.com, IPR2016-00967@bryancave.com and PTAB-
`
`NY@bryancave.com.
`
`The Petition and Exhibits are being served by Federal Express overnight de-
`
`livery to the ‘408 Patent Owner’s attorneys of record, Dawn-Marie Bey, Bey &
`
`Cotropia PLLC. The petition and exhibits are also being served by Federal Ex-
`
`2
`
`
`
`Petition for Inter Partes Review of Patent No. 8,225,408
`
`press overnight delivery to counsel of record in IPR2015-02001 and IPR2016-
`
`00157.
`
`E.
`
`Power of Attorney
`
`Filed concurrently with this petition per 37 C.F.R. § 42.10(b).
`
`III. PAYMENT OF FEES - 37 C.F.R. § 42.103
`
`This Petition requests review of claims 1, 9, 22, 23, 29, and 35 of the ‘408
`
`patent and is accompanied by a payment of $23,000. 37 C.F.R. § 42.15. No excess
`
`claims fees are required. This Petition meets the fee requirements of 35 U.S.C.
`
`§ 312(a)(1).
`
`IV. REQUIREMENTS FOR INTER PARTES REVIEW UNDER 37 C.F.R. §§ 42.104
`AND 42.108
`
`A.
`
`Grounds for Standing Under 37 C.F.R. § 42.104(a)
`
`Petitioner certifies that the ‘408 Patent is available for IPR and that Petition-
`
`er is not barred or estopped from challenging the patent claims on the grounds in
`
`this Petition because this Petition is filed within one month of institution of
`
`IPR2015-02001 along with a Motion for Joinder. 35 U.S.C. § 315(c); 37 C.F.R.
`
`§42.122(b).
`
`B.
`
`Identification of Challenge Under 37 C.F.R. § 42.104(b) and
`Statement of Precise Relief Requested
`
`Petitioner requests IPR of claims 1, 9, 22, 23, 29, and 35 of the ‘408 patent
`
`and requests that the Board find each claim unpatentable based on the substantive-
`
`ly identical grounds as instituted for the pending IPR2015-02001 proceeding. An
`
`3
`
`
`
`Petition for Inter Partes Review of Patent No. 8,225,408
`
`explanation of why each claim is unpatentable under the grounds identified in Ta-
`
`ble 1 below is provided in Section X. Additional explanation and support for each
`
`ground of unpatentability is set forth in the Declaration of Dr. Aviel Rubin (Ex.
`
`1002), an expert in the field.
`
`Table 1 – Asserted Grounds of Unpatentability
`
`Ground
`1
`
`‘408 Patent Claims
`1, 9, 22, 23, 29, 35
`
`2
`
`1, 9, 22, 23, 29, 35
`
`Basis for Challenge
`Obvious under § 103(a) by Chandnani in view
`of Kolawa
`Obvious under § 103(a) by Chandnani in view
`of Kolawa and Walls
`
`C.
`
`Threshold Requirement for Inter Partes Review Under 37 C.F.R.
`§ 42.108(c)
`Inter partes review of claims 1, 9, 22, 23, 29, and 35 should be instituted be-
`
`cause this Petition establishes a reasonable likelihood that Petitioner will prevail
`
`with respect to each of the challenged claims. 35 U.S.C. § 314(a).
`
`V.
`
`BACKGROUND OF TECHNOLOGY RELATED TO THE ‘408 PATENT
`
`Computer viruses have long been a major security problem. For example, vi-
`
`ruses can damage a computer, perform unauthorized operations, or otherwise in-
`
`convenience a user. (Ex. 1002 at ¶ 42.) Those in the art often refer to harmful or
`
`unauthorized programs as “malicious software” or “malware.” (Id. at ¶ 43.)
`
`A. Malware Detection
`
`Since at least 1988, antivirus software has served as a barrier between mal-
`
`ware and the processor. (Ex. 1002 at ¶ 56.) The concept is to have a trusted pro-
`
`4
`
`
`
`Petition for Inter Partes Review of Patent No. 8,225,408
`
`gram evaluate untrusted programs before they execute. (Id.)
`
`Security applications identify “exploits” (such as viruses) by scanning for a
`
`signature, i.e., a particular pattern of characters or instructions found in each in-
`
`stance of a known virus. (Ex. 1002 at ¶¶ 58-59; Ex. 1003 at 2:17-22.) Signature
`
`scanning requires a database of known patterns found in (and preferably only in)
`
`malware. (Id. at ¶ 59.) If the scanned program has the same sequence of bytes as a
`
`known malicious program, the scanner will not allow the program to run. (Id.) The
`
`problem with signature scanning is that it only recognizes malware after the mal-
`
`ware has been identified and its signature placed in a database, and is therefore un-
`
`able to protect against previously-unseen harmful programs. (Id. at ¶ 60.)
`
`B.
`
`Static Analysis Using Parse Trees
`
`A polymorphic virus is a virus that can copy itself slightly differently as it
`
`spreads in order to change its signature and evade detection by signature scanners.
`
`(Ex. 1002 at ¶ 61; Ex. 1003 at 2:54-61.) Small changes, like the addition of extra-
`
`neous program code, comments, or other changes, can create a new signature that
`
`is different from earlier versions of the same virus. (Id.)
`
`In 2004, one approach to detecting polymorphic viruses was known as “stat-
`
`ic analysis.” (See, e.g., Ex. 1008, Ko; Ex. 1010, Christodorescu; Ex. 1002 at ¶ 63.)
`
`Rather than looking for a specific pattern of bytes, static analysis involves a deeper
`
`“parsing” analysis of computer code to determine how the code is structured and
`
`5
`
`
`
`Petition for Inter Partes Review of Patent No. 8,225,408
`
`expected to function. (Ex. 1002 at ¶ 63.) Static analysis is particularly useful for
`
`detecting viruses in scripts because such viruses propagate in source code form,
`
`and source code can be parsed to ascertain the functions it will perform. (Id.; Ex.
`
`1008, Ko at Abstract.)
`
`One common static analysis method in 2004 was to create a representation
`
`of computer code in a “parse tree” data structure—the same technique disclosed in
`
`the ‘408 patent. (See, e.g., Ex. 1009, Gryaznov at 5:3-5 (“[P]arser 20 processes the
`
`suspect string 26 and suspect [file] 27 on a line-by-line basis and generates a hier-
`
`archical parse tree, as is known in the art.”); Ex. 1007, Ben-Natan Article at 5
`
`(“[T]he firewall compares this parse tree with the rules you’ve devised.”); Ex.
`
`1004, Kolawa at 5:62-64 (“The quality of the source code 10 is checked on an in-
`
`dividual parse tree basis.”); Ex. 1002 at ¶¶ 65-70.)
`
`A parse tree is a representation of suspect code at a higher level of abstrac-
`
`tion than the code itself. (Ex. 1002 at ¶ 66.) Parse trees preserve code’s structure
`
`and substantive patterns but remove details like spacing and capitalization. (Id.)
`
`Below are graphical representations of an example parse tree from a patent filed in
`
`2003:
`
`6
`
`
`
`Petition for Inter Partes Review of Patent No. 8,225,408
`
`(Ex. 1006, Ben-Natan at Fig. 14A; see also Ex. 1002 at ¶ 66.)
`
`Parse trees are built by first converting a sequence of characters, such as a
`
`stream of code, into a sequence of “tokens,” or strings of related characters. (Ex.
`
`1002 at ¶¶ 67-69.) Token creation is performed using a process called “lexical
`
`analysis.” (Id. at ¶ 69.) Then, a parsing process is used to convert tokens into nodes
`
`of a parse tree (such as “SELECT” or “WHERE” above) using “grammar” rules
`
`that describe the syntax of a particular computer programming language. (Id.)
`
`Parse trees can be used to abstract away extraneous details of the underlying
`
`code. (Ex. 1002 at ¶¶ 66, 70, 72; Ex. 1011, Bayliss at 13:32-50.) Parse trees are
`
`useful for detecting viral structures while ignoring details of the exact code used in
`
`the virus. (Ex. 1002 at ¶¶ 71-72; Ex. 1012, Deb at 2:14-17.) Parse tree detection
`
`methods are thus more robust than virus detection methods that compare a signa-
`
`ture to those of known viruses. (Ex. 1002 at ¶ 72.)
`
`Techniques for building parse trees were well known in 2004, when the ‘408
`
`patent was filed. (Id. at ¶ 68.) In fact, the Examiner of the application that issued as
`
`the ‘408 patent noted that parsing is a fundamental and generally applicable meth-
`
`7
`
`
`
`Petition for Inter Partes Review of Patent No. 8,225,408
`
`od for dividing a sequence of characters into individual elements. (Ex. 1021, ‘408
`
`File History at 34.)
`
`C. Malware & Vulnerability Detection
`
`By 2004, static analysis was commonly used in two closely related and over-
`
`lapping sub-disciplines: malware detection and vulnerability detection (code quali-
`
`ty analysis). (Ex. 1002 at ¶¶ 71-76.) The POSA recognized the extensive overlap
`
`between these two sub-disciplines because malware was often designed to exploit
`
`vulnerabilities in software. (Id.; see Ex. 1005, Walls at 1:48-65; Ex. 1013, Wagner
`
`at 1.) For that reason, the POSA stayed current with (and sometimes taught) ad-
`
`vancements in both disciplines. (Ex. 1002 at ¶ 76.)
`
`VI.
`
`SUMMARY OF THE ‘408 PATENT
`
`A.
`
`Brief Description of the ‘408 Patent
`
`The ‘408 patent is directed at protecting computers against potentially mali-
`
`cious programs using programming language-specific sets of rules and a “parse
`
`tree” data structure. (Ex. 1001 at Title, Abstract.) The ‘408 patent describes scan-
`
`ning an incoming stream of computer code by creating tokens, generating a parse
`
`tree using patterns in those tokens, and identifying patterns of tokens in the parse
`
`tree as potential exploits. (See id.) Patterns are identified using “parser rules” and
`
`“analyzer rules” specific to one of multiple programming languages.
`
`B.
`
`Petitioned Claims of the ‘408 Patent
`
`The six Petitioned Claims recite essentially the same elements in method
`
`8
`
`
`
`Petition for Inter Partes Review of Patent No. 8,225,408
`
`(claims 1 and 23), system (claims 9 and 29), and Beauregard (claims 22 and 39)
`
`form, respectively. The elements of representative claim 1 are shown below:
`
`1[a]
`1[b]
`
`1[c]
`
`1[d]
`
`1[e]
`
`1[f]
`
`Claim Limitation
`No.
`1[pre] A computer processor-based multi-lingual method for scanning incoming
`program code, comprising:
`receiving, by a computer, an incoming stream of program code;
`determining, by the computer, any specific one of a plurality of program-
`ming languages in which the incoming stream is written;
`instantiating, by the computer, a scanner for the specific programming lan-
`guage, in response to said determining,
`the scanner comprising parser rules and analyzer rules for the specific pro-
`gramming language,
`wherein the parser rules define certain patterns in terms of tokens, tokens
`being lexical constructs for the specific programming language, and
`wherein the analyzer rules identify certain combinations of tokens and pat-
`terns as being indicators of potential exploits, exploits being portions of
`program code that are malicious;
`identifying, by the computer, individual tokens within the incoming
`stream;
`dynamically building, by the computer while said receiving receives the
`incoming stream, a parse tree whose nodes represent tokens and patterns in
`accordance with the parser rules;
`dynamically detecting, by the computer while said dynamically building
`builds the parse tree, combinations of nodes in the parse tree which are in-
`dicators of potential exploits, based on the analyzer rules; and
`indicating, by the computer, the presence of potential exploits within the
`incoming stream, based on said dynamically detecting.
`
`1[g]
`
`1[h]
`
`1[i]
`
`1[j]
`
`C.
`
`Priority Date of the ‘408 Patent
`
`The ‘408 patent was filed on August 30, 2004, as a continuation-in-part of
`
`Application No. 09/539,667 (now U.S. Patent No. 6,804,780), filed on March 30,
`
`9
`
`
`
`Petition for Inter Partes Review of Patent No. 8,225,408
`
`2000, which is itself a continuation of Application No. 08/964,388 (now U.S. Pa-
`
`tent No. 6,092,194), filed on November 6, 1997. As explained below, although
`
`filed as a continuation-in-part, the ‘408 patent shares almost nothing with the earli-
`
`er-filed applications.
`
`The ‘667 and ‘388 applications describe a system that simply compares a
`
`downloadable application to a security policy and blocks the application if it vio-
`
`lates the policy. (See Exs. 1035, 1036.) Neither of those applications describes a
`
`scanner that parses a data stream into tokens and searches for patterns that repre-
`
`sent potential exploits. (See id.) Neither of those applications includes any of the
`
`figures that appear in the ‘408 patent. (See id.) In fact, neither of those applications
`
`even mentions the terms “token,” “parse tree,” “analyzer rule,” “parser rule,” or
`
`“exploit”—and each of these terms appears throughout all independent claims of
`
`the ‘408 patent. (See id.) In short, the ‘667 and ‘388 applications contain no disclo-
`
`sure supporting the Petitioned Claims, which are therefore entitled to a priority
`
`date no earlier than August 30, 2004, the ‘408 patent’s own filing date.
`
`As explained in Section IX below, the cited prior art references qualify as
`
`prior art under 35 U.S.C. § 102 (pre-AIA) because each reference was filed, pub-
`
`lished, and/or issued in the United States before August 30, 2004, the earliest pos-
`
`sible priority date of the claims of the ‘408 patent.
`
`VII. CLAIM CONSTRUCTION UNDER 37 C.F.R. § 42.104(B)(3)
`
`10
`
`
`
`Petition for Inter Partes Review of Patent No. 8,225,408
`
`A.
`
`“Parse tree” (all claims)
`
`The BRI of the term “parse tree” is “tree data structure that represents pro-
`
`gram code.” This BRI is consistent with the use of the term in the claims and speci-
`
`fication, which describes a parse tree as a “data structure” comprised of nodes that
`
`correspond to tokens identified in an incoming stream of program code. (Ex. 1001
`
`at 8:23-27 (“[P]arser 220 uses a parse tree data structure to represent scanned con-
`
`tent. A parse tree contains a node for each token identified while parsing, and uses
`
`parsing rules to identify groups of tokens as a single pattern.”), Fig. 2; Ex. 1002 at
`
`¶¶ 65-70.) The ‘408 patent describes tokens as “lexical constructs” that are identi-
`
`fied within “an incoming stream of program code.” (Ex. 1001 at claim 1.)
`
`B.
`
`“Dynamically building . . . while said receiving receives the incom-
`ing stream” (variants in all claims)
`The terms referenced immediately above1 all include the word “dynamical-
`
`ly.” The BRI of each of the “dynamically building” terms is “building during a
`
`time period that overlaps with the time period during which the incoming stream is
`
`being received.” Although the ‘408 patent does not define “dynamically,” the spec-
`
`1 The Petitioned Claims all include one of the following terms: “dynamically
`
`building, [] while said receiving receives the incoming stream” (claims 1, 22, 23,
`
`35); or “dynamically building[,] while said receiver is receiving the incoming
`
`stream” (claims 9, 29).
`
`11
`
`
`
`Petition for Inter Partes Review of Patent No. 8,225,408
`
`ification does describe receiving part of an incoming stream, building part of a
`
`parse tree, and then receiving more of the stream and building more of the parse
`
`tree. (See Ex. 1001 at Fig. 5 (showing that a token is added to the parse tree (step
`
`510) before the next token is retrieved (step 500)), 8:29-32 (“Preferably, the parse
`
`tree generated by parser 220 is dynamically built using a shift-and-reduce algo-
`
`rithm. Successive tokens provided to parser 220 by tokenizer 210 are positioned as
`
`siblings.”) (emphasis added).) Accordingly, the steps of “receiving” the incoming
`
`stream and “building” the parse tree are at least partially interleaved with one an-
`
`other. (See id.; Ex. 1002 at ¶¶ 162-65.)
`
`During prosecution, the Patentee confirmed that “dynamically building”
`
`means that the claimed invention “parses and analyzes incoming program scripts
`
`on-the-fly for detection of computer exploits, prior to the entire scripts being resi-
`
`dent on the computer.” (Ex. 1021 at 14 (emphases added); see