`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`In the Inter Partes Review of:
`
`
`
`U.S. Patent No. 8,645,558
`
`Filed: June 15, 2006 (PCT filing date)
`
`Issued: February 4, 2014
`
`Named Inventor(s): Steven Leslie Pope,
`Derek Edward Roberts, David James
`Riddoch, Greg Law, Steve Grantham,
`Matthew Slattery
`
`Recorded Assignee: Solarflare
`Communications, Inc.
`
`Title: Reception According To A Data
`Transfer Protocol Of Data Directed To
`Any Of A Plurality Of Destination
`Entities For Data Extraction
`
`Mail Stop Inter Partes Review
`Commissions for Patents
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`
`
`DECLARATION OF KEVIN JEFFAY, PH.D.
`
`
`
`
`
`TABLE OF CONTENTS
`
`Page
`
`I.
`
`INTRODUCTION ......................................................................................... 4
`
`II.
`
`BACKGROUND AND QUALIFICATIONS .............................................. 4
`
`III. THE APPLICABLE LAW ........................................................................... 8
`
`A.
`
`Claim Construction................................................................................ 8
`
`B.
`
`C.
`
`Anticipation ........................................................................................... 9
`
`Obviousness ........................................................................................... 9
`
`IV. LEVEL OF ORDINARY SKILL IN THE PERTINENT ART ..............11
`
`V.
`
`BACKGROUND ..........................................................................................11
`
`A. Operating Systems, Applications, And Threads .................................12
`
`B.
`
`C.
`
`Computer Networks ............................................................................14
`
`Network Protocols ...............................................................................15
`
`D. Network API (Sockets) .......................................................................18
`
`E.
`
`F.
`
`Lazy Protocol Processing ....................................................................21
`
`The ’558 Patent ...................................................................................23
`
`G.
`
`Prosecution of the ’558 Patent (Application No. 11/916,973) ...........28
`
`VI. Overview of Prior Art References ..............................................................36
`
`A.
`
`Background on Mansley ......................................................................36
`
`B.
`
`C.
`
`Background on Riddoch ......................................................................40
`
`Claims 1–5, 7, and 10–12 Are Unpatentable Over Mansley ..............41
`
`D.
`
`Claim 6 Is Obvious In View of Mansley and Riddoch .......................56
`
`
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`E.
`
`Claims 8–9 Is Obvious In View of Mansley and the Knowledge
`of One of Ordinary Skill in the Art .....................................................62
`
`VII. Secondary Considerations of Non-Obviousness .......................................65
`
`VIII. Conclusion ....................................................................................................66
`
`
`
`
`
`
`
`3
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`I.
`
`INTRODUCTION
`
`1.
`
`I submit this Declaration to offer my expert opinion regarding the
`
`unpatentability of claims 1–12 of U.S. Patent No. 8,654,558. I understand
`
`that Solarflare Inc. (“Solarflare”) has sued Petitioner Exablaze Pty Ltd.
`
`(“Petitioner”) in the U.S. District Court for the District of New Jersey for
`
`allegedly infringing the ’558 Patent.
`
`2.
`
`I have set forth my professional qualifications and relevant experience in
`
`Section II of this Declaration and have attached a copy of my curriculum
`
`vitae. (Ex. 1012.)
`
`3.
`
`In forming the opinions in this Declaration, I considered:
`
` U.S. Patent No. 8,654,558
`
` File History of U.S. Patent Application No. 11/916,973
`
` “Engineering a User-Level TCP for the CLAN Network” by Kieran
`Mansley
`
` “Distributed Computing with the CLAN Network” by David Riddoch,
`Kieran Mansley, and Steve Pope
`
`4.
`
`In addition, I relied on my own knowledge, training, and more than 30 years
`
`of experience researching and teaching the design and implementation of
`
`computer networks and computer networking technology.
`
`II. BACKGROUND AND QUALIFICATIONS
`
`5.
`
`I am currently the Gillian Cell Distinguished Professor of Computer Science
`
`in the Department of Computer Science at the University of North Carolina
`
`
`
`4
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`at Chapel Hill. I also presently serve as the Chairman of the department. I
`
`have been a faculty member at UNC since 1989.
`
`6.
`
`I received a Ph.D. in Computer Science from the University of Washington
`
`in 1989. Prior to that, I received a B.S. in Mathematics with Highest
`
`Distinction from the University of Illinois at Urbana-Champaign in 1982 and
`
`a M.Sc. in Computer Science from the University of Toronto in 1984.
`
`7.
`
`I have been
`
`involved
`
`in
`
`the research, development, design, and
`
`implementation of networked computing systems for over thirty years. In
`
`my research and teaching I have considered problems of the design and
`
`implementation of computer networks. My areas of research include
`
`computer networks, real-time systems, operating systems, multimedia
`
`networking, network performance evaluation, and aspects of router design.
`
`A major theme of my research has been the measurement and analysis of
`
`traffic patterns and traffic performance in computer networks. As an active
`
`network and operating systems researcher, I regularly attend the major
`
`international conferences and symposia where networking research is
`
`presented.
`
`8.
`
`For example, I attended the conferences where the research described in the
`
`primary reference discussed in this Declaration, Mansley (Ex. 1003), and a
`
`related work considered by Mansley (Ex. 1004, Druschel), were presented.
`
`
`
`5
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`9.
`
`In the late 1990s and 2000s aspects of my research considered router-based
`
`mechanisms for controlling the performance of network traffic. My students
`
`and I built and instrumented network routers and performed large scale
`
`experiments with this equipment. Based on these experiments, in 2003, my
`
`group at UNC won the most prestigious research award for original research
`
`in computer networking.
`
`10.
`
`In my research, I regularly use special purpose network interface cards and
`
`design software to perform network protocol processing on these cards. I
`
`have also built computer systems employing the principles of so-called
`
`“lazy” protocol processing as described in the Mansley and Druschel
`
`references discussed below.
`
`11. Results of my research have been published in books, peer reviewed
`
`domestic and international conferences, and journals. For example, in 1998
`
`my research group published a paper in the proceedings of the 19th IEEE
`
`Real-Time Systems Symposium on a form of “lazy” user-space protocol
`
`processing of network packets from a network in a data processing system.
`
`12.
`
`I am also a co-author of two textbooks related to advanced topics in
`
`computer networking. I have also edited a number of proceedings of
`
`technical conferences and symposia as well as a collection of articles on
`
`multimedia computing and networking.
`
` I have received numerous
`
`
`
`6
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`competitive research grants in the aforementioned fields of computer
`
`science, and have been invited to present distinguished lectures on topics in
`
`these fields.
`
`13. My involvement in the research community extends to leadership positions
`
`in several journals, conferences, and committees. I have been an Associate
`
`Editor of the journal Real-Time Systems since 2003 and previously served as
`
`Editor-in-Chief of the journal Multimedia Systems. I have also been an
`
`active participant in the Association for Computing Machinery (ACM) since
`
`the early 1990s and the Institute of Electrical and Electronics Engineers
`
`(IEEE) since the 1980s. Specifically, I have been a member of the ACM
`
`Special Interest Group on Data Communications (SIGCOMM) Steering
`
`Committee, the IEEE Technical Committee on Real-Time Systems, and the
`
`ACM Special Interest Group on Multimedia. I was also previously involved
`
`in the Statistical and Applied Mathematical Sciences Institute (SAMSI)
`
`program on Network Modeling for the Internet, during the period from 2002
`
`to 2004.
`
`14.
`
`I have served as an expert witness and technical consultant in litigation
`
`matters concerning computer networks, telecommunication networks, and
`
`telecommunication systems. This has included serving as an expert witness
`
`on matters related to network design and network switches and routers. I
`
`
`
`7
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`have testified in several trials, arbitrations, and claim construction hearings
`
`as an expert witness.
`
`15.
`
`I am a named inventor on three issued United States Patents and on a patent
`
`application that is currently pending. All are related to aspects of computer
`
`networking.
`
`16. More details on my qualifications, including my education, work experience
`
`and publications, are contained in my C.V., which is attached as Exhibit
`
`1012. My work on this case is being billed at a rate of $700.00 per hour,
`
`with reimbursement for actual expenses. My compensation is not contingent
`
`upon the outcome of this inter partes review.
`
`III. THE APPLICABLE LAW
`
`17.
`
`I understand
`
`the following
`
`law
`
`is applicable with regard
`
`to
`
`the
`
`unpatentability of a United States patent, and more specifically in this
`
`proceeding. I have applied this law to the facts in this matter in my analysis
`
`and in rendering my opinions.
`
`A. Claim Construction
`
`18.
`
`I understand that, during an inter partes review, claims are to be given their
`
`broadest reasonable construction in light of the specification as would be
`
`read by a person of ordinary skill in the relevant art.
`
`
`
`8
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`B. Anticipation
`
`19.
`
`It is my understanding that a reference anticipates a claim if it discloses each
`
`and every element recited in the claim, arranged as claimed. Further, it is
`
`my understanding that an anticipating reference must set forth the elements
`
`in the claim in a sufficiently detailed manner such that it would enable a
`
`person of ordinary skill in the art to make and use the claimed invention
`
`without the need for undue experimentation.
`
`20. Those elements can be either explicitly or inherently described. Inherent
`
`elements are those that are not explicitly described, but nonetheless would
`
`necessarily be present if the teachings in the reference are followed.
`
`C. Obviousness
`
`21.
`
`I understand that a patent claim is invalid if the claimed invention would
`
`have been obvious to a person of ordinary skill in the field at the time the
`
`application was filed. This means that even if all of the requirements of the
`
`claim cannot be found in a single prior art reference that would anticipate the
`
`claim, the claim can still be invalid.
`
`22. As part of this inquiry, I have been asked to consider the level of ordinary
`
`skill in the field that someone would have had at the time the claimed
`
`invention was made. In determining the level of ordinary skill, I considered
`
`the following:
`
`
`
`9
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
` the levels of education and experience of persons working in the
`field;
`
` the types of problems encountered in the field; and
`
` the sophistication of the technology.
`
`23.
`
`I understand that to obtain a patent, a claimed invention must have, as of the
`
`effective filing date, been nonobvious in view of the prior art in the field. I
`
`understand that an invention is obvious when the differences between the
`
`subject matter sought to be patented and the prior art are such that the
`
`subject matter as a whole would have been obvious at the time the invention
`
`was made to a person having ordinary skill in the art.
`
`24.
`
`I understand that to prove that prior art or a combination of prior art renders
`
`a patent obvious, it is necessary to (1) identify the particular references that,
`
`individually or in combination, make the patent obvious; (2) specifically
`
`identify which elements of the patent claim appear in each of the asserted
`
`references; and (3) explain how the prior art references could have been
`
`combined or modified to create the invention claimed. I understand that, to
`
`support a conclusion of obviousness, there must be an apparent reason for a
`
`skilled artisan to combine or modify the prior art references as recited in the
`
`claims.
`
`25.
`
`I understand that certain secondary considerations can be important evidence
`
`regarding whether a patent is obvious or nonobvious. Such considerations
`
`
`
`10
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`include: commercial success of products covered by the patent claims; a
`
`long-felt need for the invention; failed attempts by others to make the
`
`invention; copying of the invention by others in the field; unexpected results
`
`achieved by the invention as compared to the closest prior art; praise of the
`
`invention by others in the field; the taking of licenses under the patent by
`
`others; expressions of surprise by experts and those skilled in the art at the
`
`making of the invention; and the patentee proceeded contrary to the accepted
`
`wisdom of the prior art.
`
`IV. LEVEL OF ORDINARY SKILL IN THE PERTINENT ART
`
`26. Based on the disclosure of the ’558 Patent, one of ordinary skill in the art
`
`would have a B.S. degree, or its equivalent, in Computer Science, Computer
`
`Engineering, Electrical Engineering, or a related field, as well as a Master of
`
`Science degree, or equivalent, in one of those fields or approximately 2–3
`
`years of academic or industry experience in the design of software for
`
`network protocol processing. More work experience could compensate for a
`
`lack of a post-graduate degree.
`
`V. BACKGROUND
`
`27. The ’558 Patent relates to software for processing data packets received over
`
`a computer network.
`
`
`
`11
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`A. Operating Systems, Applications, And Threads
`
`28. Computers systems, including, for example, personal computers and servers,
`
`comprise both hardware and software. The software on computer systems
`
`can include both applications (such as a web browser), and an operating
`
`system (such as Windows, Mac OS, or Linux, etc.) that enables applications
`
`to use the hardware resources of the computer. The software executing on a
`
`computer systems is often described as comprising multiple “levels.” “Low-
`
`level” software refers to the software that directly controls the hardware
`
`resources (such as disk drives, network interfaces, the keyboard, etc.) while
`
`“high-level” software refers to applications. In typical computer systems
`
`using conventional operating systems, low-level software is part of the
`
`operating system and high-level software are the applications users interact
`
`with. In many operating systems the low-level software is part of the “core”
`
`or “kernel” of the operating system. Because the low-level software is part
`
`of the operating system, it is commonly referred to as “system level”
`
`software or as software that operates at the system level. High-level software
`
`is not part of the operating system and because the user interacts directly
`
`with such software, it is commonly referred to as “user level” software or
`
`software that operates at the user level. (See, e.g., Ex. 1013, Bach, The
`
`Design of the Unix Operating System (1986), at 10–11 (depicting the system
`
`
`
`12
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`architecture as containing “three levels: user, kernel, and hardware”).) This
`
`arrangement of software, with applications at the “high level” (executing
`
`“above” the operating system), and low level software, such as the kernel in
`
`the operating system (executing “below” the applications), is illustrated in
`
`Figure 1 of the ’558 Patent:
`
`
`
`(Ex. 1002, ’558 Patent, col. 2, ll. 12–16 (“FIG. 1 represents equipment
`
`capable of implementing a prior art protocol stack, such as a transmission
`
`control protocol (TCP) stack in a computer connected to a network. The
`
`equipment includes an application 1, a socket 2 and an operating system 3
`
`incorporating a kernel 4.”).)
`
`29. Both applications and operating system can be associated with a construct
`
`called a thread, which the ’558 Patent describes as “a process or part of a
`
`process.” (Ex. 1002, ’558 Patent at col. 10, ll. 5–9.) A process or a thread
`
`refers to the execution of program or portion of a program. A single
`
`
`
`13
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`application may have or use multiple threads. An operating system is
`
`responsible for making sure that resources, such as CPU time, are allocated
`
`to all the currently active processes or threads. (See Ex. 1006, Peterson &
`
`Davie, Computer Systems: A System Approach (Ed. 3 (2003)), at 7–8.) A
`
`process (the execution of a program) is defined by a “context,” which is the
`
`configuration state of the hardware and operating system required to execute
`
`the process. (See Ex. 1013, Bach, at 20.) When an operating system stops
`
`one process and starts or resumes another one (e.g., in order to share CPU
`
`time between processes), such an operation is referred to as a “context
`
`switch.” (Ex. 1006, Peterson & Davie, at 8; Ex. 1013, Bach, at 20.) Context
`
`switches are considered computational “overhead” because no application
`
`work can proceed during the switch. As further discussed below, a problem
`
`with certain prior art implementations of networking caused excess context
`
`switching, such that application processing was not performed in an efficient
`
`manner.
`
`B. Computer Networks
`
`30.
`
`In its most simple form, a computer network is a single cable that connects
`
`two or more computers together.
`
` When one computer wishes to
`
`communicate with another computer, hardware and software on that
`
`
`
`14
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`computer will create a message and transmit the message to the destination
`
`computer.
`
`31. Traditionally, a computer connects to a network using a device that is
`
`referred to as a “network interface” or “network interface card” (“NIC”).
`
`The NIC operates to receive and transmit data to and from the computer.
`
`32. An application on a computer can communicate over a network by
`
`establishing a connection to a remote node, such as a server hosting a
`
`website. In order to communicate over a network, the application generally
`
`must utilize a set of software modules often referred to as a “protocol stack”
`
`in order to send and receive data. The protocol stack enables the application
`
`to communicate using a network protocol, which are further described
`
`below.
`
`C. Network Protocols
`
`33. Communication in a network proceeds according to a number of
`
`standardized rules that control the format and processing of messages. (See,
`
`e.g., Ex. 1002, ’558 Patent at col. 43, ll. 15–36.) Together, these rules define
`
`a protocol for communication. In most networks, multiple protocols
`
`operating in concert are required to communicate messages between
`
`computers. These protocols are organized hierarchically as a series of
`
`
`
`15
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`hardware and software “layers” and are colloquially referred to as a
`
`“protocol stack.” A common 7-layer protocol stack is illustrated below.
`
`Application
`Presentation
`Session
`Transport
`Network
`Data Link
`Physical
`
`
`34.
`
`In this stack the lower (bottom) layers refer to processing that is typically
`
`performed in hardware in the NIC and the higher (top) layers refer to
`
`processing that is performed in software (in the operating system and in the
`
`application). Examples of such protocols include Ethernet (a data link
`
`protocol), the Internet Protocol (“IP”) (a network layer protocol), the
`
`Transmission Control Protocol (“TCP”) (a transport layer protocol), and the
`
`Hypertext Transport Protocol (“HTTP”) (an application layer protocol).
`
`When data arrives at a computer from the network, the data is processed by
`
`each layer in the protocol stack from the bottom layer to the top layer and
`
`eventually delivered to an application. At each layer the processing is
`
`referred to as protocol processing.
`
`35. Each layer of the protocol stack defines a message structure that is
`
`ultimately transmitted over (or received from) a network. The structures are
`
`often referred to as “packets.” Packets include both headers—which contain
`
`
`
`16
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`protocol information that is used to process the packet according to the rules
`
`of the protocol—as well as a payload—which contains the data sent (or
`
`received) by the applications communicating over the network. The ’558
`
`Patent refers to the payload as “traffic data.” (See, e.g., Ex. 1002, ’558
`
`Patent at col. 48, ll. 13–18; col. 43, ll. 42–56.
`
`36.
`
` Typically, a packet received over a network must progress through each
`
`layer of protocol stack on its way to the application for which it is destined.
`
`At each layer of the stack, headers in the packet will be used to process the
`
`packet according to a particular protocol. Such processing includes, for
`
`example, determining which application on the receiving computer should
`
`ultimately receive the payload data and determining if any data destined for
`
`the application is missing.
`
`37. Traditionally, the majority of the network protocol processing functionality,
`
`typically everything except the application protocol processing, is performed
`
`by the kernel of the operating system. (See Ex. 1003, Mansley, at 10.)
`
`However, communication over the network is typically performed by
`
`applications, such as a web browser running an application layer protocol
`
`(such as HTTP) above the operating system. Thus, “kernel protocols stacks
`
`are executed in a different context to the application they are serving,”
`
`resulting in the “large overhead associated with context switching” between
`
`
`
`17
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`the kernel and the running applications whenever network data needs to be
`
`processed. (Id.) One prior art solution to this problem is to move the
`
`protocol stack to the user-level. (Id. at 8.) The benefit of doing so is that the
`
`application is thus able to communicate with the network interface directly,
`
`“bypassing the operating system for the majority of operations.” (Id.) This
`
`mode of operation can dramatically reduce the overhead normally associated
`
`with protocol processing.
`
`D. Network API (Sockets)
`
`38. An application may access certain functions and resources using what is
`
`known as an application programming interface (API). The functions
`
`accessed by such an API are commonly packaged together in a structure
`
`referred to as a “library” (as acknowledged in the ’558 Patent specification,
`
`(Ex. 1002 at col. 13, ll. 49–52)). The concept of an API in the context of
`
`network protocol processing is well known in the art. Specifically, an
`
`application will use an API in order to leverage the functionality of a
`
`network protocol stack in order to communicate with a remote node over the
`
`network.
`
`39. When using an API, an application must be “linked” to (combined with) the
`
`library of functions implementing the API. This is because applications are
`
`typically developed separately from library functions. There are two (and
`
`
`
`18
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`only two) paradigms of linking applications and libraries. In “static
`
`linking,” applications and library functions are combined prior to the
`
`execution of the application. In “dynamic linking,” applications and library
`
`functions are combined during the execution of the application.
`
`40. Perhaps the most well-known protocol stack API model is the “sockets”
`
`API. A popular textbook by Peterson & Davie explains:
`
`1.4.1 Application Programming Interface (Sockets)
`
`The place to start when implementing a network
`
`application is the interface exported by the network.
`
`Since most network protocols are implemented in
`
`software (especially those high in the protocol stack), and
`
`nearly all computer systems implement their network
`
`protocols as part of the operating system, when we refer
`
`to interface “exported by the network,” we are generally
`
`referring to the interface that the OS provides to its
`
`networking subsystem. This interface is often called the
`
`network application programming interface (API).
`
`Although each operating system is free to define its own
`
`network API (and most have), over time certain of these
`
`APIs have become widely supported; that is, they have
`
`been ported to operating systems other than their native
`
`system. This is what happened with the socket interface
`
`originally provided by the Berkeley distribution of Unix,
`
`
`
`19
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`which is now supported by virtually all popular operating
`
`systems. . .
`
`Before describing the socket interface, it is important to
`
`keep two concerns separate in your mind. Each protocol
`
`provides a certain set of services, and the API provides
`
`the syntax by which those services can be invoked in this
`
`particular OS. . .
`
`The main abstraction of the socket interface, not
`
`surprisingly, is the socket. A good way to think of a
`
`socket is as the point where a local application process
`
`attaches to the network. The interface defines operations
`
`for creating a socket, attaching the socket to the network,
`
`sending/receiving messages through the socket, and
`
`closing the socket.
`
`(Ex. 1006, Peterson & Davie, at 5–6.)
`
`41. A socket, in other words, is a programming abstraction that allows an
`
`application to treat the network as if it were a file on disk. An application
`
`can “write” to a socket (send messages over the network to an application
`
`executing on a remote computer) as if it were writing to file and “read” from
`
`a socket (receive a message from an application on a remote computer) as if
`
`it were reading data from a file.
`
`42. An application invokes the functions of the sockets API by using a specified
`
`syntax. (Ex. 1006, Peterson & Davie, at 5–6.) For example, an application
`
`
`
`20
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`can read from a socket by calling the “select()” function on a socket. (See
`
`Ex. 1014, Stevens, Unix Network Programming (Vol. 1, Ed. 2 (1998)), at
`
`21.) Using select(), a process (of an application) can be woken up when
`
`“any of the descriptors”—e.g., a socket—“is ready for reading.” (Id.) When
`
`the select() call “returns that the socket is readable,” the application can then
`
`request the data be provided. (Id. at 18.) Similar functionality is provided
`
`by poll() and recv() (or “receive”) functions. (See id. at 40 (describing poll()
`
`as providing “similar functionality to select”).) These various “read”
`
`functions differ in the manner in which they deal with certain situations,
`
`such as an application attempting to read form a socket when no message
`
`has been sent (when there is nothing to currently read).
`
`E.
`
`Lazy Protocol Processing
`
`43. When attempting to receive data from the network, protocol processing was
`
`traditionally performed by the operating system immediately upon receipt of
`
`data over the network. This is sometimes referred to as “interrupt-driven” or
`
`“eager” processing. (See, e.g., Ex. 1004, Druschel and Banga, “Lazy
`
`Receiver Processing (LRP): A Network Subsystem Architecture for Server
`
`Systems” at 11.) The ’558 Patent similarly explains that in the “normal
`
`route” for protocol processing, the network interface “sets an interrupt”
`
`when it receives data and “[i]n response to the interrupt the operating system
`
`
`
`21
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`performs protocol processing of the received data.” (Ex. 1002, ’558 Patent,
`
`col. 43, ll. 41–53.) Because operating system protocol processing is given
`
`priority over other running processes, applications are interrupted to perform
`
`the protocol processing, and reduced application performance can result. In
`
`particular, this “leads to scheduling anomalies, decreased throughput, and
`
`potential resource starvation of applications.” (Ex. 1004, Druschel, at 9; see
`
`also Ex. 1002, ’558 Patent at col. 43, ll. 57–65 (“The normal route
`
`[operating system protocol processing] has a number of disadvantages. One
`
`significant disadvantage is the need for context switching whenever data is
`
`received from the NIC. When the data is received the processor 5 may be
`
`executing a program thread. That thread must be temporarily suspended and
`
`a new thread executed in order to allow the operating system to process the
`
`received data. Then the original thread is resumed. This switching of
`
`threads significantly reduces the performance of the data processing
`
`system.”).)
`
`44. Prior art solutions to this problem existed. For example, one solution was to
`
`avoid performing protocol processing on data upon receipt of the data over
`
`the network. Instead, the system performs protocol processing “lazily”—
`
`that is, only when an application requests the received data. (See, e.g., Ex.
`
`1004, Druschel, at 12 (“Whenever the protocol semantics allow it, protocol
`
`
`
`22
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`processing is performed lazily, in the context of the user process performing
`
`a receive system call. . . This avoids inappropriate context switches and can
`
`increase performance.”); Ex. 1003, Mansley, at 11 (“For receives, protocol
`
`processing is done lazily (i.e. when the application asks for it). This should
`
`result in improved cache performance as the data is touched by the stack just
`
`before the application makes use of it.”) (citing Druschel).) I provide further
`
`discussion of this prior art solution below as part of my invalidity analysis.
`
`F.
`
`The ’558 Patent
`
`45. The ’558 Patent relates to processing network traffic in a data processing
`
`system. (Ex. 1002, ’558 Patent, at col. 42, ll. 51–52.) The ’558 Patent
`
`discusses the alleged invention in the context of a typical computer system,
`
`comprising “an operating system” and “one or more application programs,”
`
`wherein the “operating system operates in the normal way to support the
`
`application programs, and control access by the applications to hardware
`
`resources” such as “memory” and “the network interface device.” (Id. at
`
`col. 42, l. 64–col. 43, l. 2.) The “network interface device” is described as
`
`including components “arranged for processing network traffic being
`
`transmitted or received over the network,” and “may conveniently be termed
`
`a network interface card (NIC).” (Id. at col. 43, ll. 3–14.)
`
`
`
`23
`
`
`
`Declaration of Kevin Jeffay under 37 C.F.R. § 1.68
`
`
`46. The core of the alleged invention of the ’558 Patent is the so-called
`
`“protocol processing entity,” which is software that performs protocol
`
`processing on data received from the network. (Id. at col. 44, ll. 19–29.)
`
`This protocol processing entity provides an API for use by applications to
`
`communicate over the network. (Id. at col. 44, ll. 36–37.) The ’558 Patent
`
`describes that one embodiment of the API is the well-known sockets API.
`
`(Id. at col. 3, ll. 16–21 (“Fig. 2 shows components implementing a TCP
`
`stack for use in accordance with embodiments of the present invention.
`
`Layers of the stack include an application 1 and a socket 2 provided by a
`
`socket library. The socket library is an application program interface (API)
`
`for building software applications.”).)
`
`47. The ’558 Patent also discloses that, in one embodiment, the protocol
`
`processing entity runs at a “higher level than the operating system, most
`
`preferably at a user level.” (Id. at col. 44, ll. 30–33.) Said another way, the
`
`protocol processing entity may be implemented outside of the operating
`
`system, at the level of an application, rather than as a module within the
`
`operating system. This embodim