throbber

`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`___________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`___________________
`
`
`INTEL CORPORATION,
`Petitioner
`
`v.
`
`ALACRITECH INC.,
`Patent Owner
`
`___________________
`
`Case IPR2017-01713
`Patent No. 7,337,241
`___________________
`
`
`
`
`
`
`PATENT OWNER’S EXHIBIT 2001
`DECLARATION OF PAUL PRUCNAL, PH.D.
`
`
`06973-00001/9638491.1
`
`
`
`
`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 reference:
`
`Connery (Ex. 1043) is U.S. Patent No. 5,937,169, which
`issued on August 10, 1999 and is assigned to 3Com
`Corporation.
`
`I have also considered all other materials cited and discussed herein,
`
`3.
`
`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
`
`06973-00001/9638491.1
`
`
`Short Name
`
`Interrupts
`
`Exhibit
`Jonathan Corbet; Alessandro Rubini; Greg
`Kroah-Hartman (2005), Linux Device Drivers,
`Alacritech Exhibit 2001, Page 1
`
`

`

`
`
`Claim
`Construction
`Order
`
`3rd edition, Chapter 10, “Interrupt Handling”
`Memorandum Opinion and Order on Claim
`Construction, Case No. 2:16-cv-00693-JRG-
`RSP, Dkt. 362 (E.D. Tex., September 21, 2017)
`
`The ’241 Patent describes a system for protocol processing in a
`
`2006
`
`5.
`
`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 f or 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
`
`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
`
`
`1 The ’241 Patent claims the benefit of U.S. Provisional App. Ser. No.
`
`60/061,809, filed on Oct. 14, 1997.
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 2
`
`

`

`
`
`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.
`
`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
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 3
`
`

`

`
`
`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
`
`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
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 4
`
`

`

`
`
`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
`
`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.
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 5
`
`

`

`
`
`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.
`
`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
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 6
`
`

`

`
`
`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.
`
`25.
`
`In 2006-2008, I led a DARPA-funded project developing an add drop
`
`multiplexer for a metropolitan area networks.
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 7
`
`

`

`
`
`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.
`
`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),
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 8
`
`

`

`
`
`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
`
`controller. I am also familiar with the technologies sometimes referred to as Large
`
`Segmentation Offload (LSO) and Receive Side Coalescing (RSC).
`
`III. LEGAL UNDERSTANDING
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 9
`
`

`

`
`
`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:
`
`• 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.
`
`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.
`
`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
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 10
`
`

`

`
`
`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.
`
`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.
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 11
`
`

`

`
`
`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
`
`(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
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 12
`
`

`

`
`
`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
`
`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.
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 13
`
`

`

`
`
`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
`
`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
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 14
`
`

`

`
`
`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
`
`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
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 15
`
`

`

`
`
`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
`
`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
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 16
`
`

`

`
`
`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
`
`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
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 17
`
`

`

`
`
`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
`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.).
`Alacritech Exhibit 2001, Page 18
`06973-00001/9638491.1
`
`
`

`

`
`
`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
`
`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
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 19
`
`

`

`
`
`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.
`
`
`
`06973-00001/9638491.1
`
`
`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
`
`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
`
`06973-00001/9638491.1
`
`
`Alacritech Exhibit 2001, Page 21
`
`

`

`
`
`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
`
`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 a

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket