`571-272-7822
`
`
`
`
`
`Paper 7
`Entered: March 29, 2016
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`
`PALO ALTO NETWORKS, INC.,
`Petitioner,
`
`v.
`
`FINJAN, INC.,
`Patent Owner.
`____________
`
`Case IPR2015-02001
`Case IPR2016-00157
`Patent 8,225,408 B21
`____________
`
`
`
`
`
`Before THOMAS L. GIANNETTI, MIRIAM L. QUINN, and
`PATRICK M. BOUCHER, Administrative Patent Judges.
`
`BOUCHER, Administrative Patent Judge.
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`1 We consolidate the proceedings under 35 U.S.C. § 314(d). The parties are
`directed to use a similar caption that identifies both proceedings in
`subsequently filed papers.
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`
`On September 30, 2015, Palo Alto Networks, Inc. (“Petitioner”) filed
`a Petition (IPR2015-02001, Paper 2 (“Pet. 2001”)) pursuant to 35 U.S.C.
`§§ 311–319 to institute an inter partes review of certain claims (claims 1, 9,
`22, 23, 29, and 35) of U.S. Patent No. 8,225,408 B2 (“the ’408 patent”). On
`November 6, 2015, Petitioner filed a second Petition (IPR2016-00157, Paper
`2 (“Pet. 157”)) to institute an inter partes review of certain additional claims
`(claims 3–7, 12–16, and 18–21) of the ’408 patent. Finjan, Inc. (“Patent
`Owner”) filed Preliminary Responses (IPR2015-02001, Paper 6 (“Prelim.
`Resp. 2001”); IPR2016-00157, Paper 9 (“Prelim. Resp. 157”)) on January 6,
`2016, and February 17, 2016, respectively.
`Claims 3–7 depend from independent claim 1, and claims 12–16 and
`18–21 depend (directly or indirectly) from independent claim 9. Therefore,
`much of Petitioner’s analysis in its Petition for IPR2016-00157, particularly
`as it relates to underlying independent claims 1 and 9 (which are specifically
`challenged in IPR2015-02001), duplicates the analysis presented in the
`Petition for IPR2015-02001. Similarly, Patent Owner’s Preliminary
`Response in IPR2016-00157 largely reproduces the Preliminary Response
`filed in IPR2015-02001, relying principally on its arguments for underlying
`independent claims 1 and 9 in each of the challenges rather than directly
`addressing challenged dependent claims 3–7, 12–16, and 18–21. See Prelim.
`Resp. 157, 22, 27, 30, 32, 37, 39.
`Applying the standard set forth in 35 U.S.C. § 314(a), which requires
`demonstration of a reasonable likelihood that Petitioner would prevail with
`respect to at least one challenged claim, we consider these Petitions together,
`institute inter partes review of claims 1, 3–7, 9, 12–16, 18–23, 29, and 35,
`
`2
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`and consolidate the trial proceedings. In subsequent briefing, the parties
`shall file consolidated briefs that collectively address the issues in both
`proceedings, subject to the usual page limits. The Board has not made a
`final determination of the patentability of any claim.
`
`
`I. BACKGROUND
`A. The ’408 Patent
`The ’408 patent relates to network security, including scanning
`content that includes “mobile code” to produce a diagnostic analysis of
`potential exploits, such as viruses, within the code. Ex. 1001,2 col. 1, ll. 19–
`20, col. 1, ll. 59–64. Figure 2 of the ’408 patent is reproduced below.
`
`
`2 Unless otherwise noted, citations to exhibits are to IPR2015-02001.
`3
`
`
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`Figure 2 provides a simplified block diagram of an adaptive rule-based
`content scanner system. Id. at col. 6, ll. 14–17.
`The ’408 patent explains that the adaptive rule-based scanner of
`Figure 2 “is preferably designed as a generic architecture that is language-
`independent, and is customized for a specific language through use of a set
`of language-specific rules.” Id. at col. 6, ll. 17–20. In addition, “security
`violations, referred to as exploits, are described using a generic syntax,
`which is also language-independent.” Id. at col. 6, ll. 28–30. Adaptive rule-
`based scanner 200 includes three main components: (1) tokenizer 210,
`which recognizes and identifies constructs (i.e., “tokens”) within a byte
`source code; (2) parser 220, which controls the process of scanning
`incoming content, such as with a parse tree data structure that represents the
`incoming content; and (3) analyzer 230, which checks for exploits by
`searching for specific patterns of content that indicate an exploit. Id. at col.
`6, ll. 50–54, col. 8, ll. 18–27, col. 9, ll. 19–22. Sub-scanner 270 is another
`adaptive rule-based scanner used to scan a subsection of input being
`processed by scanner 200. Id. at col. 9, ll. 7–8. Pattern matching engine 260
`performs pattern matching for both parser 220 and analyzer 230, such as by
`accepting an input list of regular-expression elements describing a pattern of
`interest and an input list of nodes from the parse tree to be matched against
`the pattern of interest, and outputting a Boolean flag indicating whether a
`pattern is matched. Id. at col. 9, ll. 44–58.
`Using a “scanner factory,” such adaptive rule-based scanners may be
`produced “on demand” for different types of content. Id. at col. 15, ll. 15–
`16. The scanner factory “instantiates” a scanner repository, which produces
`
`4
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`a single instance of multiple scanners, such as “a scanner for HTML content,
`a scanner for JavaScript content, and a scanner for URI content,” each “able
`to initialize itself and populate itself with the requisite data.” Id. at col. 15,
`ll. 31–41. When content is downloaded, a pool of thread objects is created
`and stores the scanner-factory instance as member data. Id. at col. 15, ll. 53–
`55. When a thread object has content to parse, it requests an appropriate
`scanner from its scanner-factory object; when the thread finishes scanning
`the content, it returns the scanner instance to its scanner factory, “to enable
`pooling the [adaptive rule-based] scanner for later use.” Id. at col. 15, ll. 56–
`63.
`
`
`B. Illustrative Claim
`Independent claim 1 of the ’408 patent is illustrative of the claims at
`
`issue.
`
`code;
`
`1. A computer processor-based multi-lingual method for
`scanning incoming program code, comprising:
`receiving, by a computer, an incoming stream of program
`
`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
`patters as being indicators of potential exploits, exploits being
`portions of program code that are malicious;
`
`5
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`
`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.
`
`
`C. References
`Petitioner relies on the following references.
`Chandnani
`US 7,636,945 B2
`Dec. 22, 2009
`Kolawa
`US 5,860,011
`Jan. 12, 1999
`Walls
`US 7,284,274 B1
`Oct. 16, 2007
`Huang
`US 6,968,539 B1
`Nov. 22, 2005
`
`
`
`Ex. 1003
`Ex. 1004
`Ex. 1005
`Ex. 1062 of
`IPR2016-00157
`
`D. Asserted Grounds of Unpatentability
`Petitioner challenges independent claims 1, 9, 22, 23, 29, and 35 in
`IPR2015-02001, and challenges dependent claims 3–7, 12–16, and 18–21 in
`IPR2016-00157, as obvious under 35 U.S.C. § 103(a) as follows on the
`following grounds. Pet. 2001, 4; Pet. 157, 4.
`
`
`Claims Challenged
`References
`1, 3–5, 9, 12–16, 18, 19, 22, 23, 29, and 35
`Chandnani and Kolawa
`1, 3–5, 9, 12–16, 18, 19, 22, 23, 29, and 35
`Chandnani, Kolawa, and Walls
`6, 7, 20, and 21
`Chandnani, Kolawa, and Huang
`Chandnani, Kolawa, Walls, and Huang 6, 7, 20, and 21
`
`
`6
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`
`E. Related Proceedings
`The parties assert that the ’408 patent is the subject of the following
`district-court proceedings: (1) Finjan, Inc. v. Palo Alto Networks, Inc., No.
`3-14-cv-04908 (N.D. Cal.); (2) Finjan, Inc. v. FireEye, Inc., No. 4-13-cv-
`03113 (N.D. Cal.); (3) Finjan, Inc. v. Proofpoint, Inc., No. 3-13-cv-05808
`(N.D. Cal.); (4) Finjan, Inc. v. Blue Coat Systems, Inc., No. 5-15-cv-03295;
`and (5) Finjan, Inc. v. Websense, Inc., No. 5:13-cv-04398 (N.D. Cal.). Pet.
`2001, 2; Paper 5, 1; Pet. 157, 2; Paper 8 (IPR2016-00157), 1.3
`
`
`II. ANALYSIS
`A. Claim Construction
`The Board interprets claims of an unexpired patent using the broadest
`reasonable construction in light of the specification of the patent in which
`they appear. See 37 C.F.R. § 42.100(b); In re Cuozzo Speed Techs., LLC,
`793 F.3d 1268, at 1278 (Fed. Cir. 2015) (“We conclude that Congress
`implicitly approved the broadest reasonable interpretation standard in
`enacting the AIA”), cert. granted sub nom., Cuozzo Speed Techs., LLC v.
`Lee, 84 U.S.L.W. 3218 (U.S. Jan. 15, 2016) (No. 15-446); Office Patent
`Trial Practice Guide, 77 Fed. Reg. 48,756, 48,766 (Aug. 14, 2012).
`
`
`
`
`
`3 Petitioner omits identification of the Websense matter from the statement in
`its Petition in IPR2015-02001, and Patent Owner omits identification of the
`Websense matter from the statement in its mandatory notices in IPR2016-
`00157.
`
`7
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`
`1. “parse tree”
`Each of independent claims 1, 9, 22, 23, 29, and 35 recites
`“dynamically building . . . a parse tree.” Petitioner proposes that the term
`“parse tree” be construed as a “tree data structure that represents program
`code.” Pet. 2001, 11. Patent Owner proposes that the term be construed
`instead as a “hierarchical structure of interconnected nodes built from
`scanned content,” noting that “[t]his is the construction arrived at by the
`District Court in Finjan, Inc. v. Proofpoint, Inc.” Prelim. Resp. 2001, 6.
`Patent Owner contends that Petitioner’s proposed construction “is unduly
`broad because it would encompass any tree data structure that could possibly
`represent program code.” Id. Although district courts apply a different
`claim-construction standard for unexpired patents, we agree with Patent
`Owner that its proposed construction is also commensurate with the broadest
`reasonable interpretation in light of the patent specification.
`For purposes of this Decision, we construe “parse tree” as a
`“hierarchical structure of interconnected nodes built from scanned content.”
`
`
`2. “dynamically building”
`Independent claims 1, 22, 23, and 35 recite “dynamically building [a
`parse tree] while said receiving receives the incoming stream.” Independent
`claims 9 and 29 similarly recite “dynamically building [a parse tree] while
`said receiver is receiving the incoming stream.” Petitioner proposes that
`each of these limitations be construed as “building during a time period that
`overlaps with the time period during which the incoming stream is being
`received.” Pet. 2001, 12. Patent Owner contends that there is no need to
`
`8
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`construe the phrase, and does not offer a construction. Prelim. Resp. 2001,
`7–8.
`
`The Specification of the ’408 patent describes a preferred embodiment
`in which the parser “controls the process of scanning incoming content” by
`invoking the tokenizer and giving it a callback function when a token is
`ready. Ex. 1001, col. 8, ll. 18–23. The parser is described as building the
`parse tree “dynamically” using a “shift-and-reduce algorithm” in which
`successive tokens provided to the parser by the tokenizer are positioned as
`siblings. Id. at col. 8, ll. 29–32. Thus, the Specification makes clear that
`“dynamically” building the parse tree makes use of current hierarchical data.
`See id. at col. 8, ll. 32–37 (“When parser 220 discovers that a parsing rule
`identifies a group of siblings as a single pattern, the siblings are reduced to a
`single parent node . . . .”).
`We also find merit in Petitioner’s proposed construction, which
`captures the requirement of a temporal overlap in dynamically building the
`parse tree and receiving the incoming stream. Accordingly, for purposes of
`this Decision, we construe the phrase as requiring that a time period for
`dynamically building overlap with a time period during which the incoming
`stream is being received.
`
`
`3. “dynamically detecting”
`Independent claim 1 recites “dynamically detecting [combinations of
`nodes in the parse tree] while said dynamically building builds the parse
`tree.” The other independent claims include similar recitations that both
`parties propose be construed identically. Pet. 2001, 13; Prelim. Resp. 2001,
`
`9
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`9. Petitioner proposes that these limitations be construed as “detecting
`during a time period that overlaps with the time period during which the
`parse tree is being built.” Pet. 2001, 13. Patent Owner contends that there is
`no need to construe the phrases, and does not offer a construction. Prelim.
`Resp. 2001, 9–10.
`Similar to the “dynamically building” limitations, the Specification of
`the ’408 patent describes making use of current hierarchical data in detecting
`node combinations in the parse tree: “By default, when the pattern within a
`parser rule is matched, parser 220 automatically performs a reduce operation
`by creating a new node and moving token nodes underneath.” Ex. 1001, col.
`8, l. 66–col. 9, l. 2.
`As for the “dynamically building” limitations, we find merit in
`Petitioner’s proposed construction, which captures the requirement of a
`temporal overlap in dynamically detecting certain nodes in the parse tree and
`building the parse tree. Accordingly, for purposes of this Decision, we
`construe the phrases as requiring that a time period for dynamically
`detecting overlap with a time period during which the parse tree is built.
`
`4. “instantiating . . . a scanner for the specific programming language”
`Independent claims 1, 9, and 22 recite “instantiating . . . a scanner for
`the specific programming language.” Petitioner proposes that the phrase be
`construed as “making a language-specific scanner available for use.” Pet.
`2001, 13–14. Petitioner also provides a definition of “instantiate” from a
`technical dictionary as “[t]o create an instance of a class.” Id. at 14 (citing
`Ex. 1014, 3). Patent Owner proposes that the phrase be construed as
`
`10
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`“creating a real instance of a scanner for the specific programming
`language,” contending that the dictionary definition provided by Petitioner is
`more consistent with Patent Owner’s proposal than with Petitioner’s.
`Prelim. Resp. 2001, 10–11. Petitioner’s expert, Aviel D. Rubin, Ph.D.,
`testifies that “[i]n computer science, ‘instantiating’ something means to
`create it.” Ex. 1002 ¶ 135. This testimony is more consistent with Patent
`Owner’s proposed construction than with Petitioner’s.
`Even under the broadest reasonable construction standard, the claims
`must be read in light of the specification. Microsoft Corp. v. Proxyconn,
`Inc., 789 F.3d 1292, 1298 (Fed. Cir. 2015). Although Patent Owner’s
`proposed construction is more consistent with the ordinary technical usage
`of “instantiating,” it is not consistent with the process described in the
`Specification of the ’408 patent when the claims are considered as a whole.
`Specifically, each of independent claims 1, 9, and 22 requires that
`instantiating the scanner be performed “in response to” “determining any
`specific one of a plurality of programming languages in which the incoming
`stream is written.”4 But creation of the scanners is described in the
`Specification as occurring to produce the scanner repository, separate from a
`determination of programming language for the stream of program code.
`See Ex. 1001, col. 15, ll. 30–34. According to the Specification, such
`
`
`4 Claim 9 recites “detecting any specific one of a plurality of programming
`languages in which the incoming stream is written” (emphasis added), but
`requires instantiating the scanner “in response to said determining”
`(emphasis added), without apparent antecedent basis. We consider “said
`determining” as intended to refer to the previously recited “detecting,” in
`parallel with the structure of claims 1 and 22.
`
`
`11
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`previously created scanners are requested from the scanner repository after
`the programming language has been determined, and returned to the scanner
`repository after the content has been scanned. Id. at col. 15, ll. 53–63.
`We find further support for construction of this limitation in the IEEE
`Standard Dictionary of Electrical and Electronic Terms, Sixth Edition (IEEE
`1996), which defines “instantiation (software)” as “[t]he process of
`substituting specific data, instructions, or both into a generic program unit to
`make it usable in a computer program.” Ex. 3001.5 This more general
`definition encompasses the procedure described in the Specification, which
`substitutes the specific data and instructions of a particular scanner obtained
`from the scanner factory into the generic program to make it usable for
`scanning a stream of programming code in an identified programming
`language.
`Accordingly, for purposes of this Decision, and based on the record
`currently before us, we construe “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.”
`
`
`
`5 Although technical treatises and dictionaries fall within the category of
`extrinsic evidence, they are worthy of special note. Judges are free to
`consult such resources at any time in order to better understand the
`underlying technology and may also rely on dictionary definitions when
`construing claim terms, so long as the dictionary definition does not
`contradict any definition found in or ascertained by a reading of the patent
`documents. Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1584 n. 6
`(Fed. Cir. 1996).
`
`12
`
`
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`
`B. Obviousness over Chandnani and Kolawa
`
`Petitioner challenges claims 1, 3–5, 9, 12–16, 18, 19, 22, 23, 29, and
`35 as unpatentable under 35 U.S.C. § 103(a) over Chandnani and Kolawa,
`addressing the challenged independent claims in IPR2015-02001 and the
`challenged dependent claims in IPR2016-00157. Pet. 2001, 19–56; Pet. 157,
`21–52. Patent Owner presents no separate arguments directed at the
`challenged dependent claims, relying on its arguments directed at the
`independent claims. See Prelim. Resp. 157, 27.
`Chandnani “relates to the detection of script language viruses,”
`particularly polymorphic script language viruses, which copy themselves
`differently to change their signatures and make themselves appear different
`each time they spread. Ex. 1003, col. 1, ll. 15–18, col. 2, ll. 54–56. Figure 2
`of Chandnani is reproduced below.
`
`13
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`
`
`Figure 2 provides a block diagram of a script language virus detection
`apparatus. Id. at col. 4, ll. 11–13. Language definition rules and language
`check rules are defined for respective target script languages and stored in
`rule base 54. Id. at col. 5, ll. 41–44. Such rules are processed by script
`language processor 51 to generate language description data for respective
`target script languages, stored in language description data module 55. Id. at
`col. 5, ll. 44–49. A data stream corresponding to a file to scan is tokenized
`by lexical analysis by feeding the data stream to a lexical analyzer in
`detection engine 53, which generates a stream of tokens. Id. at col. 8, ll. 4–
`7. The data stream is analyzed using the language check data to select the
`language definition data, and the selected language definition data and the
`data stream are supplied to the lexical analyzer, the process generating
`14
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`tokens that correspond to a specific language construct. Id. at col. 8, ll. 7–
`17.
`
`Kolawa “relates to a method and system for automatically checking
`computer source code quality.” Ex. 1004, col. 1, ll. 19–20. Source code is
`read as input to a lexical parser, described as “conventional in the art,” that
`scans the source code and groups the instructions into tokens, enabling a
`hierarchical analysis that groups the tokens into grammatical phrases
`represented by a parse tree. Id. at col. 3, l. 66–col. 4, l. 4.
`Petitioner contends that all limitations of independent claim 1, as well
`as similar limitations of independent claims 9, 22, 23, 29, and 35, are
`disclosed by Chandnani, relying on teachings from Kolawa for “dynamically
`building . . . a parse tree whose nodes represent tokens and patterns in
`accordance with the parser rules” and “dynamically detecting . . .
`combinations of nodes in the parse tree which are indicators of potential
`exploits, based on the analyzer rules.” Pet. 2001, 20–60. Petitioner further
`contends that the limitations of dependent claims 3–5, 12–16, 18, and 19 are
`suggested by the combination of Chandnani and Kolawa. Pet. 157, 45–52.
`
`Petitioner asserts that Chandnani and Kolawa are analogous art
`because both are “directed to scanning and analyzing programming code and
`to scanning for potential exploits and/or other security concerns.” Pet. 2001,
`18. Petitioner reasons that one of ordinary skill in the art would combine
`their teachings for multiple reasons that include common overall objectives
`of the references and “tradition” in the “software security community.” Id.
`at 19 (citing Ex. 1002 ¶¶ 112–23). We are persuaded that Petitioner has
`made a sufficient showing at this stage of a rationale to combine these
`
`15
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`references. Although Patent Owner challenges Petitioner’s analysis as
`insufficiently addressing evidence developed in related litigation, Patent
`Owner will have an opportunity to develop that response during trial. See
`Prelim. Resp. 2001, 36–38.
`We have reviewed Petitioner’s analysis and conclude that it
`demonstrates a reasonable likelihood of prevailing on its challenges to these
`claims over Chandnani and Kolawa. Below, we highlight and address
`specific arguments for emphasis.
`We also note that we are not persuaded by Patent Owner’s contention
`that the Petition is “defective on its face,” for example, by making
`“inadequate conclusory statements” regarding the references and relying on
`“impermissible incorporation by reference.” See id. at 12–18. Although
`Petitioner relies on the declaration of its witness, we do not find in this
`instance that the Petition is so lacking in analysis that the citations to that
`declaration are a substitute for analysis presented within the Petition itself.
`We, therefore, address Petitioner’s arguments and Patent Owner’s responses.
`First, the parties disagree whether Chandnani discloses receipt of an
`incoming stream of computer code that is scanned in accordance with the
`claim limitations. Chandnani states:
`This disclosure provides tools (in the form of apparatus,
`systems and methods) for detecting script language viruses by
`performing a lexical analysis of a data stream on a computing
`device/system. The data stream may be generated from a
`potentially infected file (“subject file”). The subject file may be
`stored on a storage medium, such as a hard disk or floppy disk,
`or received via a network, such as the Internet, or a wired or
`wireless transmission medium, such as telephone landlines or RF
`airwaves.
`
`16
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`
`
`Ex. 1003, col. 4, ll. 32–40 (emphases added). Petitioner identifies
`Chandnani’s receipt via a network as corresponding to receipt of a stream of
`program code. Pet. 2001, 20. Patent Owner counters that the disclosure
`reproduced above “makes it clear that this data stream is generated from a
`potentially infected file already located on the computer,” arguing that “the
`data stream itself is never received, as required by each of the independent
`challenged claims.” Prelim. Resp. 2001, 21–22. We are not persuaded by
`Patent Owner’s inference because Chandnani does not dissociate receipt of
`the subject file from scanning.
`This is relevant also to Patent Owner’s arguments that Chandnani
`does not disclose “dynamically building, by the computer while said
`receiver receives the incoming stream, a parse tree whose nodes represent
`tokens and patterns in accordance with the parser rules” (emphasis added)
`and “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” (emphasis
`added), as recited in each of the independent claims. See id. at 23–30.
`Petitioner contends that Chandnani discloses dynamic building because its
`scanner generates tokens while it receives the incoming data stream,
`identifying an exemplary parsing process that checks for a match against a
`state transition table to output a token before moving on to the next character
`in the stream. Pet. 2001 at 30 (citing Ex. 1003, col. 6, ll. 10–23, col. 8, ll.
`17–31). Chandnani thus uses current hierarchical data in building the parse
`tree and in detecting node combinations. See Ex. 1003, col. 8, ll. 18–24
`(“The lexical analyzer . . . retrieves the next character from the data stream
`17
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`and checks if the character matches any of the entries . . . . If there is a
`match, the lexical analyzer moves to the next state of the matched transition
`entry.”). Petitioner specifically contends that Chandnani discloses dynamic
`detection because its tokenizer and analyzer operate “continuously and
`simultaneously” on the incoming data stream, supporting its position with
`testimony by Dr. Rubin. Pet. 2001, 33–34 (citing Ex. 1003, col. 8, ll. 50–52,
`col. 9, ll. 12–16; Ex. 1002 ¶¶ 183–85). Patent Owner’s counterargument
`relies on its position that Chandnani fails to disclose receipt of an incoming
`stream that is scanned, a position that we reject based on the record currently
`before us. See Prelim. Resp. 2001, 23–30.
`We conclude that Petitioner has made an adequate showing with
`respect to these elements.
`Second, although we reject Petitioner’s construction related to
`limitations requiring instantiating a scanner for the specific programming
`language, we are persuaded that Petitioner identifies sufficient disclosure in
`Chandnani even under the construction we adopt for this Decision.
`Specifically, Petitioner observes that Chandnani discloses a “lexical
`analyzer” as part of the “detection engine” shown in Figure 2, and that the
`detection engine uses “language check data” to determine the script
`language used in the data stream so that language definition data may be
`selected for use in the detection process. Pet. 2001, 21 (citing Ex. 1003, Fig.
`2, col. 8, ll. 4–17; Ex. 1002 ¶¶ 128–30). Chandnani discloses:
`The data stream corresponding to a file to scan is
`tokenized by lexical analysis. The data stream is fed to a lexical
`analyzer (not shown) in the detection engine which generates a
`stream of tokens. To tokenize the data stream, a script language
`used in the data stream is determined by using the language
`18
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`
`check data. The data stream is analyzed using the language
`check data to select the language definition data to use for the
`detection process. Next, the language definition data and the data
`stream are supplied to the lexical analyzer. The data stream is
`lexically analyzed again, this time using the language definition
`data, to generate a stream of tokens. As mentioned above, each
`generated token corresponds to a specific language construct,
`and may be a corresponding unique number or character.
`
`Ex. 1003, col. 8, ll. 4–17.
`Although Patent Owner correctly observes that Petitioner’s specific
`argument refers to a construction we have rejected, Patent Owner does not
`provide a persuasive explanation why the identified disclosure does not
`nevertheless teach the relevant limitations. Chandnani’s teaching of
`supplying language definition data to the lexical analyzer, determined from
`an analysis using language check data, describes “substituting specific data,
`instructions, or both into a generic program unit to make it usable for
`scanning the specific programming language” under the construction we
`adopt for this Decision.
`Accordingly, we conclude that Petitioner has made a sufficient
`showing at this stage.
`Third, the parties disagree whether the combination of Chandnani and
`Kolawa suggests building a “parse tree” having the logical structure required
`by the claims, with Petitioner relying on Kolawa’s express disclosure of
`using a parse tree to analyze code. Pet. 2001, 26 (citing Ex. 1004, col. 3, l.
`66–col. 4, l. 4, Fig. 1). Kolawa discloses:
`The source code 10 is read as input to a lexical
`analyzer/parser 11 which is conventional in the art. The lexical
`analyzer scans the source code 10 and groups the instructions
`
`19
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`
`into tokens. The parser performs a hierarchical analysis which
`groups the tokens into grammatical phrases that are represented
`by a parse tree 12.
`
`Ex. 1004, col. 3, l. 66–col. 4, l. 4.
`Petitioner presents multiple rationales for combining Kolawa’s
`disclosure of building a parse tree with the teachings of Chandnani,
`including the existence of a teaching, suggestion, or motivation in the prior
`art, the use of a known technique to improve similar methods in the same
`way, and an “obvious to try” rationale of choosing from a finite number of
`known solutions with a reasonable expectation of success. Pet. 2001, 26–30.
`Petitioner supports its analysis with testimony by Dr. Rubin. See Ex. 1002
`¶¶ 150–158.
`Patent Owner attacks one specific aspect of Petitioner’s analysis,
`namely, Petitioner’s implication that Kolawa teaches storing tokens in a
`parse tree (“[a]ssuming those tokens are stored in a parse tree, as explicitly
`taught by Kolawa, the combination of Chandnani and Kolawa teaches the
`complete limitation” (Pet. 2001, 31)). Prelim. Resp. 2001, 25–27. Patent
`Owner contends that the tokens of Kolawa “are not stored in a parse tree as
`required under Petitioner’s theory.” Id. at 26. On the record before us, we
`are not persuaded that Patent Owner adequately rebuts Petitioner’s analysis.
`Patent Owner focuses too narrowly on a single aspect of a more
`comprehensive analysis, notably, an aspect divorced from the specific claim
`language, which does not require storage of tokens in a parse tree.
`We conclude that Petitioner has demonstrated a reasonable likelihood
`of prevailing on its challenge of claims 1, 3–5, 9, 12–16, 18, 19, 22, 23, 29,
`
`20
`
`
`
`IPR2015-02001, IPR2016-00157
`Patent 8,225,408 B2
`
`and 35 as unpatentable under 35 U.S.C. § 103(a) over Chandnani and
`Kolawa.
`
`
`C. Obviousness over Chandnani, Kolawa, and Walls
`Petitioner challenges claims 1, 3–5, 9, 12–16, 18, 19, 22, 23, 29, and
`35 as unpatentable under 35 U.S.C. § 103(a) over Chandnani, Kolawa, and
`Walls, addressing the challenged independent claims in IPR2015-02001 and
`the challenged dependent claims in IPR2016-00157. Pet. 2001, 56–