UNITED STATES PATENT AND TRADEMARK OFFICE
`
`___________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`___________
`
`GOOGLE INC.
`Petitioner
`
`v.
`
`ALFONSO CIOFFI, MEGAN ELIZABETH ROZMAN,
`MELANIE ANN ROZMAN, AND MORGAN LEE ROZMAN
`Patent Owners
`
`___________
`
`Patent No. RE43,528
`___________
`
`DECLARATION OF WILLIAM ARBAUGH, PH.D. REGARDING
`U.S. PATENT NO. RE43,528 IN SUPPORT OF PETITION FOR COVERED
`BUSINESS METHOD REVIEW
`
`Google – Exhibit 1033, cover
`
`

`

`IV.
`
`TABLE OF CONTENTS
`Background and Qualifications .......................................................................... 1
`I.
`II. Materials Considered .......................................................................................... 4
`III.
`Legal Standards for Patentability ....................................................................... 6
`A.
`Obviousness Analysis .............................................................................. 7
`B.
`Level of Ordinary Skill in the Art .......................................................... 11
`Technical Background ...................................................................................... 12
`A.
`An Operating System Process ................................................................ 13
`B.
`Inter-Process Communications .............................................................. 14
`C.
`Process Creation ..................................................................................... 15
`D.
`Process and File Permissions ................................................................. 16
`E.
`Processor Affinity .................................................................................. 18
`The ’528 Reissue .............................................................................................. 19
`A.
`Effective Filing Date .............................................................................. 19
`B.
`Overview of the ’528 Reissue ................................................................ 19
`C.
`Construction of Terms Used in the ’528 Reissue .................................. 26
`VI. Overview of Primary Prior Art References ...................................................... 28
`A.
`Overview of Ioannidis-2002 (Ex. 1025) and Ioannidis-2001
`(Ex. 1026) ............................................................................................... 28
`1.
`The Ioannidis SubOS Architecture .............................................. 30
`2.
`The Ioannidis Secure Multi-Process Web Browser ..................... 33
`Overview of Absolute OpenBSD (Ex. 1027) ........................................ 34
`B.
`Overview of Complete FreeBSD (Ex. 1028) ......................................... 35
`C.
`VII. All of the Challenged Claims Are Obvious in Light of the Prior Art .............. 35
`A.
`Claims 21, 22, 23, 24, 30, 44, 64, and 67 Are Obvious Based on
`the Ioannidis Papers Alone or in Combination with Absolute
`OpenBSD ............................................................................................... 35
`1.
`Claim 21 ....................................................................................... 37
`2.
`Claim 22 ....................................................................................... 52
`3.
`Claim 23 ....................................................................................... 53
`i
`
`V.
`
`Google – Exhibit 1033, page i
`
`

`

`TABLE OF CONTENTS
`(continued)
`
`B.
`
`Claim 24 ....................................................................................... 53
`4.
`Claim 30 ....................................................................................... 54
`5.
`Claim 44 ....................................................................................... 55
`6.
`Claim 64 ....................................................................................... 59
`7.
`Claim 67 ....................................................................................... 62
`8.
`Claims 1, 5, and 8 Are Obvious Based on the Ioannidis Papers
`Alone or in Combination with Absolute OpenBSD and Complete
`FreeBSD ................................................................................................. 63
`1.
`Claim 1 ......................................................................................... 65
`2.
`Claim 5 ......................................................................................... 69
`3.
`Claim 8 ......................................................................................... 70
`VIII. Secondary Considerations ................................................................................ 70
`IX. Conclusion ........................................................................................................ 71
`
`ii
`
`Google – Exhibit 1033, page ii
`
`

`

