throbber
Trials@uspto.gov
`571-272-7822
`
`
`
`
`
`Paper 10
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket