`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`In the Inter Partes Review of:
`)
`)
`
`)
`U.S. Patent No.: 8,074,115
`)
`
`)
`
`)
`
`)
`For: METHODS, MEDIA AND
`
`SYSTEMS FOR DETECTING )
`
`ANOMALOUS PROGRAM
`)
`EXECUTIONS
`)
`)
`
`
`
`Mail Stop Patent Board
`
`Patent Trial and Appeal Board
`
`P.O. Box 1450
`
`Alexandria, VA 22313-1450
`
`
`
`DECLARATION OF MICHAEL T. GOODRICH, Ph.D.
`IN SUPPORT OF PETITION FOR INTER PARTES REVIEW OF
`U.S. PATENT NO. 8,074,115
`
`
`
`
`
`
`
`1
`
`SYMC 1003
`
`
`
`I, Michael T. Goodrich, Ph.D., declare as follows:
`
`I.
`
`INTRODUCTION
`1.
`
`I have been asked by the party requesting this review, Symantec
`
`Corporation (“Petitioner”), to provide my expert opinions in support of the above-
`
`captioned petition for Inter Partes review of U.S. Patent No. 8,074,115 (the “’115
`
`patent”), challenging the patentability of claims 1-42 of the ’115 patent.
`
`2.
`
`3.
`
`I currently hold the opinions set forth in this declaration.
`
`In summary, it is my opinion that the references cited below render
`
`obvious claims 1-42 of the ’115 patent. My detailed opinions on the claims are set
`
`forth below.
`
`II. BACKGROUND AND QUALIFICATIONS
`4.
`I earned a Bachelor’s Degree in Mathematics and Computer Science
`
`from Calvin College in 1983. I obtained my Master’s Degree and Ph.D. in Computer
`
`Sciences from Purdue University in 1985 and 1987, respectively.
`
`5.
`
`I currently hold the position of Chancellor’s Professor for the
`
`Department of Computer Science at the University of California, Irvine. I have been
`
`employed by the University of California, Irvine since 2001 and have spent more than
`
`two decades teaching computer science at the University of California, Irvine and
`
`previously at Johns Hopkins University.
`
`6. My research for more than 30 years has focused generally on algorithm
`
`and data structure design, information assurance and security, and parallel and
`
`
`
`2
`
`SYMC 1003
`
`
`
`distributed computing. In 2011 I co-authored a book entitled “Introduction to
`
`Computer Security,” which was published by Addison-Wesley, Inc.
`
`7.
`
`I am a listed inventor on three issued U.S. Patents: U.S. Patent No.
`
`7,257,711,
`
`titled “Efficient Authenticated Dictionaries with Skip Lists and
`
`commutative Hashing,” U.S. Patent No. 7,299,219, titled “High Refresh-Rate retrieval
`
`of Freshly Published Content using Distributed Crawling,” and U.S. Patent No.
`
`8,681,145, titled “Attribute Transfer Between Computer Models Including Identifying
`
`Isomorphic Regions in Polygonal Meshes.” Additionally, I have published over 100
`
`papers and books.
`
`8. My professional background and technical qualifications also are
`
`reflected in my Curriculum Vitae, which is attached as Exhibit 1004.
`
`III. COMPENSATION AND RELATIONSHIP WITH PARTIES
`9.
`I am being compensated for my time. This compensation is not
`
`contingent upon my performance, the outcome of this matter, or any issues involved
`
`in or related to this matter.
`
`10.
`
`I have no financial interest in Petitioner or any related parties. I have
`
`been informed that The Trustees of Columbia University in the City of New York
`
`(“Columbia”) owns the ’115 patent. I have no financial interest in and have no
`
`contact with Columbia. I similarly have no financial interest in the ’115 patent and
`
`have not had any contact with any of its inventors.
`
`
`
`3
`
`SYMC 1003
`
`
`
`IV. MATERIAL CONSIDERED
`11.
`I have reviewed and considered, in the preparation of this declaration,
`
`the ’115 patent (Ex. 1001) and the prosecution file history for the ’115 patent (Ex.
`
`1002).
`
`12.
`
`I have reviewed and considered the Claim Construction Order issued by
`
`the district court in the ongoing litigation between the Petitioner and the Patentee.
`
`(The Trustees of Columbia University in the City of New York v. Symantec Corp., Civil Action
`
`No. 3:13-cv-808, Oct. 7, 2014 Claim Construction Order (Dkt. No. 123), Ex. 1005). I
`
`have also reviewed the district court’s clarification of its Claim Construction Order in
`
`the same litigation. (The Trustees of Columbia University in the City of New York v. Symantec
`
`Corp., Civil Action No. 3:13-cv-808, October 23, 2014 Memorandum Order Clarifying
`
`Claim Construction (Dkt. No. 146), Ex. 1006).
`
`13.
`
`I understand that, for purposes of determining whether a reference will
`
`qualify as prior art, the challenged claims of the ’115 patent are entitled to a priority
`
`date of no earlier than October 25, 2005.
`
`14.
`
`I have also reviewed and understand various publications as discussed
`
`herein, including the following references:
`
`a.
`
`b.
`
`c.
`
`U.S. Patent Application Publication No. 2005/0208562 to
`
`Khazan et al. (“Khazan,” Ex. 1010);
`
`U.S. Patent No. 5,440,723 to Arnold et al. (“Arnold,” Ex. 1007);
`
`U.S. Patent No. 8,108,929 to Agrawal et al. (“Agrawal,” Ex. 1008);
`
`
`
`4
`
`SYMC 1003
`
`
`
`d. McGraw-Hill Dictionary of Scientific and Technical Terms (5th
`
`ed. 1994) (“McGraw-Hill,” Ex. 1009);
`
`e.
`
`U.S. Patent No. 7,334,005 to Sobel (“Sobel,” Ex. 1011).
`
`15.
`
`I understand that the above references form the basis for the grounds
`
`for rejection set forth in the Petition for Inter Partes Review of the ’115 patent.
`
`Additionally, I am aware of information generally available to, and relied upon by,
`
`persons of ordinary skill in the art at the relevant times, including technical
`
`dictionaries and technical reference materials (including, for example, textbooks,
`
`manuals, technical papers, articles, and relevant technical standards); some of my
`
`statements below are expressly based on such awareness.
`
`16. Due to procedural limitations for Inter Partes reviews, the grounds of
`
`invalidity discussed herein are based solely on prior patents and other printed
`
`publications. I understand that Petitioner and the other interested parties reserve all
`
`rights to assert other grounds for invalidity not addressed herein at a later time, for
`
`instance failure of the application to claim patentable subject matter under 35 U.S.C. §
`
`101, failure to meet requirements under 35 U.S.C. § 112 (e.g., lack of written
`
`description in support of the claims) and anticipation/obviousness under 35 U.S.C. §§
`
`102 and 103 not based solely on patents and printed publications (e.g., evidence of
`
`prior use of combinations of elements claimed in the ’115 patent). Thus, absence of
`
`discussion of such matters here should not be interpreted as indicating that there are
`
`no such additional grounds for invalidity of the ’115 patent.
`
`
`
`5
`
`SYMC 1003
`
`
`
`17.
`
`I reserve the right to supplement my opinions to address any
`
`information obtained, or positions taken, based on any new information that comes
`
`to light throughout this proceeding.
`
`V.
`
`BASIS OF OPINIONS FORMED
`A.
`18.
`
`Level of Ordinary Skill in the Art
`
`It is my understanding that the ’115 patent is to be interpreted based on
`
`how it would be read by a person of “ordinary skill in the art” at the time of the
`
`effective filing date of the application. It is my understanding that factors such as the
`
`education level of those working in the field, the sophistication of the technology, the
`
`types of problems encountered in the art, the prior art solutions to those problems,
`
`and the speed at which innovations are made may help establish the level of skill in
`
`the art.
`
`19.
`
`I am familiar with the technology at issue and the state of the art at
`
`earliest priority date of the ’115 patent, October 25, 2005.
`
`20.
`
`In my opinion, the level of ordinary skill in the art of the ’115 patent at
`
`the time of the effective filing date is a person with a Master’s degree in computer
`
`science or a related field with two to three years of experience in the field of software
`
`security systems. With more education, for example additional post-graduate degrees
`
`and/or study, less industry experience is needed to attain an ordinary level of skill.
`
`21.
`
`I consider myself to have at least such ordinary skill in the art with
`
`respect to the subject matter of the ’115 patent at the time of the effective filing date.
`
`
`
`6
`
`SYMC 1003
`
`
`
`22.
`
`I am not a patent attorney and my opinions are limited to what I believe
`
`a person of ordinary skill in the art would have understood the meaning of certain
`
`claim terms to be, based on the patent documents. I use the principles below,
`
`however, as a guide in formulating my opinions.
`
`VI. LEGAL STANDARD FOR CLAIM CONSTRUCTION
`23. My understanding is that a primary step in determining validity of patent
`
`claims is to properly construe the claims to determine claim scope and meaning.
`
`24.
`
`In an Inter Partes review proceeding, I understand that claims are to be
`
`given their broadest reasonable construction (BRC) in light of the patent’s
`
`specification. (See 37 C.F.R. § 42.100(b).) In other forums, such as in federal courts,
`
`different standards of proof and claim interpretation control, which are not applied by
`
`the PTO for Inter Partes review. Accordingly, any interpretation or construction of the
`
`challenged claims in this proceeding, either implicitly or explicitly, should not be
`
`viewed as constituting, in whole or in part, Petitioner’s own interpretation or
`
`construction, except as regards to the broadest reasonable construction of the claims
`
`presented.
`
`VII. THE ’115 PATENT
`25. The ’115 patent is entitled “Methods, Media and Systems for Detecting
`
`Anomalous Program Executions.” The ’115 patent includes 42 claims, of which
`
`claims 1, 11, 21, 22, 32, and 42 are independent. Claims 1-42 are challenged in the
`
`Petition.
`
`
`
`7
`
`SYMC 1003
`
`
`
`A. General Background of the Technology of the ’115 patent
`26. The ’115 patent is directed to detecting anomalous program executions.
`
`The anomalous executions may be due to attacks from malicious code such as
`
`“[c]omputer viruses, worms, [and] Trojans.” (’115 patent, 1:23-43, Ex. 1001). These
`
`types of malicious code, the ’115 patent explains, are a constant menace to computer
`
`users connected over a network. (See id.). Likewise, the anomalous executions may be
`
`due to programming errors in software applications. (See id.). The software faults and
`
`failures caused by the malicious code or programming errors “result in illegal memory
`
`access errors, division by zero errors, buffer overflows attacks, etc.” (Id.). The ’115
`
`patent explains that many computers are equipped with antivirus software and
`
`firewalls for protection from malicious code. (See id.). However, these are not always
`
`adequate. (Id.).
`
`B.
`Purported Invention of the ’115 Patent
`27. The ’115 patent alleges to provide “[m]ethods, media, and systems for
`
`detecting anomalous program executions . . . that may be indicative of a malicious
`
`attack or program fault.” (’115 patent, 3:7-15, Ex. 1001). Claim 1 is representative:
`
`1. A method for detecting anomalous program executions,
`
`comprising: executing at least a part of a program in an emulator;
`
`comparing a function call made in the emulator to a model of
`
`function calls for the at least a part of the program; identifying the
`
`function call as anomalous based on the comparison; and upon
`
`
`
`8
`
`SYMC 1003
`
`
`
`identifying the anomalous function call, notifying an application
`
`community that
`
`includes a plurality of computers of the
`
`anomalous function call.
`
`(’115 patent, 20:36-46, Ex. 1001.)
`
`28.
`
`In order to detect “anomalous program executions that may be
`
`indicative of a malicious attack or program fault,” an anomaly detector trains a model
`
`of normal program behavior and applies the model to detect deviations from normal
`
`program behavior during subsequent operation. (’115 patent, 3:13-15, Ex. 1001); (See
`
`’115 patent, 3:50-56, Ex. 1001). The anomaly detector of the ’115 patent specifically
`
`focuses on detecting anomalous function calls made by the program. (See ’115 patent,
`
`3:46-56, Ex. 1001).
`
`29. The anomaly detector models normal function call behavior by
`
`executing part, or all, of the program using an instruction-level emulator, or by using
`
`another suitable technique. (See ’115 patent, 3:28-37, Ex. 1001). The anomaly detector
`
`thereby determines information about the function calls made by the program. This
`
`information may include function names, function call arguments, stack frames, and
`
`the like. (’115 patent, 3:38-40, Ex. 1001). The information is then used to train a
`
`model that describes normal function calls made by the program. (See ’115 patent,
`
`4:9-13, Ex. 1001). The anomaly detector observes subsequent function calls made by
`
`the program and uses the trained model to detect anomalous behaviors. (’115 patent,
`
`3:52-56, Ex. 1001). Upon identifying a function call as anomalous, the anomaly
`
`
`
`9
`
`SYMC 1003
`
`
`
`detector notifies an application community that includes a plurality of computers that
`
`an anomalous function call has been identified. (See ’115 patent, 18:57-59, Ex. 1001).
`
`30.
`
`Figure 8 illustrates the operation of the anomaly detector described in
`
`the ’115 patent:
`
`
`
`The anomaly detector detects a function call being made by a program at step 802.
`
`The anomaly detector then compares the detected function call at step 804 to the
`
`previously-created model of normal function calls. This comparison causes a function
`
`call to be identified as anomalous at step 806. (’115 patent, 3:46-56, Ex. 1001).
`
`31.
`
`Several of the
`
`independent claims of the
`
`’115 patent generally
`
`correspond to the steps illustrated by FIG. 8. For example, claim 22 recites: “[a]
`
`method for detecting anomalous program executions, comprising: modifying a
`
`program to include indicators of program-level function calls being made during
`
`
`
`10
`
`SYMC 1003
`
`
`
`execution of the program; comparing at least one of the indicators of program-level
`
`function calls made in an emulator to a model of function calls for at least a part of
`
`the program; and identifying a function call corresponding to the at least one of the
`
`indicators as anomalous based on the comparison. (’115 patent, 21:50-59 Ex. 1001).
`
`Independent claims 32 and 42 likewise recite “modifying,” “comparing,” and
`
`“identifying” elements.
`
`32. Other independent claims of the ’115 patent recite an additional element
`
`after the “identifying” element. For example, claim 1 recites “upon identifying the
`
`anomalous function call, notifying an application community that includes a plurality
`
`of computers of the anomalous function call.” Claims 11 and 21 also recite the
`
`“notifying” element.
`
`C.
`Priority Date
`33. The ’115 patent was originally filed as a PCT application on October 25,
`
`2006 and claims priority to Provisional application No. 60/730,289 filed on October
`
`25, 2005. A U.S. National Phase application claiming priority to the PCT application
`
`and claiming the benefit of the Provisional application was filed on April 22, 2008.
`
`(Ex. 1002).
`
`34.
`
`In an office action dated August 23, 2010, the examiner rejected all of
`
`the pending claims, 1-42. (File History, page 126, Ex. 1002). Specifically, claims 11-
`
`20 and 32-41 were rejected under 35 U.S.C. § 101; claims 1-7 and 22 were rejected
`
`under 35 U.S.C. § 102(e) as anticipated by U.S. Patent No. 7,496,898 to Vu; and
`
`
`
`11
`
`SYMC 1003
`
`
`
`claims 8-21 and 23-42 were rejected under 35 U.S.C. § 103(a) as being obvious over
`
`Vu in view of Chan et al. (“a Machine learning approach to Anomaly Detection”,
`
`Technical Report, Department of computer Science, Florida Institute of Technology,
`
`March 2003, Pages 1-13). (File History, pages 128-130, Ex. 1002).
`
`35.
`
`In response, the patentee amended independent claims 1, 11, and 21 to
`
`add the limitation, “upon identifying the anomalous function call, notifying an
`
`application community that includes a plurality of computers of the anomalous
`
`function call.” (File History, pages 119-121, Ex. 1002). The patentee also argued that
`
`“nothing in Vu shows or suggests the feature of ‘executing at least a part of the
`
`program in an emulator.’ Instead of using an emulator that executes at least a part of
`
`the program, Vu relies on examining the code for generic function calls.” (File
`
`History, page 110, Ex. 1002). The patentee also argued that “Vu also does not show
`
`or suggest ‘comparing a function call made in the emulator to a model of function
`
`calls for the at least a part of the program.” (Id. (emphasis in original)).
`
`36. The examiner, thereafter, issued a notice of allowance on March 17,
`
`2011. (File History, page 95, Ex. 1002).
`
`37. On June 17, 2011, after having already obtained a notice of allowance,
`
`the patentee filed a request for continued examination (RCE). (File History, page 42,
`
`Ex. 1002). In the RCE, the patentee disclosed various references to be considered by
`
`the examiner. The examiner responded on July 28, 2011 with a second notice of
`
`allowance. (File History, page 13, Ex. 1002). In allowing the ’115 patent, the
`
`
`
`12
`
`SYMC 1003
`
`
`
`examiner identified Khazan as one example of prior art that discloses many of the
`
`claim limitations. (See id). The examiner determined, however, that Khazan and the
`
`other prior art fails to teach “singly or in combination comparing a function call made
`
`in an emulator to a model of function calls for the at least a part of the program,
`
`identifying the function call as anomalous based on the comparison and upon
`
`identification, notifying an application community.” (See id). These were the reasons
`
`for allowance provided by the examiner. (See id).
`
`VIII. ANTICIPATION AND OBVIOUSNESS STANDARDS
`38.
`I understand that “anticipation” is a question of fact and that for a
`
`reference to anticipate a claimed invention it must disclose each and every element set
`
`forth in the claim for that invention. I further understand that the requirement of
`
`strict identity between the claim and the reference is not met if a single element or
`
`limitation required by the claim is missing from the applied reference.
`
`39.
`
`It is my further understanding that a prior art reference is anticipatory
`
`only if it discloses each and every limitation of the claim (as properly construed) at
`
`issue. In other words, every limitation of a claim must identically appear in a single
`
`prior art reference for it to anticipate a claim.
`
`40.
`
`It is further my understanding that a claimed invention is unpatentable if
`
`the differences between the invention and the prior art are such that the subject
`
`matter of the claim as a whole would have been obvious at the time the invention was
`
`made to a person having ordinary skill in the art to which the subject matter pertains.
`
`
`
`13
`
`SYMC 1003
`
`
`
`41.
`
`It is my understanding that “obviousness is a question of law based on
`
`underlying factual issues including (1) the scope and content of the prior art, (2) the
`
`differences between the prior art and the asserted claims, (3) the level of ordinary skill
`
`in the pertinent art, and (4) the existence of secondary considerations such as
`
`commercial success, long-felt but unresolved needs, failure of others, etc.”
`
`42.
`
`I understand that for a single reference or a combination of references to
`
`render obvious the claimed invention, a person of ordinary skill in the art must have
`
`been able to arrive at the claims by altering or combining the applied references.
`
`43.
`
`I understand that an obviousness evaluation can be based on a
`
`combination of multiple prior art references. I understand that the prior art
`
`references themselves may provide a suggestion, motivation, or reason to combine,
`
`but other times the nexus linking two or more prior art references is simple common
`
`sense. I further understand that obviousness analysis recognizes that market demand,
`
`rather than scientific literature, often drives innovation, and that a motivation to
`
`combine references may be supplied by the direction of the marketplace.
`
`44.
`
`I understand that if a technique has been used to improve one device,
`
`and a person of ordinary skill in the art would recognize that it would improve similar
`
`devices in the same way, using the technique is obvious unless its actual application is
`
`beyond his or her skill.
`
`45.
`
`I also understand that practical and common sense considerations
`
`should guide a proper obviousness analysis, because familiar items may have obvious
`
`
`
`14
`
`SYMC 1003
`
`
`
`uses beyond their primary purposes. I further understand that a person of ordinary
`
`skill in the art looking to overcome a problem will often be able to fit together the
`
`teaching of multiple publications. I understand that obviousness analysis therefore
`
`takes into account the inferences and creative steps that a person of ordinary skill in
`
`the art would employ under the circumstances.
`
`46.
`
`I understand that a particular combination may be proven obvious
`
`merely by showing that it was obvious to try the combination. For example, when
`
`there is a design need or market pressure to solve a problem and there are a finite
`
`number of identified, predictable solutions, a person of ordinary skill has good reason
`
`to pursue the known options within his or her technical grasp because the result is
`
`likely the product not of innovation but of ordinary skill and common sense.
`
`47.
`
`I also understand that the combination of familiar elements according to
`
`known methods is likely to be obvious when it does no more than yield predictable
`
`results. When a work is available in one field of endeavor, design incentives and other
`
`market forces can prompt variation of it, either in the same field or a different one. If
`
`a person of ordinary skill can implement a predictable variation, the patent claims is
`
`likely obvious.
`
`48.
`
`It is further my understanding that a proper obviousness analysis focuses
`
`on what was known or obvious to a person of ordinary skill in the art, not just the
`
`patentee. Accordingly, I understand that any need or problem known in the field of
`
`
`
`15
`
`SYMC 1003
`
`
`
`endeavor at the time of invention and addressed by the patent can provide a reason
`
`for combining the elements in the manner claimed.
`
`49.
`
`I understand that a claim can be obvious in light of a single reference,
`
`without the need to combine references, if the elements of the claim that are not
`
`found explicitly or inherently in the reference can be supplied by the common sense
`
`of one of skill in the art.
`
`50.
`
`I understand that secondary indicia of non-obviousness may include (1)
`
`a long felt but unmet need in the prior art that was satisfied by the invention of the
`
`patent; (2) commercial success of processes covered by the patent; (3) unexpected
`
`results achieved by the invention; (4) praise of the invention by others skilled in the
`
`art; (5) taking of licenses under the patent by others; (6) deliberate copying of the
`
`invention; (7) failure of others to find a solution to the long felt need; and (8)
`
`skepticism by experts.
`
`51.
`
`I also understand that there must be a relationship between any such
`
`secondary considerations and
`
`the
`
`invention.
`
` I
`
`further understand
`
`that
`
`contemporaneous and independent invention by others is a secondary consideration
`
`supporting an obviousness determination.
`
`52.
`
`In sum, my understanding is that prior art teachings are properly
`
`combined where a person of ordinary skill in the art having the understanding and
`
`knowledge reflected in the prior art and motivated by the general problem facing the
`
`inventor, would have been led to make the combination of elements recited in the
`
`
`
`16
`
`SYMC 1003
`
`
`
`claims. Under this analysis, the prior art references themselves, or any need or
`
`problem known in the field of endeavor at the time of the invention, can provide a
`
`reason for combining the elements of multiple prior art references in the claimed
`
`manner.
`
`IX. ANALYSIS OF THE TECHNICAL BASIS UNDERLYING THE
`GROUNDS OF REJECTION SET FORTH IN THE PETITION FOR
`INTER PARTES REVIEW
`A.
`Claim Construction
`53. As I mentioned earlier, I understand that for purposes of an Inter Partes
`
`review, the terms of patent claims are to be given their BRC in light of the patent’s
`
`specification. I additionally understand that the BRC is not necessarily the same
`
`interpretation that would be given to the terms in other proceedings.
`
`54.
`
`I have reviewed the Claim Construction Order issued by the district
`
`court. (The Trustees of Columbia University in the City of New York v. Symantec Corp., Civil
`
`Action No. 3:13-cv-808, Oct. 7, 2014 Claim Construction Order (Dkt. No. 123), Ex.
`
`1005). In addition, I have reviewed the specification and the file history for further
`
`indication of BRC. From this review, I conclude that the claim constructions made
`
`by the district court are consistent with the BRC for purposes of an Inter Partes review.
`
`Additionally, the claim terms not construed herein are given their BRC as understood
`
`by a person of ordinary skill in the art and consistent with the disclosure.
`
`55.
`
`Specifically, the construction of the term “anomalous” adopted by the
`
`district court is “[d]eviation/deviating from a model of typical, attack-free computer
`
`
`
`17
`
`SYMC 1003
`
`
`
`system usage.” (Ex. 1005; Ex. 1006). This construction is consistent with the BRC.
`
`The specification describes how the anomaly detector models “normal program
`
`execution stack behavior” and “detect[s] stacked function references as anomalous . . .
`
`by comparing those references to the model.” (’115 patent, 3:46-56, Ex. 1001). The
`
`“normal . . . behavior” refers to typical, attack-free behavior while the “comparing”
`
`serves to detect a deviation from the normal behavior.
`
`56. The construction of the term “emulator” adopted by the district court is
`
`“[s]oftware, alone or in combination with hardware, that permits the monitoring and
`
`selective execution of certain parts, or all, of a program.” (Ex. 1005). This
`
`construction is consistent with the BRC. The specification describes how stack
`
`information may be
`
`extracted using “Selective Transactional Emulation
`
`(STEM)…which permits the selective execution of certain parts, or all, of a program
`
`inside an instruction-level emulator…by modifying a program’ s binary or source code
`
`to include indicators of what functions calls are being made (and any other suitable
`
`related information), or using any other suitable technique.” (’115 patent, 3:28-37, Ex.
`
`1001).
`
`57. The construction of the term “application community” as adopted by
`
`the district court is “[m]embers of a community running the same program or a
`
`selected portion of the program.” (Ex. 1005). This construction is consistent with
`
`the BRC. The specification states that “models are shared among many members of a
`
`community running the same application (referred to as an ‘application community’).”
`
`
`
`18
`
`SYMC 1003
`
`
`
`(’115 patent, 6:31-33, Ex. 1001). Further, the specification also describes how only a
`
`portion of an application may be modeled by each member of an application
`
`community. (’115 patent, 6:59-61, Ex. 1001).
`
`58.
`
`In addition, in my opinion the BRC of the phrase “generating a
`
`virtualized error” is “simulating an error return from the function.” The specification
`
`describes how an emulator may be used to “simulate an error return from a function
`
`of the application.” (’115 patent, 13:51-61, Ex. 1001). The specification also states
`
`that “the emulator can . . . simulate an error return from the function” and that this
`
`simulation is “sometimes referred to herein as ‘error virtualization.’” (’115 patent,
`
`15:12-21, Ex. 1001).
`
`59. My opinion is that the BRC of the phrase “indicators of program-level
`
`function calls” is “indicators of which of the program’s functions are being called.”
`
`The specification supports this construction in disclosing that STEM, “which permits
`
`the selective execution of certain parts, or all, of a program inside an instruction-level
`
`emulator,” modifies a program’s binary or source code “to include indicators of what
`
`function calls are being made (and any other suitable related information) . . . .” (’115
`
`patent, 3:28-37, Ex. 1001). The specification also explains that the “instruction-level
`
`emulator can be selectively invoked for segments of the application’s code . . . and
`
`simulate an error return from a function of the application.” (’115 patent, 13:51-61,
`
`Ex. 1001; Ex. 1003 at ¶ 59). Further, “upon entering the vulnerable section of the
`
`application’s code, the instruction-level emulator can capture and store the program
`
`
`
`19
`
`SYMC 1003
`
`
`
`state and processes all instructions, including function calls, inside the area designated
`
`for emulation.” (’115 patent, 13:61-65, Ex. 1001; Ex. 1003 at ¶ 59). Because the
`
`indicators are of function calls made by a program, and because the program (i.e.,
`
`application) may return an error from the function, it is clear that the indicators
`
`indicate which of the program’s functions are being called.
`
`60. Additionally, my opinion is that the BRC of the phrase “reflects” is
`
`“describes.” The specification discloses that “models may be automatically updated
`
`as time progresses. For example, although a single site may learn a particular model
`
`over some period of time, application behavior may change over time. In this case,
`
`the previously learned model may no longer accurately reflect the application
`
`characteristics. . . .” (’115 patent, 7:58-62, Ex. 1001). A person of ordinary skill in the
`
`art would recognize that the specification is using “reflects” in this instance to mean
`
`“describes.”
`
`B. Relevant Prior Art References
`1.
`
`U.S. Patent Application Publication No. 2005/0208562
`(“Khazan”)
`61. Khazan is a Patent Application Publication filed on June 18, 2003 and
`
`published on May 19, 2005. (Khazan, Ex. 1010). Thus, Khazan is prior art under
`
`pre-AIA 35 U.S.C. 102(e).
`
`62. Khazan is entitled, “Technique for Detecting Executable Malicious Code
`
`Using a Combination of Static and Dynamic Analyses.” (Khazan, Ex. 1010). Khazan
`
`
`
`20
`
`SYMC 1003
`
`
`
`is directed at ways to automatically detect “malicious code” by comparing the function
`
`call made when an application is executed with a model defined using calls to a
`
`predetermined set of targets. (See id.). Malicious code, as defined in Khazan, refers to
`
`machine instructions which perform unauthorized functions within a computer
`
`system that may be destructive, disruptive, or otherwise problematic. (Khazan, ¶ 5,
`
`Ex. 1010). Examples of malicious code (or “MC” as it is referred to in Khazan)
`
`include “a computer virus, a worm, a trojan application, and the like.” (See id.).
`
`63. As its title suggests, Khazan discloses the detection of malicious code
`
`using both static analysis and dynamic analysis. This detection may be performed
`
`using non-transitory computer-readable media, such as ROM, data storage devices, or
`
`other forms of media or storage, containing computer-executable instructions.
`
`(Khazan, ¶ 38, Ex. 1010). Similarly, the detection may be performed by a system
`
`comprising digital processing devices like computer processors. (Khazan, ¶ 72, Ex.
`
`1010). First, static analysis is performed by identifying information about the
`
`application without execution of the code. (Khazan, ¶ 43, Ex. 1010). Specifically, a
`
`static analyzer in a malicious code detection system reviews the binary code of a
`
`software application to identify a set of predetermined target function calls that are
`
`made by the application. (See id.). As an example provided in Khazan, “it may be
`
`determined that the target function calls to be identified are those calls that are
`
`external to the application 102, such as those calls that are made to system functions.”
`
`(Khazan, ¶ 42, Ex. 1010). After performing this static analysis, the static analyzer
`
`
`
`21
`
`SYMC 1003
`
`
`
`outputs a list of locations within the application where a function call was invoked
`
`along with a reference to the target function. (Khazan, ¶ 42, Ex. 1010).
`
`64. Khazan discloses that the information obtained from the static analysis
`
`is used to create an “application model” for distinguishing “between normal or
`
`expected behavior of code” and the behavior produced by [malicious code]. (Khazan,
`
`¶ 65, Ex. 1010). The model comprises target function call names and other call-
`
`related information (e.g., parameter number, typing, and run-time values), which, as
`
`one of ordinary skill in the art would recognize are a function call name and
`
`arguments. More specifically, the model, created using in