IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`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.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`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
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
