Paper No. ____
`Filed: April 27, 2016
`
`Filed on behalf of: Blue Coat Systems, Inc.
`By: Michael T. Rosato (mrosato@wsgr.com)
`
`Andrew S. Brown (asbrown@wsgr.com)
`
`WILSON SONSINI GOODRICH & ROSATI
`701 Fifth Avenue, Suite 5100
`Seattle, WA 98104-7036
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_____________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_____________________________
`
`
`
`BLUE COAT SYSTEMS, INC.,
`Petitioner,
`
`v.
`
`FINJAN, INC.,
`Patent Owner.
`
`_____________________________
`
`IPR2016-00955
`Patent No. 8,225,408
`
`_____________________________
`
`
`
`PETITION FOR INTER PARTES REVIEW
`OF U.S. PATENT NO. 8,225,408
`
`
`
`

`
`
`
`TABLE OF CONTENTS
`
`Page
`
`I.
`
`Introduction .................................................................................................. 1
`
`II. Mandatory Notices Under 37 C.F.R. § 42.8(A)(1) ........................................ 2
`
`A.
`
`Real Party-ln-Interest Under 37 C.F.R. § 42.8(b)(1) ........................... 2
`
`B.
`
`C.
`
`Related Matters Under 37 C.F.R. § 42.8(b)(2) .................................... 2
`
`Lead and Back-Up Counsel under 37 C.F.R. § 42.8(b)(3) ................... 2
`
`D.
`
`Service Information ............................................................................ 3
`
`E.
`
`Power of Attorney ............................................................................... 3
`
`III.
`
`[RESERVED] ............................................................................................... 3
`
`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.
`
`C.
`
`Identification of Challenge Under 37 C.F.R. § 42.104(b) and
`Statement of Precise Relief Requested ................................................ 4
`
`Threshold Requirement for Inter Partes Review Under 37
`C.F.R. § 42.108(c) .............................................................................. 4
`
`V.
`
`Background of Technology Related to the ’408 Patent ................................. 4
`
`A. Malware Detection .............................................................................. 5
`
`B.
`
`Static Analysis Using Parse Trees ....................................................... 5
`
`C. Malware & Vulnerability Detection .................................................... 8
`
`VI. Summary of the ’408 Patent .......................................................................... 8
`
`A.
`
`Brief Description of the ’408 Patent .................................................... 8
`
`B.
`
`Petitioned Claims of the ’408 Patent ................................................... 9
`
`-i-
`
`

`
`
`
`C.
`
`Priority Date of the ’408 Patent ......................................................... 10
`
`VII. Claim Construction Under 37 C.F.R. § 42.104(b)(3)................................... 11
`
`A.
`
`“Parse tree” (all claims) .................................................................... 11
`
`B.
`
`C.
`
`D.
`
`“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) ..................................... 13
`
`“Instantiating . . . a scanner for the specific programming
`language” (claims 1 and 22) .............................................................. 14
`
`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 ........... 15
`
`A. Overview of Chandnani .................................................................... 15
`
`B.
`
`C.
`
`Overview of Kolawa ......................................................................... 16
`
`Overview of Walls ............................................................................ 17
`
`D.
`
`Chandnani, Kolawa, and Walls Are All Analogous Art .................... 17
`
`E.
`
`General Motivations to Combine the Prior Art Teachings ................. 18
`
`X.
`
`Chandnani in View of Kolawa Renders the Petitioned Claims Invalid
`as Obvious Under 35 U.S.C. § 103 (Ground 1) ........................................... 19
`
`A.
`
`Claim 1 ............................................................................................. 19
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`Claim 1 – preamble ................................................................. 19
`
`Claim element 1[a] – receiving a stream of code ..................... 20
`
`Claim element 1[b] – determining a programming
`language ................................................................................. 20
`
`Claim element 1[c] – instantiating a scanner ........................... 21
`
`Claim element 1[d] – scanner with language-specific
`rules ........................................................................................ 21
`
`-ii-
`
`

`
`
`
`a.
`b.
`
`Claim element 1[e] - parser rules .................................. 22
`Claim element 1[f] - analyzer rules ............................... 23
`
`Claim element 1[g] – identifying tokens ................................. 24
`
`Claim element 1[h] – dynamically building a parse tree .......... 24
`a.
`Building a parse tree ..................................................... 24
`b.
`Dynamically building.................................................... 28
`
`Claim element 1[i] – dynamically detecting exploits ............... 30
`a.
`Detecting potential exploits........................................... 30
`b.
`Dynamically detecting .................................................. 31
`
`6.
`
`7.
`
`8.
`
`9.
`
`Claim element 1[j] – indicating presence of exploits ............... 32
`
`B.
`
`Claim 9 ............................................................................................. 32
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`6.
`
`7.
`
`8.
`
`9.
`
`Claim 9 – preamble ................................................................. 34
`
`Claim element 9[a] – computer-readable storage medium ....... 34
`
`Claim element 9[b] – receiver ................................................. 34
`
`Claim element 9[c] – multi-lingual language detector ............. 35
`
`Claim element 9[d] – scanner instantiator ............................... 36
`
`Claim element 9[e] – rules accessor ........................................ 36
`
`Claim elements 9[f]-[g] – parser and analyzer rules ................ 37
`
`Claim element 9[h] – tokenizer ............................................... 37
`
`Claim element 9[i] – parser ..................................................... 38
`
`10. Claim element 9[j] – analyzer ................................................. 39
`
`11. Claim element 9[k] – notifier .................................................. 39
`
`C.
`
`Claim 22 ........................................................................................... 40
`
`1.
`
`2.
`
`3.
`
`Claim 22 – preamble ............................................................... 41
`
`Claim elements 22[a]-[e] and [g]-[j] ....................................... 41
`
`Claim element 22[f] – analyzer rules ...................................... 42
`
`-iii-
`
`