`I, William Arbaugh, Ph.D., declare as follows:
`
`1.
`
`I make this declaration based upon my own personal knowledge and,
`
`if called upon to testify, would testify competently to the matters stated herein.
`
`2.
`
`I have been asked by Google Inc. to provide technical assistance in
`
`connection with the covered business method review of U.S. Patent No. RE43,528
`
`(which I will refer to as the “’528 Reissue”). This declaration is a statement of
`
`certain opinions I have formed on issues related to the patentability of claims 1, 5,
`
`8, 21, 22, 23, 24, 30, 44, 64, and 67 of the ’528 Reissue.
`
`3.
`
`I have also been retained as an expert witness by Google Inc. in
`
`connection with the district court lawsuit involving the ’528 Reissue, and I have
`
`provided certain opinions in that proceeding. I have not been asked to restate all of
`
`my opinions on the patentability of claims in the ’528 Reissue. I continue to hold
`
`the opinions that I have expressed in the district court lawsuit. The fact that I have
`
`not restated a particular opinion in this declaration does not mean that I have
`
`changed my previously expressed opinion.
`
`4.
`
`I am compensated at $350 per hour for working on this matter. My
`
`compensation is not contingent in any way on the outcome of this matter.
`
`I.
`
`BACKGROUND AND QUALIFICATIONS
`
`5.
`
`In formulating my opinions, I have relied on my knowledge, training,
`
`and experience in the relevant field, which I will summarize briefly.
`
`1
`
`Google – Exhibit 1033, page 1
`
`

`

`6.
`
`7.
`
`I am a U.S. citizen residing in Ellicott City, Maryland.
`
`I am a computer scientist consulting in the area of computer security,
`
`operating systems, and networking.
`
`8.
`
`I earned a Bachelor of Science degree with a concentration in
`
`Computer Science in 1984 from the United States Military Academy at West Point.
`
`In 1985, I obtained a Master of Science in Computer Science degree from
`
`Columbia University. And, in 1999, I earned a Ph.D. in Computer Science from
`
`the University of Pennsylvania. For my Ph.D. dissertation I developed a system
`
`for securely starting a computer system.
`
`9.
`
`I worked for the U.S. Army from 1987 to 1990 as a senior software
`
`engineer. I developed data intensive applications in support of the Army staff.
`
`From 1990 to 2000, I worked at the National Security Agency (NSA) in a variety
`
`of research, development, and operational roles. In one role, I was a team chief in
`
`the information security research group from approximately 1992-1994. My team
`
`was responsible for performing and funding both malware detection and advanced
`
`intrusion detection research. When I departed from the NSA in 2000, I was a
`
`senior technical advisor to the chief of the Office of Advanced Network Programs.
`
`10.
`
`I joined the University of Maryland at College Park (UMCP) in 2000
`
`as an Assistant Professor. While at UMCP, I built a research group focused on
`
`Information Systems Security. My research group was responsible for the creation
`
`2
`
`Google – Exhibit 1033, page 2
`
`

`

`of a widely used software artifact known as “Open1x,” which provides an
`
`authentication framework for both wired and wireless connections.
`
`11.
`
`In 2004, I was asked to evaluate the security of the State of
`
`Maryland’s electronic voting machines. During the evaluation of the machines, I
`
`was able to successfully penetrate, via a network exploit, the central server
`
`responsible for tallying all of the votes. This work was reported in the New York
`
`Times and on National Public Radio.
`
`12.
`
`In 2004, I cofounded Komoku, Inc. and served as President and CTO.
`
`Komoku focused on the detection of a specific class of advanced malware threats
`
`(called “Rootkits”) that compromise the operating system of an infected system.
`
`Komoku’s technology employed an add-in hardware co-processor, an operating
`
`system driver, and via virtualization. Microsoft acquired Komoku in 2008, and I
`
`subsequently joined Microsoft as a Principal Architect in the Security Product
`
`Group. The technology we developed at Komoku is now integrated into every
`
`supported copy of Microsoft’s desktop and server operating system software.
`
`13.
`
`In 2009, I returned to the University of Maryland as an Associate
`
`Professor. I retired from that position in 2012 and am now an Associate Professor
`
`Emeritus. I am also the Founder, President, and Chief Technology Officer (CTO)
`
`of Five Directions, Inc. Five Directions is a start-up company focusing on the near
`
`real-time detection of advanced malware.
`
`3
`
`Google – Exhibit 1033, page 3
`
`

`

