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-00956
`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) ................... 3
`
`III. 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
`
`hreshold Requirement for Inter Partes Review Under 37 C.F.R.
`§ 42.108(c) .......................................................................................... 4
`
`IV. BACKGROUND OF TECHNOLOGY RELATED TO THE ʼ408
`PATENT ....................................................................................................... 5
`
`A. Malware Detection .............................................................................. 5
`
`B.
`
`Static Analysis Using Parse Trees ....................................................... 6
`
`C. Malware and Vulnerability Detection ................................................. 8
`
`V.
`
`SUMMARY OF THE ʼ408 PATENT ........................................................... 8
`
`A.
`
`Brief Description of the ʼ408 Patent .................................................... 8
`
`B.
`
`C.
`
`Petitioned Claims of the ʼ408 Patent ................................................... 9
`
`Priority Date of the ʼ408 Patent ......................................................... 10
`
`VI. CLAIM CONSTRUCTION UNDER 37 C.F.R. § 42.104(b)(3) .................. 11
`
`-i-
`
`

`
`A.
`
`B.
`
`C.
`
`D.
`
`
`“Parse tree” (all claims) .................................................................... 11
`
`“Dynamically building . . . while said receiving receives the
`incoming stream” (variants in all claims) .......................................... 12
`
`“Dynamically detecting . . . while said dynamically building
`builds the parse tree” (variants in all claims) ..................................... 13
`
`“Instantiating . . . a scanner for the specific programming
`language” (variants in all claims) ...................................................... 14
`
`VII. PERSON HAVING ORDINARY SKILL IN THE ART & STATE
`OF THE ART ............................................................................................. 15
`
`VIII. PETITIONED CLAIMS 3-7, 12-16, AND 18-21 OF THE ʼ408
`PATENT ARE UNPATENTABLE ............................................................ 15
`
`A. Overview of Chandnani .................................................................... 16
`
`B.
`
`C.
`
`Overview of Kolawa ......................................................................... 16
`
`Overview of Walls ............................................................................ 17
`
`D. Overview of Huang ........................................................................... 18
`
`E.
`
`F.
`
`Chandnani, Kolawa, Walls, and Huang Are All Analogous Art ........ 19
`
`General Motivations to Combine the Prior Art Teachings ................. 20
`
`IX. CHANDNANI IN VIEW OF KOLAWA RENDERS THE
`PETITIONED CLAIMS 3-5, 12-16, AND 18-19 INVALID AS
`OBVIOUS UNDER 35 U.S.C. § 103 (GROUND 1) ................................... 20
`
`A.
`
`Claim 1 ............................................................................................. 21
`
`i.
`
`ii.
`
`Claim 1 – preamble ................................................................. 21
`
`Claim element 1[a] – receiving a stream of code ..................... 21
`
`iii. Claim element 1[b] – determining a programming
`language ................................................................................. 21
`
`iv.
`
`Claim element 1[c] – instantiating a scanner ........................... 22
`
`-ii-
`
`