`
`
`
`D.
`
`Claim 23 ........................................................................................... 42
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`Claim elements 23[b], [c], [f], and [i]...................................... 43
`
`Claim element 23[a] – exploits as patterns of tokens &
`rules ........................................................................................ 43
`
`Claim element 23[d] – rules used to express exploits .............. 44
`
`Claim element 23[g] – dynamically building a parse tree ........ 44
`
`Claim element 23[h] – dynamically detecting exploits ............ 45
`
`E.
`
`Claim 29 ........................................................................................... 46
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`6.
`
`Claim 29 – limitations 29[a], [f], and [g] ................................. 47
`
`Claim elements 29[c]-[e] – exploits, tokens, and rules ............ 48
`
`Claim element 29[b] – accessor .............................................. 48
`
`Claim element 29[h] – parser .................................................. 49
`
`Claim element 29[i] – analyzer ............................................... 49
`
`Claim element 29[k] – notifier ................................................ 50
`
`F.
`
`Claim 35 ........................................................................................... 51
`
`1.
`
`2.
`
`3.
`
`4.
`
`Claim 35 – preamble ............................................................... 52
`
`Claim elements 35[b]-[f] and [h]-[i] ........................................ 52
`
`Claim element 35[a] – expressing exploits .............................. 52
`
`Claim element 35[g] – dynamically building .......................... 53
`
`XI. Chandnani in View of Kolawa and Walls Renders the Petitioned
`Claims Invalid as Obvious Under 35 U.S.C. § 103 (Ground 2) ................... 53
`
`A. Dynamically building a parse tree ..................................................... 53
`
`B.
`
`Dynamically detecting potential exploits .......................................... 55
`
`XII. No Secondary Considerations of Non-Obviousness Exist ........................... 56
`
`-iv-
`
`

`
`XIII. Payment of Fees under 37 C.F.R. §§ 42.15(a) and 42.103........................... 58
`XIII. Payment of Fees under 37 C.F.R. §§ 42.15(a) and 42.103 ......................... ..58
`
`XIV. Appendix – List of Exhibits ........................................................................ 59
`XIV. Appendix — List of Exhibits ...................................................................... ..59
`
`
`
`
`
`
`
`-v-
`
`