`14.
`
`I coauthored the book entitled “Real 802.11 Security: Wi-Fi Protected
`
`Access and 802.11i” published in 2003. Among other topics, I wrote about
`
`different types of attacks against wireless networks and the tools that can be used
`
`for attacking and defending such wireless networks.
`
`15.
`
`I am a named inventor on eight U.S. Patents. All eight patents relate
`
`to computer security including wireless security and host-based security.
`
`II. MATERIALS CONSIDERED
`
`16.
`
`I have reviewed and considered the following documents, among
`
`others, in connection with my analysis of the ’528 Reissue:
`
`• the ’528 Reissue (Ex. 1001);
`
`• Prosecution history of U.S. Application No. 12/720,147, which led to
`
`the issuance of the ’528 Reissue (“File History”) (Ex. 1002);
`
`• Prosecution history of U.S. Application No. 10/913,609, which led to
`
`the issuance of the ’247 Patent (“’247 Patent File History”)
`
`(Ex. 1003);
`
`• R. Bryant and D. O’Hallaron, “Computer Systems: A Programmer’s
`
`Perspective,” 2003 (“Bryant and O’Hallaron”) (Ex. 1023);
`
`• B. Kernighan and R. Pike, “The Unix Programming Environment,”
`
`1984 (‘Kernighan and Pike”) (Ex. 1024);
`
`• S. Ioannidis, S. Bellovin, and J. Smith, “Sub-Operating Systems: A
`
`4
`
`Google – Exhibit 1033, page 4
`
`

`

`New Approach to Application Security,” September 2002 (“Ioannidis-
`
`2002”) (Ex. 1025);
`
`• S. Ioannidis and S. Bellovin, “Building a Secure Web Browser,” June
`
`2001 (“Ioannidis-2001”) (Ex. 1026);
`
`• R. Weeks, E. Dumbill and B. Jepson, “Linux Unwired,” April 2004
`
`(“Linux Unwired”) (Ex. 1029);
`
`• M. Lucas, “Absolute OpenBSD: UNIX for the Practical Paranoid,”
`
`No Starch Press, 2003 (“Absolute OpenBSD”) (Ex. 1027);
`
`• G. Lehey, “The Complete FreeBSD: Documentation from the
`
`Source,” O’Reilly Community Press, Fourth Ed., May 2003
`
`(“Complete FreeBSD”) (Ex. 1028)
`
`• E. Zwicky, S. Cooper, and B. Chapman, “Building Internet
`
`Firewalls,” ISBN: 1-56592-871-7, Second Edition, June 2000
`
`(“Building Internet Firewalls”) (Ex. 1030)
`
`• M. Stiegler and M. Miller, “A Capability Based Client: The
`
`DarpaBrowser,” June 26, 2002 (“DarpaBrowser”) (Ex. 1031)
`
`• Declaration of Steven M. Bellovin, Ph.D (“Bellovin Decl.”) (Ex.
`
`1032)
`
`17. My opinions are also based on my experience in the field of computer
`
`security.
`
`5
`
`Google – Exhibit 1033, page 5
`
`

`

`III. LEGAL STANDARDS FOR PATENTABILITY
`
`18. My opinions are also formed by my understanding of the relevant law.
`
`I am not an attorney. For purposes of this declaration, I have been informed about
`
`certain aspects of the law as it relates to my opinions.
`
`19.
`
`I understand that for an invention claimed in a patent to be found
`
`patentable, it must be (among other things) new and not obvious based on what
`
`was known before the invention was made.
`
`20.
`
`I understand that the information that is used to evaluate whether an
`
`invention was new and not obvious when made is generally referred to as “prior
`
`art.” I understand that the prior art includes patents and printed publications that
`
`existed before the earliest filing date of the patent (i.e., the “effective filing date”).
`
`I also understand that a patent is prior art if it was filed before the effective filing
`
`date of the claimed invention and that a printed publication is prior art if it was
`
`publicly available before the effective filing date.
`
`21.
`
`I understand that in this covered business method patent review
`
`proceeding, Google has the burden of proving that the claims of the ’528 Reissue
`
`are unpatentable in light of prior art by a preponderance of the evidence. I
`
`understand that a preponderance of the evidence is evidence sufficient to show that
`
`a fact is more likely true than not true.
`
`22.
`
`I understand that in this covered business method patent review
`
`6
`
`Google – Exhibit 1033, page 6
`
`

`