`
`
`
`v.
`
`Claim element 1[d] – scanner with language-specific
`rules ........................................................................................ 22
`1.
`Claim element 1[e] - parser rules .................................. 23
`2.
`Claim element 1[f] - analyzer rules ............................... 24
`
`vi.
`
`Claim element 1[g] – identifying tokens ................................. 25
`
`vii. Claim element 1[h] – dynamically building a parse tree .......... 25
`1.
`Building a parse tree ..................................................... 26
`2.
`Dynamically building.................................................... 30
`
`viii. Claim element 1[i] – dynamically detecting exploits ............... 31
`1.
`Detecting potential exploits........................................... 31
`2.
`Dynamically detecting .................................................. 32
`
`ix.
`
`Claim element 1[j] – indicating presence of exploits ............... 33
`
`B.
`
`Claim 9 ............................................................................................. 34
`
`i.
`
`ii.
`
`Claim 9 – preamble ................................................................. 35
`
`Claim element 9[a] – computer-readable storage medium ....... 35
`
`iii. Claim element 9[b] – receiver ................................................. 36
`
`iv.
`
`Claim element 9[c] – multi-lingual language detector ............. 36
`
`v.
`
`Claim element 9[d] – scanner instantiator ............................... 37
`
`vi.
`
`Claim element 9[e] – rules accessor ........................................ 38
`
`vii. Claim elements 9[f]-[g] – parser and analyzer rules ................ 38
`
`viii. Claim element 9[h] – tokenizer ............................................... 39
`
`ix.
`
`Claim element 9[i] – parser ..................................................... 39
`
`x.
`
`Claim element 9[j] – analyzer ................................................. 40
`
`xi.
`
`Claim element 9[k] – notifier .................................................. 41
`
`C.
`
`Dependent Claim 3: “The method of claim 1 wherein the parser
`rules and analyzer rules include actions to be performed when
`rules are matched” ............................................................................ 41
`
`-iii-
`
`

`
`
`
`D. Dependent Claim 4: “The method of claim 1 wherein the
`specific programming language is JavaScript” .................................. 43
`
`E.
`
`F.
`
`Dependent Claim 5: “The method of claim 1 wherein the
`specific programming language is Visual Basic VBScript” ............... 44
`
`Dependent Claim 12: “The system of claim 9 wherein said
`parser comprises a pattern-matching engine, for matching a
`pattern within a sequence of tokens in accordance with the
`parser rules accessed by said rules accessor” .................................... 44
`
`G. Dependent Claim 13: “The system of claim 12 wherein the
`parser rules accessed by said rules accessor are represented as
`finite-state machines”........................................................................ 45
`
`H. Dependent Claim 14: “The system of claim 12 wherein the
`parser rules are represented as pattern expression trees” ................... 45
`
`I.
`
`J.
`
`Dependent Claim 15: “The system of claim 12 wherein parser
`rules are merged into a single deterministic finite automaton
`(DFA)” ............................................................................................. 46
`
`Dependent Claim 16: “The system of claim 9 wherein the
`parser rules and analyzer rules include actions to be performed
`when rules are matched” ................................................................... 47
`
`K. Dependent Claim 18: “The system of claim 9 wherein the
`parser rules and analyzer rules include actions to be performed
`when rules are matched” ................................................................... 47
`
`L.
`
`Dependent Claim 19: “The system of claim 9 wherein the
`parser rules and analyzer rules include actions to be performed
`when rules are matched” ................................................................... 47
`
`X.
`
`CHANDNANI IN VIEW OF KOLAWA AND HUANG RENDERS
`THE PETITIONED CLAIMS 6-7 AND 20-21 INVALID AS
`OBVIOUS UNDER 35 U.S.C. § 103 (GROUND 2) ................................... 48
`
`A. Dependent Claim 6: “The method of claim 1 wherein the
`specific programming language is HTML” ....................................... 48
`
`-iv-
`
`