`
`
`
`I.
`
`INTRODUCTION
`
`Pursuant to 35 U.S.C. §§ 311-319 and 37 C.F.R. § 42, Blue Coat Systems,
`
`Inc. (“Petitioner”) petitions for inter partes review (“IPR”) of claims 1, 9, 22, 23,
`
`29, and 35 (the “Petitioned Claims”) of U.S. Patent No. 8,225,408 (Ex. 1001),
`
`assigned on its face to Finjan, Inc. The ’408 patent is directed to protecting
`
`computers against potentially malicious programs using a programming language-
`
`specific set of rules and a “parse tree” data structure.
`
`When the ’408 patent was filed in 2004, there was already a crowded field of
`
`prior art security software that analyzed computer code for security problems such
`
`as viruses and other malicious code. After approximately four years of prosecution
`
`without a single allowed claim, the patentee was forced to amend each of the
`
`Petitioned Claims to add two elements: (1) multi-language scanning capability; and
`
`(2) the ability to “dynamically” analyze a parse tree as it was being built. But
`
`numerous prior art references that were not before the Examiner—including the
`
`three primary references discussed in this Petition—confirm that these features
`
`were both well-known and obvious for use in security scanners.
`
`The Chandnani patent, for example, teaches dynamically parsing a data
`
`stream to detect computer viruses in a multi-language environment. It was obvious
`
`to use a parse tree data structure with Chandnani for storing suspect programs, as
`
`in the ’408 patent. And it was obvious to combine Chandnani with other prior art,
`
`such as Kolawa, that expressly taught using a parse tree to represent and analyze
`
`programming code, because both Chandnani and Kolawa taught parsing code and
`
`then searching for patterns that identify problematic code. Chandnani in
`
`1
`
`

`
`
`
`combination with Kolawa and other prior art references described in this Petition
`
`therefore render the Petitioned Claims invalid as obvious.
`
`II. MANDATORY NOTICES UNDER 37 C.F.R. § 42.8(A)(1)
`
`A. Real Party-ln-Interest Under 37 C.F.R. § 42.8(b)(1)
`
`Blue Coat Systems, Inc. is the real party-in-interest.
`
`B. Related Matters Under 37 C.F.R. § 42.8(b)(2)
`
`Finjan, Inc. (“Patent Owner” or “Finjan”) has asserted the ’408 patent in
`
`Finjan, Inc. v. Blue Coat Systems, Inc., No. 5-15-cv-03295 (N.D. Cal.); Finjan,
`
`Inc. v. Palo 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. Proofpoint, Inc.,
`
`No. 3-13-cv-05808 (N.D. Cal.). Two inter partes reviews involving the ’408
`
`patent, IPR2015-02001 and IPR2016-00157, each styled Palo Alto Networks, Inc.
`
`v. Finjan, Inc., were instituted on March 29, 2016 and consolidated into a single
`
`proceeding (“Consolidated PAN IPRs”) by the Board. Petitioner has filed herewith
`
`a motion to join the Consolidated PAN IPRs. The grounds presented in this
`
`petition match the grounds instituted from IPR2015-02001, and Petitioner has filed
`
`a second petition, IPR2016-00956, with grounds matching those instituted from
`
`IPR2016-00157.
`
`C. Lead and Back-Up Counsel under 37 C.F.R. § 42.8(b)(3)
`
`Lead Counsel
`
`Back-Up Counsel
`
`Michael T. Rosato
`
`Andrew S. Brown
`
`USPTO Reg. No. 52,182
`
`USPTO Reg. No. 74,177
`
`-2-
`
`

`
`
`
`WILSON SONSINI GOODRICH &
`
`WILSON SONSINI GOODRICH &
`
`ROSATI
`
`ROSATI
`
`701 Fifth Avenue
`
`701 Fifth Avenue
`
`Suite 5100
`
`Suite 5100
`
`Seattle, WA 98104-7036
`
`Seattle, WA 98104-7036
`
`Tel.: 206-883-2529
`
`Tel.: 206-883-2584
`
`Fax: 206-883-2699
`
`Fax: 206-883-2699
`
`Email: mrosato@wsgr.com
`
`Email: asbrown@wsgr.com
`
`
`
`D.
`
`Service Information
`
`Service information for lead and back-up counsel is provided in the
`
`designation of lead and back-up counsel, above. Petitioner consents to electronic
`
`service by email at the email addresses provided above.
`
`E.
`
`Power of Attorney
`
`Filed concurrently with this petition per 37 C.F.R. § 42.10(b).
`
`III.
`
`[RESERVED]
`
`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 eligible for IPR and further
`
`certifies that Petitioner is not barred or estopped from requesting this IPR.
`
`-3-
`
`

