`
`___________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`___________________
`
`SYMANTEC CORPORATION
`Petitioner
`
`v.
`
`THE TRUSTEES OF COLUMBIA UNIVERSITY
`IN THE CITY OF NEW YORK
`Patent Owner
`___________________
`
`CASE IPR2015-00375
`Patent 8,074,115
`___________________
`
`COLUMBIA’S PATENT OWNER RESPONSE
`UNDER 37 C.F.R. § 42.108
`
`Mail Stop “PATENT BOARD”
`Patent Trial and Appeal Board
`U.S. Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`3471556
`
`Columbia Exhibit 2058-1
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`
`TABLE OF CONTENTS
`
`I.
`
`II.
`
`III.
`
`IV.
`
`Introduction......................................................................................................1
`
`The Invention Of The ’115 Patent...................................................................2
`
`Level Of Ordinary Skill In The Art.................................................................4
`
`The Prior Art....................................................................................................6
`
`A.
`
`U.S. Patent Publication No. 2005/0108562 (“Khazan”).......................6
`
`1.
`
`2.
`
`3.
`
`Khazan Describes A Simple List Of Function Calls ..................7
`
`Khazan Only Tracks Win32 DLL Function Calls That
`Are Capable Of Being Made.......................................................7
`
`Khazan Identifies A Program As Malicious Code With
`Absolute Certainty ......................................................................8
`
`B.
`
`C.
`
`U.S. Patent No. 8,108,929 (“Arnold”) ..................................................8
`
`U.S. Patent No. 5,440,723 (“Agrawal”)................................................9
`
`V.
`
`Ground 1: Khazan Does Not Anticipate Claims 22, 25, 27-29, 32,
`35-39 or 42.....................................................................................................10
`
`A.
`
`B.
`
`C.
`
`D.
`
`E.
`
`Khazan Does Not Disclose “Modifying A Program To Include
`Indicators Of Program-Level Function Calls”....................................10
`
`Khazan Does Not Disclose “Identifying A Function Call As
`Anomalous”.........................................................................................14
`
`1.
`
`2.
`
`Khazan Does Not Disclose “Deviation From A Model
`of Typical Computer System Usage” .......................................14
`
`Khazan Does Not Identify “Deviation From A Model”...........16
`
`Khazan Does Not Disclose an “Emulator” .........................................18
`
`Khazan Does Not Disclose “The Model Reflects Normal
`Activity” ..............................................................................................20
`
`Khazan Does Not Disclose “The Model Reflects Attacks”................22
`
`3471556
`
`- i -
`
`Columbia Exhibit 2058-2
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`F.
`Khazan Does Not Disclose A “Model Of Function Calls”.................23
`
`1.
`
`2.
`
`“Model Of Function Calls” Requires The Model To Be
`Created Using A Learning Algorithm ......................................23
`
`Under Patent Owner’s Construction, Khazan Does Not
`Disclose A “Model Of Function Calls” ....................................27
`
`VI. Ground 2: Claims 1, 4-8, 11, 14-18, 21, Or 26 Are Not Obvious
`Under The Combination Of Khazan And Arnold .........................................30
`
`A.
`
`B.
`
`C.
`
`The Combination Of Khazan And Arnold Does Not Disclose
`An “Application Community” ............................................................30
`
`The Combination Of Khazan And Arnold Does Not Disclose,
`“Upon Identifying The Anomalous Function Call,” Notifying
`Any Computer “Of The Anomalous Function Call” ..........................33
`
`Khazan And Arnold May Not Be Combined To Render The
`Claims Obvious ...................................................................................35
`
`VII. Ground 3: Claims 2-3, 9-10, 12-13, 19-20, 23-24, 30-31, 33-34, Or
`40-41 Are Not Obvious Under The Combination Of Khazan, Arnold,
`And Agrawal..................................................................................................40
`
`A.
`
`B.
`
`C.
`
`D.
`
`The Combination Of Khazan, Arnold, And Agrawal Does Not
`Disclose “Randomly Selecting The Model As To Be Used In
`The Comparison From A Plurality Of Different Models
`Relating To The Program” ..................................................................40
`
`The Combination Of Khazan, Arnold, And Agrawal Does Not
`Disclose “Randomly Selecting A Portion Of The Model To
`Be Used In The Comparison” .............................................................45
`
`The Combination Of Khazan, Arnold, And Agrawal Does Not
`Disclose “Creating A Combined Model”............................................46
`
`The Combination Of Khazan, Arnold, And Agrawal Does Not
`Disclose “Creating A Combined Model From At Least Two
`Models Created Using Different Computers”.....................................48
`
`1.
`
`Agrawal Does Not Disclose The Limitation.............................48
`
`3471556
`
`- ii -
`
`Columbia Exhibit 2058-3
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`2.
`
`A Combination Of Khazan, Arnold, and Agrawal
`Would Not Include The Limitation ..........................................50
`
`E.
`
`The Combination Of Khazan, Arnold, And Agrawal Does Not
`Disclose “Creating A Combined Model From At Least Two
`Models Created At Different Times”..................................................52
`
`1.
`
`2.
`
`Agrawal Does Not Disclose The Limitation.............................52
`
`A Combination Of Khazan, Arnold, And Agrawal And
`Arnold Would Not Include The Limitation..............................55
`
`F.
`
`Khazan, Arnold, and Agrawal May Not Be Combined to
`Render the Challenged Claims Obvious .............................................56
`
`3471556
`
`- iii -
`
`Columbia Exhibit 2058-4
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`
`TABLE OF AUTHORITIES
`
`Cases
`Amgen Inc. v. F. Hoffman-La Roche Ltd.,
`580 F.3d 1340 (Fed. Cir. 2009) .....................................................................57
`
`Bates v. Coe,
`98 U.S. 31 (1878)...........................................................................................28
`
`Daiichi Sankyo Co. v. Apotex, Inc.,
`501 F.3d 1254 (Fed. Cir. 2007) .......................................................................4
`
`Endo Pharms., Inc. v. Depomed, Inc.,
`IPR2014-00656, Paper 66 (PTAB Sept. 21, 2015) .......................................57
`
`In re Am. Acad. Of Sci. Tech Ctr.,
`367 F.3d 1359 (Fed. Cir. 2004) .....................................................................26
`
`In re Cuozzo Speed Techs., LLC,
`793 F.3d 1268 (Fed. Cir. 2015) .....................................................................26
`
`In re Omeprazole Patent Litig.,
`536 F.3d 1361 (Fed. Cir. 2008) .............................................................. 22, 50
`
`In re Robertson,
`169 F.3d 743 (Fed. Cir. 1999) ......................................................................23
`
`In re Suitco Surface, Inc.,
`603 F.3d 1255 (Fed. Cir. 2010) .....................................................................27
`
`InTouch Techs., Inc. v. VGO Communs., Inc.,
`751 F.3d 1327 (Fed. Cir. 2014) .....................................................................36
`
`KSR Int'l Co. v. Teleflex Inc.,
`550 U.S. 398 (2007).......................................................................................35
`
`Microsoft Corp. v. Proxyconn, Inc.,
`789 F.3d 1292 (Fed. Cir. 2015) .....................................................................26
`
`NetMoneyIN, Inc. v. VeriSign, Inc.,
`545 F.3d 1359 (Fed. Cir. 2008) ....................................................................20
`
`3471556
`
`- iv -
`
`Columbia Exhibit 2058-5
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`PAR Pharm., Inc. v. TWI Pharm., Inc.,
`773 F.3d 1186 (Fed. Cir. 2014) ........................................................ 48, 49, 60
`
`PharmaStem Therapeutics, Inc. v. ViaCell, Inc.,
`491 F.3d 1342 (Fed. Cir. 2007) .....................................................................36
`
`Phillips v. AWH Corp.,
`415 F.3d 1303 (Fed. Cir. 2005) .....................................................................25
`
`Rhone-Poulenc Agro, S.A. v. DeKalb Genetics Corp.,
`272 F.3d 1335 (Fed. Cir. 2001) .....................................................................58
`
`Unigene Labs., Inc. v. Apotex, Inc.,
`655 F.3d 1352 (Fed. Cir. 2011) ....................................................................57
`
`Other Authorities
`
`MPEP § 2143 ...........................................................................................................50
`
`3471556
`
`- v -
`
`Columbia Exhibit 2058-6
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`I.
`Introduction
`
`The challenged ’115 patent is about protecting computer systems from faults
`
`and attacks. The ’115 patent describes using an emulator to monitor the function
`
`calls made by a running program. The program’s function calls are compared to a
`
`sophisticated model of function calls. The model contains insights about the
`
`program’s expected behavior that have been learned by training on a large amount of
`
`data and distilling common features from the data. If a new function call deviates far
`
`enough from the statistical baseline of normal behavior found in the model, the
`
`function call may be labeled anomalous. Neighboring computers that are running
`
`the same application—an “application community”—may be notified of the
`
`anomalous function call. The application community also assists in developing
`
`multiple models. These models may be shared and combined throughout the
`
`community to develop better protections against faults and attacks.
`
`Petitioner’s challenge to the ’115 patent rests on one primary reference,
`
`Khazan. But Khazan is a rudimentary approach to computer security that takes a
`
`starkly different approach than the ’115 patent. Khazan uses a simple,
`
`quickly-compiled list of a subset of the external library functions that may be called
`
`by an application. If the runtime calls to external libraries do not exactly match the
`
`entries in the list, then the application is declared to be MC—malicious code—with
`
`100% certainty. Because Khazan’s list only records the function calls that the
`
`3471556
`
`- 1 -
`
`Columbia Exhibit 2058-7
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`application is capable of making, it does not have insight into which functions are
`
`actually called in normal usage. Therefore, Khazan does not disclose several critical
`
`elements of the ’115 patent. To remedy some admitted deficiencies, Petitioner turns
`
`to two other references, Arnold and Agrawal. However, neither reference discloses
`
`the elements for which they are cited, and neither may be appropriately combined
`
`with Khazan. All claims of the ’115 patent remain novel and nonobvious. None
`
`should be canceled in this trial.
`
`II.
`
`The Invention Of The ’115 Patent
`
`The ’115 patent, entitled “Methods, Media and Systems for Detecting
`
`Anomalous Program Executions,” resulted from the joint efforts of Professors
`
`Salvatore Stolfo and Angelos Keromytis at Columbia University’s Intrusion
`
`Detection Systems Laboratory and Network Security Laboratory. The patent relates
`
`to improved computer security techniques. Ex. 1001 at 1:18-19. Certain
`
`activity—function calls made by running programs—can be a leading indicator of
`
`intrusions or attacks. Id. at 3:64-4:5 (“[T]he application of an anomaly detector to
`
`function calls can enable rapid detection of malicious program executions, such that
`
`it is possible to mitigate against such faults or attacks . . . .”).
`
`A model of function calls is used to establish a baseline for program behavior
`
`and to detect anomalous program executions. Id. at 3:16-19. The ’115 patent
`
`teaches methods to capture, isolate, and repair the harm caused by those anomalies.
`
`3471556
`
`- 2 -
`
`Columbia Exhibit 2058-8
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`Id. at 3:28-4:5. And it provides techniques for improving overall security by
`
`combining models created on different computers or at different times, and notifying
`
`the application community of specific information regarding anomalous functions.
`
`Id. at 8:9-49, 18:44-62.
`
`The model of function calls is developed using a learning algorithm with a
`
`training phase to develop a statistical profile of function calls. Id. at 3:16-19; 4:6-11;
`
`5:8-21; 7:5-8:8. After the model has been created in a learning phase, the model of
`
`function calls can be applied to inspect running programs to identify anomalous
`
`function calls. Id. at 3:52-56. This second phase is conducted using emulation,
`
`which allows for “enhanced detection of some types of attacks,” as well as
`
`“enhanced reaction mechanisms.” Id. at 9:35-40; 3:37-45; 3:56-62.
`
`Once an anomalous function call is detected on one computer, that computer
`
`can notify an application community of the anomalous function call. Providing
`
`information about the anomalous function call to members of the application
`
`community allows the notified computers to “isolate the portion of the code that
`
`caused the fault.” Id. at 18:44-62. Further, multiple models can be used to make the
`
`system more robust. For example, a model of function call executions can be
`
`combined with other models created at different times or using different computers.
`
`Id. at 8:9-31; 6:31-47 (describing how these combined models allow distribution of
`
`computer workload, and reduce the effects of “concept drift”).
`
`3471556
`
`- 3 -
`
`Columbia Exhibit 2058-9
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`III. Level Of Ordinary Skill In The Art
`
`As explained by Patent Owner’s expert Prof. George Cybenko, a POSITA at
`
`the time of the invention would have at least an undergraduate degree in computer
`
`science or mathematics and one to two years of experience in the field of computer
`
`security. Ex. 2030 at ¶¶ 24-28. Prof. Cybenko’s definition is comparable to that
`
`proposed by Petitioner’s experts in the related district court action. Ex. 2003 at ¶ 94
`
`(defining a POSITA as one with “a Master’s degree in computer science, computer
`
`engineering, or a similar field, or a Bachelor’s degree in computer science, computer
`
`engineering, or a similar field, with approximately two years of industry experience
`
`relating to computer security.”); Ex. 2004 at ¶ 18 (same).
`
`However, Petitioner and its expert argue that a POSITA must have both a
`
`Master’s degree and two to three years of relevant experience. Ex. 1003 at ¶ 20.
`
`Notably, one of the inventors of the ’115 patent, Stelios Sidiroglou (now Stelios
`
`Sidiroglou-Douskos) had not yet received a Master’s degree at the time of the
`
`invention. Ex. 2032 (listing M.Phil. degree received from Columbia University in
`
`2006). Requiring a POSITA to have a Master’s degree in addition to two to three
`
`years of relevant experience would place the level of skill in the art significantly
`
`higher than the educational level of an inventor of the ’115 patent itself. Daiichi
`
`Sankyo Co. v. Apotex, Inc., 501 F.3d 1254, 1256 (Fed. Cir. 2007) (listing “the
`
`educational level of the inventor” as the first factor to consider “in determining level
`
`3471556
`
`- 4 -
`
`Columbia Exhibit 2058-10
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`of ordinary skill in the art”).
`
`Neither the Petition nor its expert provided any rationale for their proposed
`
`elevated level of ordinary skill. However, at deposition, Petitioner’s expert
`
`advanced a new argument that a particular formula in the ’115 patent was the entire
`
`basis for requiring a Master’s degree, and that, apart from that single formula, the
`
`appropriate level of skill was actually that proposed by Patent Owner. Ex. 2029 at
`
`240:12-241:15; 254:16-255:6; 255:15-19 (“[T]he rest of the ’115 patent as well as
`
`the ’322 patent of corresponding parts would only require a Bachelor’s degree in
`
`computer science or an equivalent plus one to two years of experience in computer
`
`security . . . .”). Petitioner’s expert testified that there was a typographical error in
`
`the formula at 4:59-62 in the ’115 patent, and that it would be hard “for an
`
`undergraduate to understand how to correct that formula as well as to even
`
`understand the formula” because the formula was not typically taught to
`
`undergraduate students. Id. at 257:23-258:6. Petitioner’s expert further testified
`
`that a reader would need to look at a prior art paper by Friedman and Singer that had
`
`the correct formula to be able to correct the typo. Id. at 45:17-19 (“So somebody
`
`would need to know that they need to go to Friedman & Singer and find this error
`
`and be able to correct it.”).
`
`This analysis is suspect for a number of reasons. First, it hinges on one
`
`formula that is an aspect of the PAD algorithm, and the PAD algorithm itself (as
`
`3471556
`
`- 5 -
`
`Columbia Exhibit 2058-11
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`opposed to learning algorithms in general) is not a requirement of any claim. See
`
`generally Ex. 1001 at cls. 1-42. Second, immediately following the formula, the
`
`patent notes that the value can be calculated a different way. Id. at 4:66-5:7
`
`(“Because this computation of C can be time consuming, C can also be calculated by
`
`. . . .”). This formula is a sufficient substitute for the one with the error. Ex. 2030 at
`
`¶ 29. Third, the corrected formula is already found in the provisional application.
`
`Ex. 2028 at 31. This was incorporated by reference into the specification. Ex. 1001
`
`at 1:8-14. But Dr. Goodrich did not even read the provisional application. Ex. 2029
`
`at 86:7-8 (“Q Did you read the provisional applications? A Just sitting here today, I
`
`don’t recall.”). Prof. Cybenko also discusses the complexity of the gamma function
`
`and the paper and concludes that both are comprehensible by undergraduates. Ex.
`
`2030 at ¶ 29.
`
`Therefore, Dr. Goodrich’s obviousness analysis should be given little, if any,
`
`weight, because his conclusions apply the wrong standard and require a POSITA to
`
`have an unduly high level of education. Indeed, Dr. Goodrich’s misstep on the level
`
`of ordinary skill indicates his opinion should receive close scrutiny.
`
`IV. The Prior Art
`
`A.
`
`U.S. Patent Publication No. 2005/0108562 (“Khazan”)
`
`Khazan describes a way to detect malicious code in a software program by a
`
`two-step process: first static analysis and then dynamic analysis. Ex. 1010 at
`
`3471556
`
`- 6 -
`
`Columbia Exhibit 2058-12
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`Abstract. Before the program is executed, the static analysis step identifies the
`
`instructions that call into well-known Win32 APIs and saves their target and
`
`invocation locations in a list. Id. at Abstract; ¶¶ 42, 45, 47, 48, 99; Figs. 4A, 12-14.
`
`When the program is executed, the dynamic analysis step examines the Win32 API
`
`calls that are made and validates the call against the list that was generated during
`
`the preprocessing static analysis step. Id. at Abstract; ¶¶ 78, 80, 82-83, 94, 99; Figs.
`
`4B, 6, 7, 9. If a mismatch occurs, the system blocks the API call. Id. at ¶¶ 85, 94, 99.
`
`Ex. 2030 at ¶¶ 48-50.
`
`1.
`
`Khazan Describes A Simple List Of Function Calls
`
`Khazan uses “static analysis of a binary form of the application” to build what
`
`it terms a “model.” Khazan at Abstract. Khazan’s “model” is “comprised of a list of
`
`calls to targets, their invocation and target locations, and possibly other call-related
`
`information.” Ex. 1010 at Abstract; Ex. 2030 at ¶¶ 41-45. As described in Fig. 4A,
`
`the “model” (i.e. objects labeled 106 or 112 in Fig. 4A) is simply a “list of target and
`
`invocation locations.” Id. at Fig. 4A. Each and every example of a list used by
`
`Khazan is simply a different way of associating targets with invocation locations.
`
`Id. at ¶ 102-04, Figs. 10-12.
`
`2.
`
`Khazan Only Tracks Win32 DLL Function Calls That Are
`Capable Of Being Made
`
`Only “predetermined” functions are analyzed during static analysis and added
`
`to the list. Id. at ¶ 43. In other words, the static analyzer needs to know about the
`
`3471556
`
`- 7 -
`
`Columbia Exhibit 2058-13
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`functions before it is capable of adding them to the list. The predetermined
`
`functions are also a subset of external libraries used by the application—the
`
`well-known Win32 libraries that provide access to operating system functions. Id. at
`
`¶ 42 (“These functions may represent the set of Win32 Application Programming
`
`Interfaces (APIs) as known to those of ordinary skill in the art in connection with the
`
`Windows operating system by Microsoft Corporation.”); Ex. 2031 at ¶ 11; Ex. 2030
`
`at ¶ 52. These predetermined external function calls are simply the calls that the
`
`program is capable of making, as shown by inspecting its executable code. Ex. 1010
`
`at ¶ 48; Ex. 2031 at ¶ 15. Khazan’s static analyzer does not record information about
`
`how the functions are used at runtime. Ex. 1010 at ¶¶ 78, 86 (run time stack used by
`
`dynamic analyzer to compare to the list but not by the static analyzer to build the
`
`list); Ex. 2031 at ¶ 15.
`
`3.
`
`Khazan Identifies A Program As Malicious Code With
`Absolute Certainty
`
`If a program’s function calls do not exactly match the information in the list
`
`that was compiled by the static analyzer, the program is flagged as malicious. Ex.
`
`1010 at ¶¶ 43, 65; Ex. 2031 at ¶ 16. The validation procedure is a simple comparison
`
`of new function calls with what was noted on the static analysis list. Ex. 1010 at ¶¶
`
`67, 85. Khazan does not estimate a probability of maliciousness, or a probability of
`
`anything at all. Ex. 2031 at ¶ 16; Ex. 2030 at ¶ 49.
`
`B.
`
`U.S. Patent No. 8,108,929 (“Arnold”)
`
`3471556
`
`- 8 -
`
`Columbia Exhibit 2058-14
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`Arnold discloses a system for identification of a “virus, worm, or Trojan
`
`Horse, within a data processing system” which may employ anomaly detection. Ex.
`
`1007 at 3:3-6; 4:60-5:26. After the virus or worm is detected, a signature can be
`
`computed automatically if one does not already exist. Id. at 2:6-62; 3:6-12; 5:28-68;
`
`7:10-20:23 (more than 16 columns of specification devoted to signature generation
`
`techniques). Then “neighboring data processing systems on a network [may be
`
`informed] of an occurrence of the undesirable software entity . . . .” Id. at 2:66-68;
`
`19:45-20:68. This is accomplished via a “kill signal” that “is transmitted from an
`
`infected computer to neighboring computers on the network.” Id. at 19:48-52. The
`
`purpose of the kill signal is “that other computers on the network are alerted to the
`
`presence of an anomaly.” Id. at 20:8-11.
`
`C.
`
`U.S. Patent No. 5,440,723 (“Agrawal”)
`
`Agrawal is directed to processing “observations” of computer activity through
`
`multiple, tiered “detection algorithms.” Agrawal at Abstract. In particular, the
`
`different tiers generally utilize distinct algorithms, each with different speed and
`
`reliability characteristics. Id. at 1:56-60 (“By cascading detectors, fast algorithms
`
`are used to weed out normal behavior very quickly, while more complex algorithms
`
`are run preferably only when there is a good possibility that something is wrong.”);
`
`2:43-45
`
`(“Preferably,
`
`the
`
`first
`
`level
`
`detection
`
`algorithm
`
`has
`
`a
`
`computational-efficiency that is greater than a computational-efficiency of the
`
`3471556
`
`- 9 -
`
`Columbia Exhibit 2058-15
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`second level detection algorithm.”). Separate algorithms may be executed in a serial
`
`“cascade manner.” Id. at 3:45-64. Multiple separate algorithms may also run in
`
`parallel if the algorithms are directed to assessing different characteristics of the
`
`data. Id. at 3:65-4:8; 7:18-23.
`
`V.
`
`Ground 1: Khazan Does Not Anticipate Claims 22, 25, 27-29, 32, 35-39 or
`42
`
`A.
`
`Khazan Does Not Disclose “Modifying A Program To Include
`Indicators Of Program-Level Function Calls”
`
`All claims in this ground require the limitation “modifying a program to
`
`include indicators of program-level function calls.” Petitioner gives the example of
`
`modifying the program’s binary or source code to include indicators of what
`
`function call are being made. Pet. 9 (citing Ex. 1001 at 3:28-37); Ex. 1003 at ¶ 59.
`
`Patent Owner agrees that the claims require that the program itself—as opposed to
`
`other software components or libraries that the program interacts with—must be
`
`modified to include the indicators. Ex. 2030 at ¶ 114.
`
`Petitioner identifies paragraphs 73, 75, and 78 of Khazan as disclosing
`
`modification of a program to execute additional monitoring code that indicates
`
`which of the program’s functions are being called. Pet. 21; Ex. 1003 at ¶ 83.
`
`Although these paragraphs are cited, Petitioner has not identified a teaching in
`
`Khazan that the instrumentation technique modifies the program itself. To the
`
`contrary, Khazan teaches that other software components—not the program—are
`
`3471556
`
`- 10 -
`
`Columbia Exhibit 2058-16
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`modified to intercept function calls. Ex. 1010 at ¶ 73 (“At step 126, the associated
`
`libraries, such as all operating system DLLs, are instrumented to intercept calls to
`
`a predetermined set of target functions at run time.” (emphasis added)).
`
`In particular, Figure 7 shows how the instrumentation technique transfers
`
`control from the program when it makes a call to an external Win32 API function.
`
`Id. at Fig. 7 and ¶ 82. As the program 102 is running, the control of the program is
`
`transferred to the target function, then to the wrapper function, then the trampoline
`
`function, and then back to the target function. Id.; Ex. 2030 at ¶ 117. When a call is
`
`made to a target function, control is transferred to instructions inside the external
`
`library which provide a jump instruction to the wrapper function. Ex. 1010 at ¶ 83.
`
`The wrapper function verifies the call by comparing it with a list of calls generated
`
`by the static analysis. Id. at ¶¶ 84-85. After the call has been verified, control is
`
`transferred to the trampoline function which then returns to the library to execute the
`
`call. Id. at ¶ 88. As a result, the program is not modified but instead loses control to
`
`other software components that are not part of the program. Ex. 2030 at ¶ 117; Ex.
`
`2031 at ¶ 12. Instead, the DLL is modified to add the required wrapper and stub
`
`code. Ex. 1010 at Fig. 7.
`
`Petitioner’s expert raised a new argument at deposition that the external DLL
`
`code and Khazan’s wrapper code were “part of the application.” Ex. 2029 at
`
`112:17-19 (“[P]aragraph 80 itself is talking about the wrapper’s DLL and it is
`
`3471556
`
`- 11 -
`
`Columbia Exhibit 2058-17
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`referring to it as part of the application.”). This argument makes no sense. First,
`
`Petitioner’s expert conceded that the program’s code was not modified. Id. at
`
`116:23-117:4 (“I don’t see application dot EXE that particular file as being
`
`modified. Instead I see this modification happening in this wrapper dot DLL
`
`function . . . .”). Second, Petitioner’s expert relies on the description of the
`
`program’s “address space” in paragraph 80 to support his interpretation. Id. at
`
`111:11-22. A program’s address space is the section of system RAM that has been
`
`allocated to that application by the operating system. Ex. 2030 at ¶ 121. It is not the
`
`program itself. Id. at ¶¶ 121-22. The ’115 patent indicates that the “program’s
`
`binary or source code” is modified, neither of which are external components that
`
`happen to be loaded into the program’s address space. Id. at ¶¶ 114-16; Ex. 1001 at
`
`3:28-37; Ex. 2024 (definition of “program” concurs). In fact, Patent Owner
`
`specifically cited this disclosure of how a program would be modified to the PTO to
`
`distinguish a prior art reference during prosecution. Ex. 1002 at 111-12. Third,
`
`Khazan itself distinguishes between “the application executable” and its “address
`
`space.” Ex. 1010 at ¶ 80 (“In this example, the application executable may be
`
`located in the first portion of its address space.” (emphasis added)).
`
`Further, Petitioner has not explained how functions that are internal to the
`
`program (not in libraries) would be tracked or how a program would be modified to
`
`add indicators for them. Khazan extensively discusses particular methods for
`
`3471556
`
`- 12 -
`
`Columbia Exhibit 2058-18
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`intercepting and monitoring Win32 API calls. Ex. 1010 at Fig. 7; ¶¶ 79-100.
`
`Khazan consistently states that its system monitors external function calls, with no
`
`discussion of monitoring function calls internal to an application. Ex. 1010 at ¶ 48
`
`(explaining that “the calls determined by static analyzer 104 are the Win32 APIs
`
`which are predetermined subset [sic] of externally called functions or routines”); id.
`
`at ¶ 73 (“The target functions are assumed to be external to the application.”); id. at ¶
`
`82 (“The external call is intercepted using the instrumentation techniques described
`
`herein.”); Ex. 2031 at ¶ 12 (named inventor on Khazan agrees).
`
`Prof. Cybenko concurs that a POSITA reading Khazan would understand that
`
`reference to disclose function calls made to well-known Win32 libraries and not to
`
`functions entirely within the application. Ex. 2030 at ¶¶ 123-25. Indeed, the
`
`consistent emphasis in Khazan on Win32 API calls makes sense because those are
`
`the function calls that interact with the operating system and which can harm the
`
`computer. Id. at ¶ 125; Ex. 2031 at ¶ 11. By contrast, internal function calls by
`
`definition do not interact with the operating system, and so in most cases are not
`
`indicative of malicious behavior. Ex. 2030 at ¶ 125.
`
`As such, Khazan’s discussion of instrumentation techniques for intercepting
`
`the runtime function calls made by an application are only applicable to external
`
`libraries and cannot be used with internal function calls, because the methods of
`
`representing those function calls are significantly different. Ex. 2030 at ¶¶ 114-17,
`
`3471556
`
`- 13 -
`
`Columbia Exhibit 2058-19
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`123-25. Khazan provides no guidance to a POSITA on why or how to implement a
`
`system that modifies a program to track internal function calls.
`
`B.
`
`Khazan Does Not Disclose “Identifying A Function Call As
`Anomalous”
`All claims in this ground require the limitation “identifying/identifies a
`
`function call corresponding to the at least one of the indicators as anomalous based
`
`on the comparison,” which Khazan does not disclose. The Board adopted the
`
`construction for “anomalous” as “deviation/deviating from a model of typical
`
`computer system usage.” Institution Decision at 6. Khazan does not meet this
`
`limitation under the Board’s construction for two reasons.
`
`1.
`
`Khazan Does Not Disclose “Deviation From A Model of
`Typical Computer System Usage”
`
`Khazan does not model computer system usage.1 Khazan consistently
`
`describes doing something different—collecting information regarding function
`
`target and invocation locations using “static analysis,” which is analysis “by static
`
`examination of code without execution.” Ex. 1010 at Abstract (“A model is
`
`constructed using a static analysis . . . .”); id. at ¶ 43 (“Static analysis processing as
`
`described herein may be characterized as identifying information about code by
`
`
`1 Notably, Petitioner proposed including “computer system usage” in the
`
`construction, and the Board included that term even though it disagreed with other
`
`aspects of Petitioner’s proposed construction. Institution Decision at 6.
`
`3471556
`
`- 14 -
`
`Columbia Exhibit 2058-20
`Symantec v. Columbia
`IPR2015-00375
`
`
`
`IPR2015-00375
`Patent 8,074,115
`static examination of code without execution.”). Thus, Khazan does not teach
`
`constructing its baseline list of targets and invocation locations by examining
`
`computer system usage, but rather by looking statically at unexecuted code. The
`
`information collected by Khazan’s stati