`
`
`
`B.
`
`C.
`
`Dependent Claim 7: “The method of claim 1 wherein the
`specific programming language is Uniform Resource Identifier
`(URI)”............................................................................................... 48
`
`Dependent Claim 20: “The system of claim 9 wherein the
`specific programming language is HTML” ....................................... 49
`
`D. Dependent Claim 21: “The system of claim 9 wherein the
`specific programming languages language is Uniform Resource
`Identifier (URI)” ............................................................................... 49
`
`XI. CHANDNANI IN VIEW OF KOLAWA AND WALLS RENDERS
`THE PETITIONED CLAIMS 3-5, 12-16, AND 18-19 INVALID AS
`OBVIOUS UNDER 35 U.S.C. § 103 (GROUND 3) ................................... 50
`
`A. Dynamically building a parse tree ..................................................... 50
`
`B.
`
`Dynamically detecting potential exploits .......................................... 52
`
`XII. CHANDNANI IN VIEW OF KOLAWA, WALLS, AND HUANG
`RENDERS THE PETITIONED CLAIMS 6-7 AND 20-21 INVALID
`AS OBVIOUS UNDER 35 U.S.C. § 103 (GROUND 4) ............................. 53
`
`XIII. NO SECONDARY CONSIDERATIONS OF NON-OBVIOUSNESS
`EXIST......................................................................................................... 54
`
`XIV. Payment of Fees under 37 C.F.R. §§ 42.15(a) and 42.103........................... 55
`
`XV. Appendix – List of Exhibits ........................................................................ 56
`
`
`
`
`
`-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 3-7, 12-16,
`
`and 18-21 (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
`
`independent claims from which the Petitioned Claims depend 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 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
`
`1
`
`

`
`
`
`then searching for patterns that identify problematic code. Chandnani in
`
`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 IPR2016-00157, and Petitioner has filed
`
`a second petition, IPR2016-00955, with grounds matching those instituted from
`
`IPR2015-02001.
`
`-2-
`
`

`
`
`
`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
`
`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
`
`
`
`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 address provided above.
`
`III. 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 3-7, 12-16, and 18-21 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 VIII. Additional explanation and support for each ground of
`
`unpatentability are 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
`
`3, 4, 5, 12-16, 18, 19
`
`Obvious under § 103(a) by Chandnani
`
`in view of Kolawa
`
`2
`
`6, 7, 20, 21
`
`Obvious under § 103(a) by Chandnani
`
`in view of Kolawa and Huang
`
`3
`
`3, 4, 5, 12-16, 18, 19
`
`Obvious under § 103(a) by Chandnani
`
`in view of Kolawa and Walls
`
`4
`
`6, 7, 20, 21
`
`Obvious under § 103(a) by Chandnani
`
`in view of Kolawa, Walls, and Huang
`
`
`
`C. Threshold Requirement for Inter Partes Review Under 37 C.F.R.
`§ 42.108(c)
`
`Inter partes review of claims 3-7, 12-16, and 18-21 should be instituted
`
`-4-
`
`

`
`
`
`because this Petition establishes a reasonable likelihood that Petitioner will prevail
`
`with respect to one or more of the challenged claims. 35 U.S.C. § 314(a).
`IV. 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 ¶ 42.) Those in the art often refer to harmful or
`
`unauthorized programs as “malicious software” or “malware.” (Id. ¶ 43.)
`
`A. Malware Detection
`
`Since at least 1988, antivirus software has served as a barrier between
`
`malware and the processor. (Id. ¶ 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. (Id. ¶¶ 58-59; Ex. 1003 at 2:17-21.) Signature scanning
`
`requires a database of known patterns found in (and preferably only in) malware.
`
`(Ex. 1002 ¶ 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; it is therefore
`
`unable to protect against previously-unseen harmful programs. (Id. ¶ 60.)
`
`-5-
`
`

`
`
`
`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.
`
`(Id. ¶ 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. (Ex. 1002 ¶¶ 61-62.)
`
`In 2004, one approach to detecting polymorphic viruses was known as 5
`
`“static analysis.” (See, e.g., Ex. 1008, Ex. 1010, Ex. 1002 ¶¶ 63-64.) 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 expected to
`
`function. (Ex. 1002 ¶ 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 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 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 at 5 (“[T]he firewall compares this
`
`parse tree with the rules you’ve devised.”); Ex. 1004 at 5:62-64 (“The quality of
`
`the source code 10 is checked on an individual parse tree basis.”); Ex. 1002 ¶¶ 65-
`
`70.)
`
`-6-
`
`

`
`
`
`A parse tree is a representation of suspect code at a higher level of
`
`abstraction than the code itself. (Ex. 1002 ¶ 66.) Parse trees preserve the 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:
`
`
`
`(Ex. 1006 at Fig. 14; see also Ex. 1002 ¶ 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 ¶¶ 67-69.) Token creation is performed using a process called “lexical
`
`analysis.” (Id. ¶ 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 ¶¶ 66, 70, 72; Ex. 1011 at 13:33-50.) Parse trees are useful for
`
`-7-
`
`

`
`
`
`detecting viral structures while ignoring details of the exact code used in the virus.
`
`(Ex. 1002 ¶¶ 71-72; Ex. 1012 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 ¶ 72.)
`
`Techniques for building parse trees were well known in 2004, when the ʼ408
`
`patent was filed. (Id. ¶ 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
`
`at 34.)
`
`C. Malware and 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 ¶¶ 71-76.) The person of ordinary skill in the art
`
`(“POSA”) recognized the extensive overlap between these two sub-disciplines
`
`because malware was often designed to exploit vulnerabilities in software. (Id.; see
`
`Ex. 1005 at 1:48-65; Ex. 1013 at 1.) For that reason, the POSA stayed current with
`
`(and sometimes taught) advancements in both disciplines. (Ex. 1002 ¶ 76.)
`V.
`
`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; Ex. 1002 ¶¶ 83-86.) The
`
`-8-
`
`

`
`
`
`ʼ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 “parser rules” and “analyzer rules” specific to one of multiple
`
`programming languages.
`
`B.
`
`Petitioned Claims of the ʼ408 Patent
`
`Petitioned Claims 3-7 depend from independent claim 1, and Petitioned
`
`Claims 12-16 and 18-21 depend directly or indirectly from independent claim 9.
`
`Petitioned Claims 3-7, 16, 18-21 recite essentially the same elements in method
`
`(claims 3-7) and system (claims 16 and 18-21) form, respectively. Petitioned
`
`Claims 12-15 depend directly or indirectly from claim 9. The elements of
`
`representative independent claim 1 are shown below:
`
`No.
`
`Claim Limitation
`
`1[a]
`1[b]
`
`1[c]
`
`1[d]
`
`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;
`
`1[e]
`
`1[f]
`
`-9-
`
`

`
`
`
`No.
`
`1[g]
`
`1[h]
`
`1[i]
`
`1[j]
`
`Claim Limitation
`
`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.
`
`The additional elements of the Petitioned Claims are shown below:
`
`No.
`
`Claim Limitation
`
`12
`
`3 and 16 wherein the parser rules and actions analyzer rules include actions to
`be performed when rules are matched
`4 and 18 wherein the specific programming language is JavaScript
`5 and 19 wherein the specific programming language is Visual Basic script
`6 and 20 wherein the specific programming language is HTML
`7 and 21 wherein the specific programming language is Uniform Resource
`Identifier (URI)
`wherein said parser comprises a pattern-matching engine, for matching
`a pattern within a sequence of tokens in accordance with the parser
`rules accessed by said rules accessor
`wherein the parser rules accessed by said rules accessor are
`represented as finite-state machines
`wherein the parser rules are represented as pattern expression trees
`wherein parser rules are merged into a single deterministic finite
`automaton (DFA)
`
`13
`
`14
`15
`
`
`
`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.
`
`-10-
`
`

`
`
`
`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 VIII 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.
`VI. CLAIM CONSTRUCTION UNDER 37 C.F.R. § 42.104(B)(3)
`
`A.
`
`“Parse tree” (all claims)
`
`The broadest reasonable interpretations (“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
`
`-11-
`
`

`
`
`
`“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. IPR2016-00157, paper 10 at 8, 17.
`
`B.
`
`“Dynamically building . . . while said receiving receives the
`incoming stream” (variants in all claims)
`
`The claims subject to this petition depend from either claim 1 or claim 9 and
`
`therefore each includes a limitation directed to “dynamically building.” 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.”
`
`This construction was adopted by the Board in the Consolidated PAN IPRs.
`
`IPR2016-00157, paper 10 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
`
`-12-
`
`

`
`
`
`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 ¶¶ 167-70.)
`
`During prosecution, the Patentee confirmed that “dynamically building”
`
`means that the claimed invention “parses and analyses 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
`
`¶ 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.
`
`C.
`
`“Dynamically detecting . . . while said dynamically building builds
`the parse tree” (variants in all claims)
`
`As with the “dynamically building” terms discussed in the previous section,
`
`because the claims subject to this petition depend from either claim 1 or claim 9,
`
`each includes a limitation directed to “dynamically detecting.” 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. IPR2016-00157, paper
`
`10 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
`
`-13-
`
`

`
`
`
`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.)
`
`D.
`
`“Instantiating . . . a scanner for the specific programming
`language” (variants in all claims)
`
`The claims subject to this petition also include limitations directed to
`
`“instantiating . . . a scanner for the specific programming language.” The BRI of
`
`these terms 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 ¶ 135.) 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.” IPR2016-00157, paper 10 at 12, 18.
`
`-14-
`
`

`
`
`
`VII. 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 a