`proceeding, the claims must be given their broadest reasonable interpretation
`
`consistent with the patent specification. After the claims are construed in this
`
`manner, they are then compared to the prior art.
`
`23.
`
`I understand that in this covered business method patent review
`
`proceeding, the information that may be evaluated is limited to patents and printed
`
`publications. My analysis, which is set out in detail below, compares the claims to
`
`printed publications that I understand are prior art to the claims.
`
`A.
`
`24.
`
`Obviousness Analysis
`
`I understand that prior art can render a patent claim unpatentable
`
`where the claim would have been “obvious” to a person of ordinary skill in the art.
`
`I understand that the following standards govern the determination of whether a
`
`patent claim is rendered “obvious” in light of the prior art. I have applied these
`
`standards in my evaluation of whether claims 1, 5, 8, 21, 22, 23, 24, 30, 44, 64, and
`
`67 of the ’528 Reissue were obvious in light of the prior art.
`
`25.
`
`I understand that a claimed invention is not patentable if it would have
`
`been obvious to a person of ordinary skill in the field of the invention at the time
`
`the invention was made. This means that even if all the requirements of a claim
`
`are not found in a single prior art reference, the claim is not patentable if the
`
`differences between the subject matter in the prior art and the subject matter in the
`
`claim would have been obvious to a person of ordinary skill in the art at the time
`
`7
`
`Google – Exhibit 1033, page 7
`
`

`

`the application was filed.
`
`26.
`
`I understand that a determination as to whether a claim would have
`
`been obvious should be based on four factors (though not necessarily in the
`
`following order): (i) the level of ordinary skill in the art at the time the application
`
`was filed; (ii) the scope and content of the prior art; (iii) the differences between
`
`the claimed invention and the prior art; and (iv) any objective factors indicating
`
`obviousness or non-obviousness that may exist in a particular case.
`
`27.
`
`I understand that an obviousness analysis should not be based on
`
`hindsight, but must be done using the perspective of a person of ordinary skill in
`
`the relevant art as of the effective filing date of the patent claim.
`
`28.
`
`I understand the objective factors indicating obviousness or non-
`
`obviousness may include: commercial success of products covered by the patent
`
`claims; a long-felt but unaddressed need for the invention; failed attempts by
`
`others to make the invention; copying of the invention by others in the field;
`
`expressions of surprise by experts and those skilled in the art at the making of the
`
`invention; and the patentee having proceeded contrary to the accepted wisdom of
`
`the prior art. I also understand that any of this evidence must be specifically
`
`connected to the invention rather than associated with the prior art or with
`
`marketing or other efforts to promote an invention.
`
`29.
`
`I understand that the teachings of two or more prior art references may
`
`8
`
`Google – Exhibit 1033, page 8
`
`

`

`be combined in the manner disclosed in the claim if such a combination would
`
`have been obvious to one having ordinary skill in the art. In determining whether a
`
`combination would have been obvious, the following exemplary rationales may
`
`support a conclusion of obviousness:
`
`• Combining prior art elements according to known methods to yield
`
`predictable results;
`
`• Simple substitution of one known element for another to obtain
`
`predictable results;
`
`• Use of a known technique to improve similar devices (methods, or
`
`products) in the same way;
`
`• Applying a known technique to a known device (method, or product)
`
`ready for improvement to yield predictable results;
`
`• “Obvious to try” – choosing from a finite number of identified,
`
`predictable solutions, with a reasonable expectation of success;
`
`• Known work in one field of endeavor may prompt variations of it for
`
`use in either the same field or a different one based on design
`
`incentives or other market forces if the variations are predictable to
`
`one of ordinary skill in the art;
`
`• Some teaching, suggestion, or motivation in the prior art that would
`
`have led one of ordinary skill to modify the prior art reference or to
`
`9
`
`Google – Exhibit 1033, page 9
`
`

`