`
`
`
`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 each claim be found unpatentable. An explanation of why each
`
`claim is unpatentable under the grounds identified in Table 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
`
`’408 Patent Claims
`
`Basis for Challenge
`
`1
`
`1, 9, 22, 23, 29, 35 Obvious under § 103(a) by Chandnani in view
`
`of Kolawa
`
`2
`
`1, 9, 22, 23, 29, 35 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
`
`because 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,
`
`viruses can damage a computer, perform unauthorized operations, or otherwise
`
`inconvenience 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.)
`
`-4-
`
`

`
`
`
`A. Malware Detection
`
`Since at least 1988, antivirus software has served as a barrier between
`
`malware and the processor. (Ex. 1002 at ¶ 56.) The concept is to have a trusted
`
`program 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
`
`instance 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
`
`malware has been identified and its signature placed in a database, and is therefore
`
`unable 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
`
`extraneous 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
`
`“static 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
`
`-5-
`
`

`
`
`
`structured and 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
`
`hierarchical 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
`
`individual parse tree basis.”); Ex. 1002 at ¶¶ 65-70.)
`
`A parse tree is a representation of suspect code at a higher level of
`
`abstraction 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-
`
`

`
`
`
`
`
`(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
`
`signature to those of known viruses. (Ex. 1002 at ¶ 72.)
`
`-7-
`
`

`
`
`
`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
`
`method 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
`
`overlapping sub-disciplines: malware detection and vulnerability detection (code
`
`quality 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) advancements 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
`
`malicious programs using programming language-specific sets of rules and a
`
`“parse tree” data structure. (Ex. 1001 at Title, Abstract.) The ’408 patent
`
`describes scanning 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
`
`-8-
`
`

`
`
`
`“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
`
`(claims 1 and 23), system (claims 9 and 29), and Beauregard (claims 22 and 39)
`
`1[a]
`1[b]
`
`1[c]
`
`1[d]
`
`1[e]
`
`form, respectively. The elements of representative claim 1 are shown below:
`
`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
`programming languages in which the incoming stream is
`written;
` instantiating, by the computer, a scanner for the specific
`programming language, in response to said determining,
` the scanner comprising parser rules and analyzer rules for the
`specific programming 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
`patterns 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
`indicators 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[f]
`
`1[g]
`
`1[h]
`
`1[i]
`
`1[j]
`
`-9-
`
`

`
`
`
`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,
`
`2000, which is itself a continuation of Application No. 08/964,388 (now U.S.
`
`Patent 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
`
`earlier-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
`
`violates 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
`
`represent 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 disclosure 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,
`
`published, and/or issued in the United States before August 30, 2004, the earliest
`
`possible priority date of the claims of the ’408 patent.
`
`-10-
`
`

`
`
`
`VII. CLAIM CONSTRUCTION UNDER 37 C.F.R. § 42.104(B)(3)
`
`A.
`
`“Parse tree” (all claims)
`
`The BRI of the term “parse tree” is “tree data structure that represents
`
`program code.” This BRI is consistent with the use of the term in the claims and
`
`specification, 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
`
`content. 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
`
`identified within “an incoming stream of program code.” (Ex. 1001 at claim 1.) In
`
`the Consolidated PAN IPRs, the Board construed “parse tree” as a “hierarchical
`
`structure of interconnected nodes built from scanned content,” and found that the
`
`cited art disclosed the use of such structures. IPR2015-02001, paper 7 at 8, 18.
`
`B.
`
`“Dynamically building . . . while said receiving receives the
`incoming stream” (variants in all claims)
`
`The terms referenced immediately above1 all include the word
`
`“dynamically.” The BRI of each of the “dynamically building” terms is “building
`
`
`
`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-
`
`

`
`
`
`during a time period that overlaps with the time period during which the incoming
`
`stream is being received.” This construction was adopted by the Board in the
`
`Consolidated PAN IPRs. IPR2015-02001, paper 7 at 9.
`
`Although the ’408 patent does not define “dynamically,” the specification
`
`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 algorithm.
`
`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
`
`another. (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
`
`resident on the computer.” (Ex. 1021 at 14 (emphases added); see also Ex. 1002
`
`at ¶ 166.) Thus, consistent with the BRI set forth above, receipt of the incoming
`
`data stream must overlap with the process of building the parse tree.
`
`-12-
`
`

`
`
`
`C.
`
` “Dynamically detecting . . . while said dynamically building
`builds the parse tree” (variants in all claims)
`
`Like the “dynamically building” terms discussed in the previous section, the
`
`terms referenced immediately above2 all include the word “dynamically.” The BRI
`
`of each of the “dynamically detecting” terms is “detecting during a time period that
`
`overlaps with the time period during which the parse tree is being built.” This
`
`construction was adopted by the Board in the Consolidated PAN IPRs. IPR2015-
`
`02001, paper 7 at 10.
`
`This BRI is consistent with the specification, which describes building part
`
`of the parse tree, looking for potential exploits, and then building more of the parse
`
`tree and looking for more potential exploits. (See Ex. 1001 at Fig. 5 (showing that
`
`the analyzer is called to determine if a potential exploit is present (step 560) before
`
`the next node of the parse tree is created (step 540)), 14:53-55 (“the analyzer is
`
`called repeatedly, while the parse tree is being dynamically built up”) (emphasis
`
`added).) Thus, similar to the “dynamically building” term discussed in the
`
`previous section, the steps of “building” the parse tree and “detecting” potential
`
`exploits are at least partially interleaved with one another. (See id.)
`
`
`
`2 Each of the Petitioned Claims includes one of the following terms:
`
`“dynamically detecting, [] while said dynamically building builds the parse tree”
`
`(claims 1, 22, 23, 35); or “dynamically detecting, while said parser is dynamically
`
`building the parse tree” (claims 9 and 29).
`
`-13-
`
`

`
`
`
`D.
`
` “Instantiating . . . a scanner for the specific programming
`language” (claims 1 and 22)
`
`The BRI of the term “instantiating . . . a scanner for the specific
`
`programming language” is “making a language-specific scanner available for use.”
`
`The specification does not define “instantiating,” and simply refers to provision of
`
`a scanner. (See Ex. 1001 at 15:30-35 (“ARB scanner factory module 630
`
`instantiates a scanner repository 640. Repository 640 produces a single instance of
`
`each ARB scanner defined in the archive file.”); see also Ex. 1014 at 3 (defining
`
`“instantiate” as “[t]o create an instance of a class”); Ex. 1002 at ¶ 130.) In the
`
`Consolidated PAN IPRs, the Board construed “instantiating . . . a scanner for the
`
`specific programming language” as “substituting specific data, instructions, or both
`
`into a generic program unit to make it usable for scanning the specific
`
`programming language,” and found that there was “sufficient disclosure in
`
`Chandnani even under [this] construction.” IPR2015-02001, paper 7 at 12, 18.
`
`VIII. PERSON HAVING ORDINARY SKILL IN THE ART & STATE OF THE ART
`
`The ’408 patent is directed at the field of computer security programs,
`
`including content scanners for analyzing program code. (Ex. 1002 at ¶ 30.) At the
`
`time of the alleged invention in or around August 2004, a person of ordinary skill
`
`in the art (“POSA”) held a bachelor’s degree or the equivalent in computer science
`
`(or related academic fields) and three to four years of additional experience in the
`
`field of computer security, or equivalent work experience. (Id. at ¶ 33.)
`
`-14-
`
`

`
`
`
`IX. CLAIMS 1, 9, 22, 23, 29, AND 35 OF THE ’408 PATENT ARE UNPATENTABLE
`
`As detailed in Sections X and XI below, the Petitioned Claims are
`
`unpatentable. Both grounds presented below invalidate the challenged claims
`
`using Chandnani as a base reference. Ground 1 combines Chandnani’s multi-
`
`language scanner with Kolawa, which explicitly teaches the use of parse trees for
`
`storing and analyzing code in the related field of code quality analysis. Ground 2
`
`is an alternative ground that adds to Ground 1 prior art (Walls) that expressly
`
`teaches pipelining techniques that satisfy the “dynamically building” and
`
`“dynamically detecting” limitations of the Petitioned Claims. If the Board declines
`
`to institute IPR under Ground 1, the Board should institute IPR under Ground 2.
`
`Below is an overview of each prior art reference and an explanation of why
`
`it would have been obvious to combine the teachings of the prior art.
`
`A. Overview of Chandnani
`
`U.S. Patent No. 7,636,945 (“Chandnani”), titled “Detection of Polymorphic
`
`Script Language Viruses by Data Driven Lexical Analysis,” was filed on July 14,
`
`2001. Chandnani is prior art under 35 U.S.C. § 102(b) because it was published on
`
`June 13, 2002, more than one year before the filing date of the ’408 patent.
`
`Chandnani teaches detecting polymorphic script