`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`___________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`___________________
`
`
`INTEL CORPORATION,
`Petitioner
`
`v.
`
`ALACRITECH INC.,
`Patent Owner
`
`___________________
`
`Case IPR2017-01392
`Patent No. 7,337,241
`___________________
`
`
`
`
`
`
`PATENT OWNER’S EXHIBIT 2001
`DECLARATION OF PAUL PRUCNAL, PH.D.
`
`
`
`
`
`
`
`Alacritech Exhibit 2001
`
`
`
`
`
`1.
`
`I have been retained on behalf of Alacritech, Inc. (“Alacritech” or
`
`“Patent Owner”) for the above-captioned inter partes review (IPR) proceeding. I
`
`understand that this proceeding was filed by Intel Corporation (“Intel”) and
`
`involves U.S. Patent No. 7,337,241 (“the ’241 Patent”), titled “Fast-path apparatus
`
`for receiving data corresponding to a TCP connection.” The ’241 Patent is
`
`currently assigned to Alacritech. I have been retained to provide my opinions in
`
`support of Alacritech’s Preliminary Response Pursuant to 35 U.S.C. § 313 and 37
`
`C.F.R. § 42.107 pursuant to the legal standards set forth below. I am being
`
`compensated for my time at the rate of $650 per hour. I have no interest in the
`
`outcome of this proceeding.
`
`2.
`
`In preparing this declaration, I have reviewed and am familiar with the
`
`following prior art references:
`
`Erickson (Ex. 1005) is U.S. Patent No. 5,768,618, which
`issued on June 16, 1998 and is assigned to NCR
`Corporation.
`
`Tanenbaum (Ex. 1006) is the 3rd edition of a textbook
`entitled Computer Networks by Andrew S. Tanenbaum.
`
`Alteon (Ex. 1033) is the 1st edition of a technical brief
`entitled “Gigabit Ethernet Technical Brief: Achieving
`End-to-End Performance” by Alteon Networks, Inc.
`
`
`
`
`
`Alacritech Exhibit 2001, Page 1
`
`
`
`
`
`3.
`
`I have also considered all other materials cited and discussed herein,
`
`including all other materials cited and discussed in Intel’s Petition for Inter Partes
`
`Review of U.S. Patent No. 7,337,241 (Case IPR2017-01392).
`
`4.
`
`I have also considered the following:
`
`No.
`
`2004
`
`2006
`
`5.
`
`Short Name
`
`Interrupts
`
`Exhibit
`Jonathan Corbet; Alessandro Rubini; Greg
`Kroah-Hartman (2005), Linux Device Drivers,
`3rd edition, Chapter 10, “Interrupt Handling”
`January 13, 1997 Wayback Machine Archive of
`www.alteon.com homepage, available at
`https://web.archive.org/web/19970113130740/
`http://www.alteon.com:80/
`
`The ’241 Patent describes a system for protocol processing in a
`
`Alteon ’97
`Homepage
`
`computer network that has an “intelligent network interface card” (INIC) or
`
`“communication processing device” (CPD) associated with a host computer. (Ex.
`
`1001 at Abstract). The INIC provides a “fast-path” that avoids some or all
`
`protocol processing for large multi-packet messages, greatly accelerating data
`
`communication. (Id.) The INIC can also assist the host for those message packets
`
`that are chosen for processing by host software layers. A communication control
`
`block for a message is defined that allows Direct Memory Access (DMA)
`
`controllers of the INIC to move data, free of headers, directly to or from a
`
`destination or source in the host. (Id.) A context, for example, can be stored in the
`
`INIC as a communication control block (CCB) that can be passed back to the host
`
`
`
`
`Alacritech Exhibit 2001, Page 2
`
`
`
`
`
`for message processing by the host. (Id.) I am familiar with the technology
`
`described in the ’241 Patent as of its October 14, 19971 effective filing date.
`
`6.
`
`The statements made herein are based on my own knowledge and
`
`opinion. This Declaration represents only the opinions I have formed to date. I
`
`may consider additional documents as they become available or other documents
`
`that are necessary to form my opinions. I reserve the right to revise, supplement,
`
`or amend my opinions based on new information and on my continuing analysis.
`
`II. QUALIFICATIONS
`7. My qualifications can be found in my Curriculum Vitae, which
`
`includes a complete list of my publications. (Ex. 2010).
`
`8.
`
`I am a professor of Electrical Engineering at Princeton University, in
`
`Princeton, NJ. I received my undergraduate education at Bowdoin College, where
`
`I graduated summa cum laude in 1974 with an A.B. in Mathematics and Physics. I
`
`then graduated from Columbia University in 1976 with a M.S. in Electrical
`
`Engineering, and went on to receive an M.Phil. from Columbia University in 1978
`
`in Electrical Engineering and a Ph.D. from Columbia University in 1979 in
`
`Electrical Engineering.
`
`
`1 The ’241 Patent claims the benefit of U.S. Provisional App. Ser. No.
`
`60/061,809, filed on Oct. 14, 1997.
`
`
`
`
`Alacritech Exhibit 2001, Page 3
`
`
`
`
`
`9.
`
`Upon graduation from Columbia in 1979, I joined Columbia
`
`University as an Assistant Professor of Electrical Engineering, and in 1984 I was
`
`promoted to Associate Professor. In 1988, I joined the faculty of Princeton
`
`University as an Associate Professor of Electrical Engineering. My responsibilities
`
`included teaching and research. At that time, I also was the Founding Director of
`
`the New Jersey Advanced Technology Center for Photonics and Optoelectronic
`
`Materials. My responsibilities included leading a $10 million research center
`
`involving approximately thirty faculty members.
`
`10.
`
`In 1990, I was promoted to the position of full Professor of Electrical
`
`Engineering at Princeton University. My teaching responsibilities have included
`
`courses in electronic circuits, signal processing, communications and fiber-optic
`
`networks. My broad research interests have included communications networks
`
`and switching, computer interconnects, and network security. I also head the
`
`Lightwave Communications Research Laboratory and the Center for Network
`
`Security and Access at Princeton University, through which much of my present
`
`research is conducted.
`
`11. While at Princeton University, I received several awards and
`
`recognitions, including: (a) becoming a Fellow of the Institute for Electrical and
`
`Electronics Engineers (IEEE) where my fellow citation is, “For contributions to
`
`photonic switching and fiber-optic networks;” (b) becoming a Fellow of the
`
`
`
`
`Alacritech Exhibit 2001, Page 4
`
`
`
`
`
`Optical Society of America (OSA); (c) receiving the Rudolf Kingslake Medal and
`
`Prize from the Society of Photo-Optical Instrumentation Engineers (SPIE) for the
`
`most noteworthy original paper in Optical Engineering, titled, “Self-routing
`
`photonic switching with optically processed control;” (d) receiving the
`
`international Gold Medal Award from the Faculty of Mathematics, Physics, and
`
`Informatics from Comenius University; (e) receiving the Princeton University
`
`Graduate Mentoring Award; (f) receiving the Lifetime Achievement Award for
`
`Excellence in Teaching from the Engineering Council at Princeton; (g) receiving
`
`the Walter Curtis Johnson Prize for Excellence in Teaching; (h) receiving the
`
`Princeton School of Engineering and Applied Science Distinguished Teacher
`
`Award; (i) receiving the President’s Award for Distinguished Teaching at
`
`Princeton.
`
`12.
`
`I am the author of the books, “Optical Code Division Multiple Access:
`
`Fundamentals and Applications” (2005) and “Neuromorphic Photonics (2017),
`
`both of which relate to networking. I am a co-author or contributor to
`
`approximately thirty additional book chapters, as well as over 300 peer-reviewed
`
`publications in peer-reviewed journals and conference proceedings including
`
`papers in the area of communications networks and packet switching.
`
`13.
`
`In addition to the activities, education, and professional experience
`
`listed above, I have been involved in numerous research projects that contribute to
`
`
`
`
`Alacritech Exhibit 2001, Page 5
`
`
`
`
`
`my expertise relating to this report. My work in these projects have included,
`
`among other things, multiple access techniques for high-speed communication
`
`networks and fast packet switching techniques. More information on several of
`
`these research projects is provided below.
`
`14.
`
`In 1982, I worked with Optical Information Systems, Inc. on a project
`
`that involved transceiver design for communications systems. My responsibilities
`
`included the investigation of high-speed clock recovery.
`
`15.
`
`In 1983-1984, I worked with GTE Labs on a project that involved
`
`performance analysis of communication systems. My responsibilities included the
`
`investigation of high performance modulation formats.
`
`16.
`
`In 1985-1986, I worked with AT&T Bell Laboratories on a project
`
`that involved research on multiple access techniques. My responsibilities included
`
`investigating multiplexing techniques for telecommunications networks.
`
`17.
`
`In 1987-1988, I worked with IBM on a project that involved research
`
`on multiple access techniques and switching for computer communication
`
`networks.
`
`18.
`
`In 1987-1989, I worked with Dove Electronics on a project that
`
`involved research on communication switching technology and architectures. My
`
`responsibilities included the design and analysis of fast packet switching
`
`architectures.
`
`
`
`
`Alacritech Exhibit 2001, Page 6
`
`
`
`
`
`19.
`
`In 1992-1995, I worked with Siemens Corporate Research on a
`
`project that involved research on switching technology. My responsibilities
`
`included the investigation of technologies for high speed multiplexing and
`
`switching, and performing an analysis of the potential application of these
`
`technologies to telecommunications networks that carried TCP/IP traffic.
`
`20.
`
`In 1999-2000, I worked with SAIC on a project that involved research
`
`on network architectures. My responsibilities included the investigation of fast
`
`switching and multiplexing techniques for high-speed communication networks.
`
`21.
`
`In 1999-2002, I worked with Multi Link Technologies, Inc. on a
`
`project that involved communication transceiver design. My responsibilities
`
`included the design and analysis of high-speed transmitters and receivers.
`
`22.
`
`In 2000-2002, I worked with Ultra-Fast Optical Systems on a project
`
`that involved research and development on packet switching technology. My
`
`responsibilities included the design and testing of switch technology.
`
`23.
`
`In 2000-2003, I was a member of the advisory board on optical
`
`network technology for Alphion, Inc. My responsibilities included providing
`
`guidance on the development of technology in the communication networks space.
`
`24.
`
`In 2003-2006, I worked with Kailight Inc. on a project that involved
`
`research and development on switching technology. My responsibilities included
`
`the design and testing of an optical switch for communication networks.
`
`
`
`
`Alacritech Exhibit 2001, Page 7
`
`
`
`
`
`25.
`
`In 2006-2008, I led a DARPA-funded project developing an add drop
`
`multiplexer for a metropolitan area networks.
`
`26.
`
`In 2004-2011, I worked with NEC Laboratories on a project that
`
`involved research on physical layer security in communication networks. My
`
`responsibilities included the design and analysis of techniques for steganography
`
`and data encryption.
`
`27.
`
`I am also a named inventor on at least 27 issued U.S. patents, and at
`
`least 5 additional U.S. patent applications.
`
`28.
`
`I have extensive experience in the communication networks field
`
`throughout my career, including being an editor for the IEEE Transactions on
`
`Communications.
`
`29. Also, during the past 10 years I have taught several undergraduate and
`
`graduate courses at Princeton on communications, such as “Photonics and
`
`Lightwave Communications,” which includes digital communications systems and
`
`networks, including protocols such as TCP/IP; “Electronic Circuit Design,” which
`
`covers basic circuit design and implementation; and “An Introduction to
`
`Engineering,” which includes basic communication networks. I am also involved
`
`with independent research projects involving senior thesis works, the majority of
`
`which pertain to communications systems and networking.
`
`
`
`
`Alacritech Exhibit 2001, Page 8
`
`
`
`
`
`30. My research focuses on advanced topics in lightwave and radio
`
`frequency communication systems, networks and switching. My research has been
`
`supported by contracts and grants from the National Science Foundation (NSF),
`
`the U.S. Army Communication Electronics Command, the Office of Naval
`
`Research, the Defense Advanced Research Projects Agency (DARPA) and the
`
`National Security Agency, among others.
`
`31.
`
`I also have extensive experience consulting for the communications
`
`industry, including AT&T Bell Laboratories, NEC Labs, Alphion Inc. and the
`
`Institute for Defense Analyses. In particular, my work at the Institute relates to
`
`computers and communication networks.
`
`32.
`
`I have been a technical advisor to several startup companies in the
`
`telecommunications industry. Based on my patents, Kalight Photonics developed
`
`all-optical communication switching technology, before being acquired by a
`
`publicly traded company. Another company, Bascom Hunter Technologies, in
`
`conjunction with L3 Telemetry East, developed anti-jamming systems for wireless
`
`networks. This work is also based on my patents.
`
`33. From my education, teaching, and consulting experience, I am
`
`familiar with networking protocols in general and in particular the TCP/IP
`
`protocol. I am also familiar with TCP offload engines (sometime referred to as
`
`TOE) that offload the processing of the entire TCP/IP stack to the network
`
`
`
`
`Alacritech Exhibit 2001, Page 9
`
`
`
`
`
`controller. I am also familiar with the technologies sometimes referred to as Large
`
`Segmentation Offload (LSO) and Receive Side Coalescing (RSC).
`
`III. LEGAL UNDERSTANDING
`A. The Person of Ordinary Skill in the Art
`34.
`I understand that a person of ordinary skill in the relevant art (also
`
`referred to herein as “POSA”) is presumed to be aware of all pertinent art, thinks
`
`along conventional wisdom in the art, and is a person of ordinary creativity—not
`
`an automaton.
`
`35.
`
`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
`
`deciding the level of ordinary skill, I considered the following:
`
`(cid:120) the levels of education and experience of persons working in the
`
`field;
`
`(cid:120) the types of problems encountered in the field; and
`
`(cid:120) the sophistication of the technology.
`
`36. My opinion below explains how a person of ordinary skill in the art
`
`would have understood the technology described in the references I have identified
`
`herein around the October 1997 timeframe. I have been advised that the earliest
`
`possible effective filing date of the ’241 Patent is October 14, 1997.
`
`
`
`
`Alacritech Exhibit 2001, Page 10
`
`
`
`
`
`37.
`
`In my opinion, a POSA at that time would be a person with (i.) at least
`
`four years of relevant work or research experience in the field of network
`
`engineering and/or design; (ii.) a Bachelor’s of Science degree in electrical
`
`engineering, computer science, or a related field plus at least two to three years of
`
`relevant work or research experience in the field of network engineering and/or
`
`design, or (iii) an advanced degree (e.g., Master’s or Ph.D.) and one to two years
`
`of relevant work or research experience in the field of network engineering and/or
`
`design.
`
`38.
`
`I am well-qualified to determine the level of ordinary skill in the art
`
`and am personally familiar with the technology of the ’241 Patent in the October
`
`1997 timeframe. By 1997, I had completed my formal education and had been
`
`working in the relevant field as a professor, researcher, or consultant for more than
`
`15 years. I have supervised, recruited, advised, and taught individuals at all levels
`
`of training in the relevant field. I have also worked with individuals in the industry
`
`at all levels of training in the relevant field.
`
`39.
`
`I was a person of at least ordinary skill in the art at this timeframe.
`
`Regardless if I do not explicitly state that my statements below are based on this
`
`timeframe, all of my statements are to be understood as a POSA would have
`
`understood something as of the alleged effective filing date of the ’241 patent.
`
`
`
`
`Alacritech Exhibit 2001, Page 11
`
`
`
`
`
`B. My Understanding of Obviousness Law
`40.
`I am not a lawyer and will not provide any legal opinions. Though I
`
`am not a lawyer, I have been advised that certain legal standards are to be applied
`
`by technical experts in forming opinions regarding the meaning and validity of
`
`patent claims.
`
`41.
`
`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.
`
`42. To obtain a patent, a claimed invention must have, as of the priority
`
`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.
`
`43.
`
`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 singly, or in combination, make the patent obvious; (2) specifically identify
`
`which elements of the patent claim appear in each of the asserted references; and
`
`
`
`
`Alacritech Exhibit 2001, Page 12
`
`
`
`
`
`(3) explain how the prior art references could have been combined to create the
`
`inventions claimed in the asserted claim.
`
`44.
`
`I understand that certain objective indicia can be important evidence
`
`regarding whether a patent is obvious or nonobvious. Such indicia include: (1)
`
`commercial success of products covered by the patent claims; (2) a long-felt need
`
`for the invention; (3) failed attempts by others to make the invention; (4) copying
`
`of the invention by others in the field; (5) unexpected results achieved by the
`
`invention as compared to the closest prior art; (6) praise of the invention by the
`
`infringer or others in the field; (7) the taking of licenses under the patent by others;
`
`(8) expressions of surprise by experts and those skilled in the art at the making of
`
`the invention; and (9) the patentee proceeded contrary to the accepted wisdom of
`
`the prior art.
`
`45.
`
`I understand that in evaluating the validity of the ’241 Patent claims,
`
`the content of a patent or printed publication prior art should be interpreted the way
`
`a person of ordinary skill in the art would have interpreted the prior art as of the
`
`effective filing date (October 1997) of the challenged patent. My full analysis
`
`below is based upon these understandings.
`
`C. My Understanding of Claim Construction
`46.
`I have been instructed by counsel on the law regarding claim
`
`construction and patent claims, and understand that a patent may include two types
`
`
`
`
`Alacritech Exhibit 2001, Page 13
`
`
`
`
`
`of claims––independent claims and dependent claims. An independent claim
`
`stands alone and includes only the features it recites. A dependent claim can
`
`depend from an independent claim or another dependent claim. I understand that a
`
`dependent claim includes all the features that it recites in addition to all of the
`
`features recited in the claim from which it depends.
`
`47.
`
`I understand that in this inter partes review the claims must be given
`
`their broadest reasonable interpretation, but that interpretation must be consistent
`
`with the patent specification.
`
`48.
`
`I understand that claim terms are given their plain and ordinary
`
`meaning as would be understood by a person of ordinary skill in the art, unless the
`
`inventor provides a special meaning for a term.
`
`49.
`
`I understand that if there are specific statements in the specification
`
`that define the invention, those statements are strong evidence of a definition for a
`
`term.
`
`50. Additionally, I understand and have been instructed that, when a
`
`claim’s recitation is purely functional and does not include any definite structure
`
`for performing the function claimed, the term is a “means-plus-function” claim. It
`
`is my understanding that means-plus-function claims are construed using a two-
`
`step process: first, determination of the claimed function, and second, identification
`
`
`
`
`Alacritech Exhibit 2001, Page 14
`
`
`
`
`
`of the corresponding structure. If the term is understood by a POSA as referring to
`
`a particular structure, however, this two-step process is not followed.
`
`51.
`
`I understand and have been instructed that, where the claim uses the
`
`word “means,” there is a presumption that it is a means-plus-function claim term. I
`
`also understand and have been instructed that an applicant for a patent must
`
`disclose adequate structure in the specification to perform the recited function, and
`
`that if adequate structure is not recited, the claim is indefinite. I am further
`
`instructed that when the corresponding structure is a general purpose computer or
`
`microprocessor, the specification must disclose the algorithm or process to be
`
`performed by the general purpose computer or microprocessor, or the claim is
`
`indefinite.
`
`52.
`
`In this Declaration, I have used the broadest reasonable interpretation
`
`(“BRI”) standard when interpreting the claim terms.
`
`53.
`
`I reserve my right to amend or alter my analysis and opinions in view
`
`of the Patent Owner’s proposed claim constructions, if any.
`
`IV. BACKGROUND OF THE TECHNOLOGY DISCLOSED IN THE ’241
`PATENT
`54.
`I understand Petitioner has filed for Inter Partes Review of eight
`
`related Alacritech patents: U.S. Patent No. 7,124,205, 7,237,036, 7,337,241,
`
`7,673,072, 7,945,699, 8,131,880, 8,805,948, and 9,055,104 (“the Alacritech
`
`
`
`
`Alacritech Exhibit 2001, Page 15
`
`
`
`
`
`Patents”). The Alacritech Patents reflect inventions relating to offloading certain
`
`tasks traditionally performed by the CPU to a Network Interface Device.
`
`55. The transmission of data over a network usually requires multiple
`
`steps. For example, the data has to be broken up into packets of a certain size that
`
`can be sent over the network. Information needs to be added to packets that, for
`
`example, helps them get to the right recipient. Then, once the intended recipient
`
`receives the data packets, additional processing often needs to be done. For
`
`example, packets often need to be reassembled and sent to a location in memory
`
`where they can be accessed by programs that use the data.
`
`56. The steps involved in the process of data transmission are each
`
`typically performed by different software, in a particular order, and without
`
`bypassing any steps. This is what is known as a “multi-layered software
`
`architecture.” At each layer, the sending computer performs additional processing
`
`on the data received from the previous layer, for example adding new metadata,
`
`dividing the data into packets, or addressing the data. Once the data reaches the
`
`final layer, it is ready to be transmitted over the network.
`
`57. The receiving computer uses the same multi-layered software
`
`architecture to process incoming data packets. Layers are processed in the reverse
`
`order on the receive-side. So, the network interface layer or physical layer receives
`
`packets from the network medium. Then the data is reassembled and the metadata
`
`
`
`
`Alacritech Exhibit 2001, Page 16
`
`
`
`
`
`is accessed and used to ensure the data is provided to the correct destination and in
`
`the correct format. The data is stored until it is ready to be used by another
`
`program.
`
`58. Although this traditional approach for transferring data is functional
`
`and well-established, it can also be slow and inefficient. The central processor
`
`(CPU), which is responsible for the software layers, uses a lot of processing power
`
`to do this type of layer-by-layer processing. Additionally, moving from one
`
`processing layer to the next may involve making a new copy of the data, further
`
`burdening the CPU.
`
`59.
`
`In the 1990s, network traffic exploded through the advent of the
`
`Internet and related technologies. The burden of traditional layer-by-layer
`
`processing in computer networks—long a recognized but unsolved problem—
`
`became a fundamental threat to the efficient expansion of computer networking
`
`scope and volume. Overburdened host CPUs constituted a bottleneck in a variety
`
`of network computing contexts.
`
`60. Engineers and scientists in both the public and private sectors worked
`
`extensively on the problem of network acceleration throughout the late 1980s and
`
`throughout the 1990s. A few academics and industry groups proposed and/or
`
`theorized that some kind of offloading procedure or architecture could improve
`
`network processing speeds, but none of these proposals was sufficiently developed
`
`
`
`
`Alacritech Exhibit 2001, Page 17
`
`
`
`
`
`or explained to actually solve the growing problem of overburdened network CPUs
`
`by the late 1990s.
`
`61.
`
`It was not enough to simply theorize that processing could be split or
`
`offloaded from the host CPU in a computer network (this is a basic premise of
`
`distributed processing architectures, after all) —there needed to be concrete
`
`solutions as to how this split or offload would be achieved. None of the proposals
`
`in the 1980s and 1990s—including proposed standards—actually solved the
`
`problem of host CPU overload. And many, many engineers and academics were
`
`working directly on this problem over this time period.
`
`62.
`
`In the late 1990s and early 2000s, Alacritech invented several
`
`improvements over the traditional approach to network data processing.
`
`Alacritech’s inventions, which are disclosed and claimed in the Alacritech Patents,
`
`went well beyond earlier theories and proposals that CPU processing could
`
`somehow be offloaded: the Alacritech Patents describe a unique, novel architecture
`
`in which critical portions of network processing are offloaded to a dedicated
`
`processor on a network interface device, rather than a general purpose CPU.
`
`63. The inventions embodied in the Alacritech Patents largely solved the
`
`tricky and growing problem of network host CPU overload, and they were greeted
`
`as paradigm-shifting advances in the industry.
`
`V. THE ’241 PATENT
`
`
`
`
`Alacritech Exhibit 2001, Page 18
`
`
`
`
`
`A. Overview
`64. As explained herein, the ’241 patent describes a novel system for
`
`accelerating network processing. An intelligent network interface card (INIC)
`
`communicates with a host computer. The INIC provides “a fast-path that avoids
`
`protocol processing for most large multi-packet messages, greatly accelerating data
`
`communication.” Ex. 1001 at Abstract. In some embodiments, the INIC
`
`“contains specialized hardware circuits that are much faster at their specific tasks
`
`than a general purpose CPU.” (Id.).
`
`65. As explained in the background of the ’241 patent, when a
`
`conventional network interface card prepares to send data from a first host to a
`
`second host, “some control data is added at each layer of the first host regarding
`
`the protocol of that layer, the control data being indistinguishable from the original
`
`(payload) data for all lower layers of that host.” (Id. at 3:67-4:3). For example, an
`
`application layer attaches an application layer header to the payload data and sends
`
`the combined data to the presentation layer of the sending host, which receives the
`
`combined data, operates on it and adds a presentation layer header to the data,
`
`resulting in another combined data packet. The data resulting from combining the
`
`payload data, application layer header, and presentation layer header is then passed
`
`to the session layer, which performs required operations including attaching a
`
`session layer header to the data and presenting the resulting combination of data to
`
`
`
`
`Alacritech Exhibit 2001, Page 19
`
`
`
`
`
`the transport layer. This process continues as the information moves to lower
`
`layers, with a transport layer header, network layer header, and data link layer
`
`header and trailer attached to the data at each of those layers, with each step
`
`typically including data moving and copying, before sending the data as bit packets
`
`over the network to the second host. (Id. at 4:4-20).
`
`66. This process of adding a layer header to the data from the preceding
`
`layer is sometimes referred to as “encapsulation” because the data and layer header
`
`is treated as the data for the immediately following layer, which, in turn, adds its
`
`own layer header to the data from the preceding layer. Each layer is generally not
`
`aware of which portion of the data from the preceding layer constitutes the layer
`
`header or the user data; as such, each layer treats the data it receives from the
`
`preceding layer as some generic payload. The figure below, which I annotated
`
`with colors, illustrates the encapsulation process. The user data (payload) is
`
`colored in purple. In the example below, layer headers in the form of an
`
`application layer header (in yellow), TCP layer header (in blue), IP layer header (in
`
`orange), and Ethernet header and trailer (in green) each encapsulate the user or
`
`application data received from the layer immediately above.
`
`
`
`
`
`
`Alacritech Exhibit 2001, Page 20
`
`
`
`
`
`
`
`Ex. 1008, Stevens at .034, Figure 1.4 (adapted from Petition at 1).
`
`67. On the receiving side, the receiving host generally performs the
`
`reverse of the sending process, beginning with receiving the bits from the network.
`
`Headers are removed, one at a time, and the received data is processed, in order,
`
`from the lowest (physical) layer to the highest (application) layer before
`
`transmission to a destination within the receiving host (e.g., to the operating system
`
`space where the received data may be used by an application running on the
`
`receiving host). (Ex. 1001 at 4:20-26). Each layer of the receiving host
`
`recognizes and manipulates only the headers associated with that layer, since to
`
`that layer the higher layer header data is included with and indistinguishable from
`
`
`
`
`Alacritech Exhibit 2001, Page 21
`
`
`
`
`
`the payload data. “Multiple interrupts, valuable central processing unit (CPU)
`
`processing time and repeated data copies may also be necessary for the receiving
`
`host to place the data in an appropriate form at its intended destination.” (Id. at
`
`4:30-33).
`
`68. Because the processing of each layer typically involves a copy and
`
`data manipulation operation (for example a checksum computation operation), the
`
`host CPU must be “interrupted” at least one time per layer in order to process the
`
`data and construct (transmit side) or deconstruct (receive side) the packet. An
`
`interrupt is a signal to the processor emitted by hardware or software indicating an
`
`event that needs immediate attention. One popular textbook explains “[a]n
`
`interrupt is simply a signal that the hardware can send when it wants the
`
`processor’s attention.” (Ex. 2004 at 258 (emphasis in original)). The purpose of
`
`the interrupt is to “let the processor know when something has happened.” (Id.)
`
`69. An interrupt alerts the processor to a high-priority condition requiring
`
`the interruption of the current code the processor is executing. The interrupt
`
`process used in connection with traditional network interface cards results in
`
`“repeated copying and interrupts to the CPU” of the host computer. (Ex. 1001 at
`
`5:24-28). When the host CPU is interrupted, it generally must stop all other tasks
`
`it is currently working on, including tasks completely unrelated to the network
`
`processing. “For the most part, a driver need only register a handler for its
`
`
`
`
`Alacritech Exhibit 2001, Page 22
`
`
`
`
`
`device’s interrupts, and handle them properly when they arrive.” (Ex. 2004 at
`
`258). The “interrupt handler” is a piece of software that is executed by the CPU
`
`after receiving the interrupt. “If the [operating system] hasn’t been told to expect
`
`[the] interrupt, it simply acknowledges and ignores it.” (Ex. 2004 at 259). The
`
`role of an interrupt handler “is to give feedback to its device [generating the
`
`interrupt] about interrup