`combine prior art reference teachings to arrive at the claimed
`
`invention.
`
`30.
`
`I understand that the obviousness analysis need not seek out precise
`
`teachings directed to the specific subject matter of the challenged claim, but
`
`instead can take account of the ordinary innovation and experimentation in the
`
`relevant field that does no more than yield predictable results.
`
`31.
`
`I understand that, in assessing whether there was an apparent reason to
`
`modify or combine known elements as claimed, it may be necessary to look to
`
`interrelated teachings of multiple patents, the effects of commercial demands, and
`
`the background knowledge of a person of ordinary skill in the art. I further
`
`understand that any motivation that would have applied to a person of ordinary
`
`skill in the art, including motivation from common sense or derived from the
`
`problem to be solved, is sufficient to explain why references would have been
`
`combined.
`
`32.
`
`I understand that modifications and combinations suggested by
`
`common sense are important and should be considered. Common sense suggests
`
`that familiar items can have obvious uses beyond the particular application being
`
`described in a prior art reference, that if something can be done once it would be
`
`obvious to do it multiple times, and that in many cases a person of ordinary skill in
`
`the art can fit the teachings of multiple patents together in an obvious manner to
`
`10
`
`Google – Exhibit 1033, page 10
`
`

`

`address a particular problem. The prior art does not need to be directed to solving
`
`the same problem that is addressed in the patent.
`
`33.
`
`I understand that a person of ordinary skill in the art is also a person
`
`of ordinary creativity. In many fields, it may be that there is little discussion of
`
`obvious techniques, modifications, and combinations, and it may be the case that
`
`market demand, rather than scientific research or literature, will drive a new
`
`design. When there is market pressure or design need to solve a particular problem
`
`and there are a finite number of identified, predictable solutions, a person of
`
`ordinary skill has a good reason to employ the known options. If this leads to the
`
`expected success, then it is likely the product of ordinary skill and common sense
`
`as opposed to patentable innovation. I understand that if a combination was
`
`obvious to try, that may show that it was obvious and therefore unpatentable. That
`
`a particular combination of prior art elements was obvious to try suggests that the
`
`combination was obvious even if no one made the combination.
`
`B.
`
`Level of Ordinary Skill in the Art
`
`34. My opinions regarding invalidity are rendered from the perspective of
`
`a hypothetical person of ordinary skill in the art (POSITA) at the time of the
`
`invention of the ’247 Patent. It is my opinion that the level of ordinary skill in the
`
`art during the 2004 time frame would be an engineer with a bachelor’s degree in
`
`computer science with at least two years of experience with operating systems and
`
`11
`
`Google – Exhibit 1033, page 11
`
`

`

`operating system security mechanisms.
`
`35.
`
`I understand that Patent Owner’s expert witness in the related
`
`litigation has opined that a person of ordinary skill in the art would have been a
`
`person with a bachelor’s degree in computer science, or a closely related field such
`
`as electrical engineering that requires the study of computer science, and at least
`
`two years of experience in the computer science industry or the equivalent
`
`experience and education obtained working in the computer science industry.
`
`36.
`
`I do not agree with this definition because it does not specify any
`
`particular type of experience in the broad field of computer science. However, I
`
`have considered my opinions expressed in this declaration and conclude that they
`
`would not change if I were to adopt Patent Owner’s definition.
`
`IV. TECHNICAL BACKGROUND
`
`37.
`
`The problem of protecting computer systems from malicious
`
`computer code was decades old when the application for the original ’247 Patent
`
`was filed in 2004. Operating systems at that time provided a number of protections
`
`for programs and files that would have been well known to a person of ordinary
`
`skill in the art. The following discussion addresses a few basic concepts that are
`
`useful for understanding my opinions regarding the ’528 Reissue and the prior art I
`
`discuss below.
`
`12
`
`Google – Exhibit 1033, page 12
`
`

`

`A.
`
`An Operating System Process
`
`38. An operating system is software that manages basic functionality on a
`
`computer system including the use of memory, execution of computer programs,
`
`and interaction with peripheral devices. For example, Microsoft Windows is a
`
`common operating system used on personal computers. UNIX is another example
`
`of an operating system. There are a number of different versions of UNIX based
`
`operating systems. OpenBSD and FreeBSD, which I discuss below, are both
`
`UNIX-based operating systems.
`
`39. An operating system process is one abstraction provided by an
`
`operating system so that a program can execute as if it has access to the entire
`
`computer and its hardware, when in fact it is sharing that hardware with other
`
`programs. A process abstracts a running program such that the program is
`
`presented with the illusion that the program is the only one currently running in the
`
`system. The program appears to have exclusive use of both the processor and the
`
`memory. These illusions are provided by the notion of a process.
`
`40. Bryant and O’Halloran discuss operating system processes in their
`
`text “Computer Systems: A Programmer’s Perspective.” (Ex. 1023) This is a
`
`standard text book that has been used to teach undergraduate classes in computer
`
`science. They explain that the classic definition of a process is an instance of a
`
`program in execution. Each program executes in the context of some process.
`
`13
`
`Google – Exhibit 1033, page 13
`
`

`

