Case 5:17-cv-04467-BLF Document 112-17 Filed 01/31/19 Page 1 of 8
`Case 5:17-cv-04467-BLF Document 112-17 Filed 01/31/19 Page 1 of 8
`
`EXHIBIT 16
`
`
`
`
`
`EXHIBIT 16
`
`
`
`
`
`
`
`
`

`

`Case 5:17-cv-04467-BLF Document 112-17 Filed 01/31/19 Page 2 of 8
`Case 5:17-cv-04467-BLF Document 112-17 Filed 01/31/19 Page 2 of 8
`
`REMARKS
`
`Applicants have carefully studied the outstanding Office Action. The
`
`present amendment is intended to place the application in condition for allowance and is
`
`believed to overcome all of the objections and rejections made by the Examiner. Favorable
`
`reconsideration and allowance of the application are respectfully requested.
`
`Applicants have amended claims l, 13 and 25 to properly claim the
`
`present invention. No new matter has been added. Claims 1 — 25 are presented for
`
`examination.
`
`Elm
`
`0n pages 2 and 3 of the Office Action, the Examiner has objected to
`
`the specification as failing to provide proper antecedent basis for the claimed subject matter.
`
`Specifically, the Examiner has indicated that there is no support for ‘jottttems ofppes of
`
`tokens".
`
`Applicants note that the appendix to the specification discloses that
`
`tokens are characterized into types. Thus, as defined on page 46,
`
`IDENT
`
`“[A-Za-z[!underscore!][!dollarsign!]][A-Za—zO-
`
`9[!undcrscore!][!dollarsign!]]*",
`
`a token consisting of a character a-z or a character A-Z or an underscore or a dollar sign,
`
`followed by zero or more of a character a—z or a character A—Z or a number 0 — 9 or an
`
`underscore or a dollar sign, is of type IDENT. Similarly, as defined on page 47,
`
`INTEGER_DECIMAL
`
`“[0-9]+”,
`
`a token consisting of one or more of the numbers 0 — 9, is of type INTEGER_DECIMAL;
`
`and
`
`INTEGER_HEX
`
`“0[xX][0—9A—Fa—f]+”,
`
`a token consisting of 0x or UK followed by one or more of the numbers 0 - 9 or the characters
`
`A-F or the characters a-f, is of type INTEGER_HEX.
`
`Applicants respectfully submit that patterns of types of tokens appear
`
`throughout the specification. Inter alia, at par. [0067], the specification recites
`
`A parse tree
`
`uses parsing rules to identify groups of tokens as a single pattern.
`
`Atty. Docket No. FINOOOl—CONl—CIP3—CIP1
`
`—6—
`
`

`