`The context consists of the state that the program needs to run correctly. This state
`
`includes the program’s code and data stored in memory, its stack, the contents of
`
`its general purpose registers, its program counter, environment variables, and the
`
`set of open file descriptors. Bryant and O’Hallaron, p. 594 (Ex. 1023).
`
`41.
`
`Each time a user runs a program, the system creates a new process and
`
`runs the program file in the context of this new process. Application programs
`
`may also create new processes and run either their own code or other applications
`
`in the context of the new process.
`
`42.
`
`The abstraction, or illusion, that a process has a private address space
`
`provides one of the building blocks for process “sandboxing” or “jailing,” because
`
`a process provides each program with its own private address space. This space is
`
`private in the sense that a byte of memory associated with a particular address in
`
`the space cannot in general be read or written by any other process.
`
`B.
`
`Inter-Process Communications
`
`43. As discussed above, a process’ private address space is isolated from
`
`the other processes running in the system in general. Operating system designers
`
`recognized that there is a need for two or more processes to communicate. This
`
`permits multiple processes to work together to perform functions, for example.
`
`There are a number of ways processes can communicate and share data such as
`
`pipes, sockets, shared memory, and semaphores.
`
`14
`
`Google – Exhibit 1033, page 14
`
`

`

`44. One particularly relevant aspect of IPC is that the programmer of the
`
`application/process controls the processes’ communications. A POSITA would
`
`have known by May 2004 about inter-process communications and how they were
`
`available in operating systems at that time.
`
`C.
`
`Process Creation
`
`45. A process can be started, initiated, or spawned, by a user in a number
`
`of ways such as using the command line or through double-clicking an icon in a
`
`windowed user interface. In an operating system, all processes are created,
`
`typically, through one system call- fork. A POSITA would know that words like
`
`“start,” “open,” “initiate,” “spawn” are all used interchangeably to refer to process
`
`creation.
`
`46. A process that spawns another process is referred to as a “parent”
`
`process. The spawned process is referred to as a “child” process. A parent process
`
`creates a new running child process by calling the fork function. The newly created
`
`child process is almost, but not quite, identical to the parent. The child gets an
`
`identical (but separate) copy of the parent’s user-level virtual address space,
`
`including the text, data, and bss segments, heap, and user stack. The child also
`
`gets identical copies of any of the parent’s open file descriptors, which means the
`
`child can read and write any files that were open in the parent when it called fork.
`
`The most significant difference between the parent and the newly created child is
`
`15
`
`Google – Exhibit 1033, page 15
`
`

`

`that they have different process identifications or “PIDs”. Bryant and O’Hallaron,
`
`p. 601 (Ex. 1023).
`
`47. A POSITA could write a program that starts-up and spawns or creates
`
`a child process via fork. A programmer can, also, control what resources the newly
`
`created child process can access. In the OpenBSD 3.5 operating system, for
`
`example, a programmer can create processes with the rfork function. The function
`
`rfork allows a programmer to control the inheritance of the copies of the file
`
`descriptors from the child’s parent process. If the child process inherits these file
`
`descriptors, then the child can access any of the open files of the parent. Without a
`
`copy of the file descriptors, the child process would have to re-open these files
`
`subject to the process permissions granted to it.
`
`D.
`
`48.
`
`Process and File Permissions
`
`I have mentioned file permissions previously and will now explain
`
`how they work. Most operating systems employ some type of permission system.
`
`The terminology may be different, but the basic concepts are the same. I will focus
`
`on UNIX to illustrate.
`
`49. UNIX processes have had four different identifiers since at least the
`
`1980’s: user id, effective user id, group id, and effective group id. The user id
`
`uniquely identifies a user represented by an integer value stored in a password file,
`
`typically /etc/passwd or a shadow version. This is generally set to the user that
`
`16
`
`Google – Exhibit 1033, page 16
`
`

`

`started the process, but it can be changed with the setuid function. The effective
`
`user id controls which resources a process can access. The user id and the
`
`effective user id can be the same or different on a process. Employing the seteuid
`
`function allows changing the effective user id. The group ids function in a fashion
`
`similar to the user ids except they allow permissions to be set to a group of users
`
`identified in the file /etc/group rather than individually.
`
`50. A commonly-used technique is to utilize the user and group ids to
`
`reduce the privileges of spawned processes. For instance, a privileged program
`
`may spawn a process and set its user and/or group id to ones that significantly limit
`
`the spawned processes privileges.
`
`51. UNIX file permissions work very much in the same way as the
`
`process permissions via users and groups. Each file is assigned to a user and a
`
`group. Each file also has a set of permissions associated with itself that determine
`
`what and how the file may be used. In general, there are three types of
`
`permissions: read, write, and execute. There are also three categories of
`
`permissions associated with a file: owner, group, and others. Thus, each category
`
`(owner, group, others) can have their own, potentially different, permissions.
`
`52. Kernighan and Pike described UNIX permission in their 1984 book
`
`“The UNIX Programming Environment.” As they explained, “[t]he file system,
`
`and therefore the UNIX system in general, determines what you can do by the
`
`17
`
`Google – Exhibit 1033, page 17
`
`

`

`permissions granted to your uid and group-id.” Kernighan and Pike, p. 53 (Ex.
`
`1024).
`
`53.
`
`For example, consider a notional system configuration file (often
`
`found in the /etc directory on a UNIX system). For example, the sudoers file
`
`found on some UNIX systems in the /etc directory contains a list of users who are
`
`permitted to elevate their permissions via the sudo command. This file will most
`
`likely be owned by root as the user and wheel as the group with read permissions
`
`set for both. Others will have no permissions to the file. These permissions enable
`
`the file to be used as intended by some specific users without allowing normal
`
`users access to read (or modify) the list of users permitted to elevate their
`
`privileges.
`
`Processor Affinity
`E.
`54. Before 2004, a programmer could pin a process or thread to a specific
`
`processor via an operating system’s programming interface. This technique
`
`ensures that the “pinned” process or thread will only execute on the assigned
`
`processor. The exact method to accomplish this varies by operating system.
`
`55.
`
`For instance, by May 2004, the Linux operating system allowed
`
`programmers to assign processes to a specific processor or set of processors. A bit
`
`mask is stored as part of the process’ meta-data that identifies the processors upon
`
`which the process may run. Initially, the mask is set to all 1’s indicating that the
`
`18
`
`Google – Exhibit 1033, page 18
`
`

`

`process can run on any processor. A programmer may, however, set the bit mask
`
`by using the sched_setaffinity function to limit the processors upon which the
`
`process may run. Thus, the programmer pins a process or thread to a specific
`
`processor or set of processors. FreeBSD also allows this functionality with
`
`multiple processors. Complete FreeBSD (Ex. 1028).
`
`V.
`
`THE ’528 REISSUE
`
`A.
`
`56.
`
`Effective Filing Date
`
`The ’528 Reissue is a reissue of ’247 Patent, which was based on U.S.
`
`Application No. 10/913,609 filed on August 7, 2004. I understand that the
`
`effective filing date of the claims of the ’528 Reissue is August 7, 2004. I have
`
`used that date in my analysis.
`
`57.
`
`I understand that the Patent Owner has taken the position in the
`
`related litigation that the appropriate invention date is in May 2004. I have
`
`considered my opinions in view of this date as well. Applying May 2004 as the
`
`invention date has no impact on my opinions expressed here.
`
`B.
`
`58.
`
`Overview of the ’528 Reissue
`
`The ’528 Reissue is entitled “System and Method for Protecting a
`
`Computer System from Malicious Software.” The Abstract states:
`
`In a computer system, a first electronic data processor is communicatively
`coupled to a first memory space and a second memory space. A second
`electronic data processor is communicatively coupled the second memory
`
`19
`
`Google – Exhibit 1033, page 19
`
`

`

`space and to a network interface device. The second electronic data
`processor is capabl