`Case 5:17-cv-04467-BLF Document 112-17 Filed 01/31/19 Page 3 of 8
`Case 5:17-cv-04467-BLF Document 112-17 Filed 01/31/19 Page 3 of 8
`
`Further, at par. [0085], the specification recites
`
`For example, if a pattern “(1DENT) EQUALS NU MBER” is matched
`
`ifa matched
`
`pattern is “(I 2 3) 4 5"
`
`Further, at par. [0086], the specification recites
`
`Reference is now made to FIG. 5, which is an illustration ofa simple finite state machine
`
`... for a pattern
`
`(IDENT) <val="foo" & match(*):Rulel> I <val="bar"> EQUALS NUMBER
`
`Specifically, the pattern of interest specifies either an IDENT token with value “foo” and
`
`that matches RuleI, or a List with value “bar", followed by an EQUALS token and a
`
`NUMBER token.
`
`Further, at par. [0094] the specification recites
`
`For example, the pattern in the rule for FuncSig
`
`(FUNCTION) (IDENT?) (List)
`
`describes a keyword “function”, followed by zero or one IDENT tokens, and followed by
`
`a “List”. In turn, the pattern in the rule for List
`
`(LPAREN) ((Expr (COM MA Expr)*)? (RPAREN)
`
`describes an LPAREN token and an RPAREN token surrounding a list of zero or more
`
`Expr’s separated by COMMA tokens.
`
`Further, at par. [0098], the specification recites
`
`Referring back to the example above, the pattern
`
`(IDENT) ASSIGNMENT IDENT <val="screen”> DOT IDENT <val="width">
`
`within the rule for SchidAssign describes a five-token pattern; namely (i) an IDENT
`
`token, followed by (ii) an ASSIGNMENT token, followed by (iii) an IDENT token that
`
`has a value equal to “screen”, followed by (iv) a DOT token, followed by (v) an IDENT
`
`token that has a value equal to “width". Such a pattern
`
`corresponds to the example
`
`exploit listed above
`
`Clearly items (i) — (v) above form a pattern of token types IDENT ASSIGNMENT IDENT
`
`DOT IDENT.
`
`On page 3 of the Office Action, the Examiner has indicated that
`
`parsing rules for parsing of data into tokens, and analysis rules for analyzing the meaning of
`
`patterns of tokens are known concepts. Applicants respectfully submit that a point of novelty
`
`Atty. Docket No. FINOOOl—CONl—CIP3—CIP1
`
`—7—
`
`

`

`Case 5:17-cv-04467-BLF Document 112-17 Filed 01/31/19 Page 4 of 8
`Case 5:17-cv-04467-BLF Document 112-17 Filed 01/31/19 Page 4 of 8
`
`
`of the claimed invention is describing and recognizing computer exploits from patterns of
`
`types of tokens, which is not a known concept.
`
`Claim Re'ections — 35 USC 112
`
`On pages 3 and 4 of the Office Action, the Examiner has rejected
`
`claims I — 25 under 35 U.S.C. §1 12, first paragraph, as failing to comply with the written
`
`description requirement. Applicants respectfully submit that the amended claims are
`
`supported in the original specification, as indicated above.
`
`On pages 4 and 5 of the Office Action, the Examiner has rejected
`
`claims I — 25 under 35 U.S.C. §l l2, second paragraph, as being indefinite. Moreover, the
`
`Examiner has indicated that applicants point only to portions of the specification that
`
`describe what is standard and known prior art teaching for parsing and analyzing languages
`
`according to parsing rules and analyzing rules. Applications respectfully submit that the
`
`specification teaches recognition and detection of computer exploits from patterns of types of
`
`tokens, which is not standard and known prior art.
`
`Claims Re'ections — 35 USC
`
`102 and 103
`
`On pages 5 — "i of the Office Action, the Examiner has rejected claims
`
`1, 2, 5, 6, 8 — l3, [7, 18 and 20 — 25 under 35 U.S.C. §l02(e) as being anticipated by Freund,
`
`US. Patent No. 5,987,61 l (“Freund”).
`
`0n pages ”i and 8 of the Office Action, the Examiner has rejected
`
`claims 3, 4, 7, l4 — 16 and 19 under 35 U.S.C. §103(a) as being unpatentable over Freund.
`
`The rejections of claims I — 25 on pages 5 - 8 of the Office Action will
`
`now be dealt with specifically.
`
`As to amended independent claim I for a security system, applicant
`
`respectfully submits that the limitations in claim 1 of
`
`“a database of parser and anabrzer rules corresponding to computer
`
`expioits, stored within the computer, computer exploits being portions ofprogram code that
`
`are malicious, wherein the parser and anaiyzer ruies describe computer expioits as patterns
`
`of types of tokens, tokens being program code constructs, and tJ-pes oftokens comprising a
`
`punctuation type, an identifier type and afunction type”, and
`
`Atty. Docket No. FINOODl—CONl—CIP3—CIP1
`
`—8—
`
`

`

`Case 5:17-cv-04467-BLF Document 112-17 Filed 01/31/19 Page 5 of 8
`Case 5:17-cv-04467-BLF Document 112-17 Filed 01/31/19 Page 5 of 8
`
`“a network trafi‘ic probe, operativeiy coupled to said network interface
`
`and to said mie—based content scanner, for seiectiveiy diverting incoming content from its
`
`intended destination to said rule-based content scanner”
`
`are neither shown nor suggested in Freund.
`
`On page 9 of the Office Action, the Examiner has indicated that
`
`Freund teaches parsing data into recognizable tokens, wherein the tokens are not the same
`
`tokens and are distinct from one another. The Examiner is citing “tokens" in rejecting the
`
`claim limitations of “patterns ofp'pes of tokens”. Applicants wish to point Out that the
`
`phrases “tokens" and “patterns of types of tokens" have different meanings. In particular, as
`
`used in the subject specification, “types of tokens” refers to a categorization of tokens into
`
`types. A “type" is a category. For example, the constructs APPLET, OBJECT, EMBED,
`
`SCRIPT, HREF and IMAGE are distinct tokens; yet they are all of the same type lDENT.
`
`Similarly, the constructs 0x01, 0XC33, OxGB and 0X24AD3 are distinct tokens; yet they are
`
`all of the same type INTEGER_HEX.
`
`Types of tokens disclosed in the subject specification include inter alia
`
`identifier tokens (say, type TYPEI), assignment tokens (say, type TYPEZ), and punctuation
`
`tokens (say, type TYPEB). A pattern of types of tokens is, e.g., a pattern TYPEI TYPE2
`
`TYPEl TYPE3 TYPEI; meaning, a token of type TYPE] followed by a token of type
`
`TYPE2 followed by a token oftype TYPE] followed by a token of type TYPE3 followed by
`
`a token of type TYPE]; e.g., an identifier token followed by an assignment token followed
`
`by an identifier token followed by a punctuation token followed by an identifier token.
`
`On page 9 of the Office Action, the Examiner has indicated that
`
`applicants fail to specifically explain how the recited language “patterns offline? oftokens"
`
`distinguishes from the prior art. Applicants respectfully submit that the prior art does not
`
`relate to categorization of tokens into types, i.e., categories of tokens, and to description of
`
`computer exploits in terms of such categories. Moreover, the Examiner‘s citations, e.g.,
`
`Freund 23:44—55, 28:14—16 and 29:54 — 30:9 do not relate to patterns of types oftokens.
`
`Indeed, Freund 23:44-55 concerns types of Internet protocols, and not types of tokens.
`
`(An
`
`Internet protocol is not a token.) Freund 28:14 — [6 relates to filtering of rules. Freund 29:54
`
`— 30:9 relates to specific tags (<APPLET}, <OBJECT>, éEMBED}, <SCRIPT}, <HREF>
`
`and <IMAGE>) and other “syntax elements” and “HTML components”. Applicants
`
`respectfully submit that tags, other syntax elements and HTML components may correspond
`
`to tokens, but they do not correspond to “patterns oftjpes".
`
`Atty. Docket No. FINOOOl—CONl—CIP3—CIP1
`
`—9—
`
`

`

`Case 5:17-cv-04467-BLF Document 112-17 Filed 01/31/19 Page 6 of 8
`Case 5:17-cv-04467-BLF Document 112-17 Filed 01/31/19 Page 6 of 8
`
`Therefore, Freund does not teach categorization of tokens into types,
`
`nor description of computer exploits in terms of patterns of types of tokens.
`
`In order to further clarify this distinction, applicants have amended
`
`claim 1 to include the limitation that types of tokens comprise a punctuation type, an
`
`identifier type and a function type.
`
`In rejecting claim 1 on page 6 of the Office Action, the Examiner,
`
`referring to Freund, FIG. 3Az3l 1, has indicated the Freund discloses a network traffic probe
`
`that selectively diverts incoming content from its intended destination to a rule-based content
`
`scanner. Applicants respectfully submit that elements 3 I la, 31 lb and 31 1c of Freund, FIG.
`
`3A, are client-side monitors for monitoring Internet access (Freund l4:59-62), which do not
`
`divert incoming content to a content scanner. Indeed, Freu nd’s client—side monitors limit
`
`Internet access; they do not divert incoming content to a content scanner.
`
`In rejecting claim 2 on page 6 of the Office Action, the Examiner has
`
`cited Freund 29:54 — 30:10 as disclosing that the rules enable the driver or parser to operate
`
`according to a partiCular manner. Applicants respectfully submit that Freund does not
`
`disclose storing parser and analyzer rules in the form of pattern—matching engines, and that
`
`rules that operate according to a particular manner does not anticipate or render obvious m
`
`stored in the form of pattern—matching engines. Examples of rules in the form of pattern
`
`matching engines are provided on pages 47 — 51 in the appendix of the original specification,
`
`and storing rules in the form of pattern matching engines is discussed at paragraphs [00?]] —
`
`[0078] of the original specification with reference to FIGS. 4A and 43.
`
`Because claims 3 — 12 depend from claim 1 and include additional
`
`features, applicants respectfully submit that claims 2 — 12 are not anticipated or rendered
`
`obvious by Freund.
`
`Accordingly claims 1 — 12 are deemed to be allowable.
`
`As to amended independent method claim 13 and amended
`
`independent claim 25 for a computer—readable storage medium, applicants respectfully
`
`submit that the limitations in claims 13 and 25 of
`
`“setectivek diverting the received incoming contentfrom its intended
`
`destination”, and
`
`"scanning the selective!) diverted incoming content to recognize
`
`potentiai computer exploits therewithin, based on a database ofparser and rtnaitizer rates
`
`corresponding to computer expioits, computer expioits being portions ofprogram code that
`
`Atty. Docket No. FINOOOl—CONl—CIP3—CIP1
`
`—10—
`
`

`

`Case 5:17-cv-04467-BLF Document 112-17 Filed 01/31/19 Page 7 of 8
`Case 5:17-cv-04467-BLF Document 112-17 Filed 01/31/19 Page 7 of 8
`
`are malicious, wherein the parser and anoiyzer rules describe computer exploits as patterns
`
`ofgzpes oftokens. tokens being program code constructs, and types ofiokens comprising a
`
`punctuation ope, an identifier type and afiinction pipe”
`
`are neither shown nor suggested in Freund.
`
`In rejecting claims 13 and 25 on page 7 of the Office Action, the
`
`Examiner has referenced his rejection of claim 1, which cited Freund. As explained above,
`
`the claimed invention includes the limitation of patterns of types of tokens, which is not
`
`disclosed in Freund. The claimed invention also includes the limitation of selectively
`
`diverting incoming content, which is not disclosed in Freund.
`
`Because claims 14 — 24 depend from claim 13 and include additional
`
`features, applicants respectfully submit that claims 14 — 24 are not anticipated or rendered
`
`obvious by Freund.
`
`Accordingly claims 13 — 25 are deemed to be allowable.
`
`Support for Amended Claims in Original Specification
`
`Independent claims 1, 13 and 25 have been amended to include the
`
`limitation that types of tokens include at least (i) a punctuation type, (ii) an identifier type
`
`and (iii) a function type. This limitation is supported in the original specification at least (i)
`
`by the various punctuation types of tokens defined on pages 46 and 4? (LBRAC E, RBRACE,
`
`etc), (ii) by the IDENT type of token defined on page 46, and (iii) by the FUNCTION type
`
`of token appearing on pages 29, 47 ad 48.
`
`Atty. Docket No. FINOOOl—CONl—CIP3—CIP1
`
`—11—
`
`

`

`Case 5:17-cv-04467-BLF Document 112-17 Filed 01/31/19 Page 8 of 8
`Case 5:17-cv-04467-BLF Document 112-17 Filed 01/31/19 Page 8 of 8
`
`M
`
`For the foregoing reasons, applicants respectfully submit that the
`
`applicable objections and rejections have been overcome and that the claims are in condition
`
`for allowance. The undersigned looks forward to discussing the response with the Examiner
`
`on October 28, 2010 at l 1 AM. If any additional fees are required in connection with the
`
`filing of this response, the Commissioner is hereby authorized to charge the same to Deposit
`
`Account 50—4402.
`
`Date: September 15, 2010
`
`By:
`
`
`/Dawn—Marfe Ber — 44 442/
`
`Respectfully submitted,
`
`King & Spalding LLP
`1700 Pennsylvania Avenue
`Suite 200
`
`Washington DC 20006
`(202) 626-8978
`
`Dawn-Marie Bey
`Registration No. 44,442
`
`Atty. Docket No. FINOOOl—CONl—CIP3—CIP1
`
`—12—
`
`