`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`________________
`
`
`CAVIUM, INC.,
`
`Petitioners,
`
`v.
`
`ALACRITECH INC.,
`
`Patent Owner.
`________________
`
`Case IPR2018-00400
`U.S. Patent 7,124,205
`________________
`
`
`
`PATENT OWNER’S EXHIBIT 2003
`
`DECLARATION OF KEVIN ALMEROTH, PH.D.
`
`
`
`
`
`Alacritech Exhibit 2003
`
`
`
`
`
`1.
`
`I have been retained on behalf of Alacritech, Inc. (“Alacritech” or
`
`“Patent Owner”) in connection with the above-captioned inter partes review (IPR).
`
`I understand that on December 27, 2017, Cavium, Inc. (“Cavium”) filed this Third
`
`Petition (Paper 1, IPR 2018-00400, hereinafter “Third Petition”) requesting IPR of
`
`claims 1, 4-8, 11, and 13 (“the Challenged Claims”) of U.S. Patent No. 7,124,205
`
`(“the ‘205 patent”). 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 $600 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:
`
`A Reduced Operation Protocol Engine (ROPE) for a
`multiple-layer bypass architecture (Ex. 1015, “Thia”),
`an academic article theorizing a potential processor
`architecture for “bypassing” certain layers in the OSI
`model.
`
`3.
`
`I have also considered all other materials cited and discussed in the
`
`Third Petition.
`
`4.
`
`The ’205 Patent describes a novel system for accelerating network
`
`processing. An intelligent network interface card (INIC) communicates with a
`
`host computer. The INIC “provides hardware and processing mechanisms for
`
`accelerating data transfers between the host and a network.” (Ex. 1001.001 at
`
`
`
`
`Alacritech Exhibit 2003, Page 1
`
`
`
`
`
`Abstract.) “Some data transfers are processed using a dedicated fast-path where by
`
`the protocol stack of the host performs no network layer or transport layer
`
`processing.” (Id.)
`
`5.
`
`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
`
`6. My qualifications can be found in my Curriculum Vitae, which
`
`includes a complete list of my publications. (Ex. 2005.)
`
`7.
`
`I am currently a Professor in the Department of Computer Science at
`
`the University of California, Santa Barbara. I also hold an appointment and am a
`
`founding member of the Computer Engineering (CE) Program at UCSB. I am also
`
`a founding member of the Media Arts and Technology (MAT) Program, and the
`
`Technology Management Program (TMP) at UCSB. I also served as the Associate
`
`Director of the Center for Information Technology and Society (CITS) at UCSB
`
`from 1999 to 2012. I have been a faculty member at UCSB since July 1997.
`
`8.
`
`I hold three degrees from the Georgia Institute of Technology: (1) a
`
`Bachelor of Science degree in Information and Computer Science (with minors in
`
`
`
`
`Alacritech Exhibit 2003, Page 2
`
`
`
`
`
`Economics, Technical Communication, and American Literature) earned in June,
`
`1992; (2) a Master of Science degree in Computer Science (with specialization in
`
`Networking and Systems) earned in June, 1994; and (3) a Doctor of Philosophy
`
`(Ph.D.) degree in Computer Science (Dissertation Title: Networking and System
`
`Support for the Efficient, Scalable Delivery of Services in Interactive Multimedia
`
`System), minor in Telecommunications Public Policy, earned in June, 1997.
`
`9.
`
`One of the major themes of my research has been the delivery of
`
`multimedia content and data between computing devices and users. In my research
`
`I have looked at large-scale content delivery systems and the use of servers located
`
`in a variety of geographic locations to provide scalable delivery to hundreds, or
`
`even thousands, of users simultaneously. I have also looked at smaller-scale
`
`content delivery systems in which content, including interactive communication
`
`like voice and video data, is exchanged between computers and portable
`
`computing devices. As a broad theme, my work has examined how to exchange
`
`content more efficiently across computer networks, including the devices that
`
`switch and route data traffic. More specific topics of my work include the scalable
`
`delivery of content to many users, mobile computing, satellite networking,
`
`delivering content to mobile devices, and network support for data delivery in
`
`wireless and sensor networks.
`
`
`
`
`Alacritech Exhibit 2003, Page 3
`
`
`
`
`
`10. Beginning in 1992, at the time I started graduate school, the initial
`
`focus of my research was the provision of interactive functions (e.g., VCR-style
`
`functions like pause, rewind, and fast-forward) for near video-on-demand systems
`
`in cable systems, in particular, how to aggregate requests for movies at a cable
`
`head-end and then how to satisfy a multitude of requests using one audio/video
`
`stream to broadcast to multiple receivers simultaneously. Continued evolution of
`
`this research has resulted in the development of new techniques to scalably deliver
`
`on-demand content, including audio, video, web documents, and other types of
`
`data, through the Internet and over other types of networks, including over cable
`
`systems, broadband telephone lines, and satellite links.
`
`11. An important component of my research from the very beginning has
`
`been investigating the challenges of communicating multimedia content between
`
`computers and across networks. Although the early Internet was designed mostly
`
`for text-based non-real time applications, the interest in sharing multimedia content
`
`quickly developed. Multimedia-based applications ranged from downloading
`
`content to a device for streaming multimedia content to be instantly used. One of
`
`the challenges was that multimedia content is typically larger than text-only
`
`content, but there are also opportunities to use different delivery techniques
`
`because multimedia content is more resilient to errors. I have worked on a variety
`
`
`
`
`Alacritech Exhibit 2003, Page 4
`
`
`
`
`
`of research problems and used a number of systems that were developed to deliver
`
`multimedia content to users.
`
`12.
`
`In 1994, I began to research issues associated with the development
`
`and deployment of a one-to-many communication facility (called “multicast”) in
`
`the Internet (first deployed as the Multicast Backbone, a virtual overlay network
`
`supporting one-to-many communication). Some of my more recent research
`
`endeavors have looked at how to use the scalability offered by multicast to provide
`
`streaming media support for complex applications like distance learning,
`
`distributed collaboration, distributed games, and large-scale wireless
`
`communication. Multicast has also been used as the delivery mechanism in
`
`systems that perform local filtering (i.e., sending the same content to a large
`
`number of users and allowing them to filter locally content in which they are not
`
`interested).
`
`13. Starting in 1997, I worked on a project to integrate the streaming
`
`media capabilities of the Internet together with the interactivity of the web. I
`
`developed a project called the Interactive Multimedia Jukebox (IMJ). Users would
`
`visit a web page and select content to view. The content would then be scheduled
`
`on one of a number of channels, including delivery to students in Georgia Tech
`
`dorms delivered via the campus cable plant. The content of each channel was
`
`delivered using multicast communication.
`
`
`
`
`Alacritech Exhibit 2003, Page 5
`
`
`
`
`
`14.
`
`In the IMJ, the number of channels varied depending on the
`
`capabilities of the server including the available bandwidth of its connection to the
`
`Internet. If one of the channels was idle, the requesting user would be able to
`
`watch their selection immediately. If all channels were streaming previously
`
`selected content, the user’s selection would be queued on the channel with the
`
`shortest wait time. In the meantime, the user would see what content was currently
`
`playing on other channels, and because of the use of multicast, would be able to
`
`join one of the existing channels and watch the content at the point it was currently
`
`being transmitted.
`
`15. The IMJ service combined the interactivity of the web with the
`
`streaming capabilities of the Internet to create a jukebox-like service. It supported
`
`true Video-on-Demand when capacity allowed, but scaled to any number of users
`
`based on queuing requested programs. As part of the project, we obtained
`
`permission from Turner Broadcasting to transmit cartoons and other short-subject
`
`content. We also attempted to connect the IMJ into the Georgia Tech campus
`
`cable television network so that students in their dorms could use the web to
`
`request content and then view that content on one of the campus’s public access
`
`channels.
`
`16. More recently, I have also studied issues concerning how users choose
`
`content, especially when considering the price of that content. My research has
`
`
`
`
`Alacritech Exhibit 2003, Page 6
`
`
`
`
`
`examined how dynamic content pricing can be used to control system load. By
`
`raising prices when systems start to become overloaded (i.e., when all available
`
`resources are fully utilized) and reducing prices when system capacity is readily
`
`available, users’ capacity to pay as well as their willingness can be used as factors
`
`in stabilizing the response time of a system. This capability is particularly useful
`
`in systems where content is downloaded or streamed on-demand to users.
`
`17. As a parallel research theme, starting in 1997, I began researching
`
`issues related to wireless devices and sensors. In particular, I was interested in
`
`showing how to provide greater communication capability to “lightweight
`
`devices,” i.e., small form-factor, resource-constrained (e.g., CPU, memory,
`
`networking, and power) devices. Starting by at least 2004, I researched techniques
`
`to wirelessly disseminate information, for example, advertisements between users
`
`using ad hoc networks. In the system, called Coupons, an incentive scheme is used
`
`to encourage users to relay information, including advertisements, to other nearby
`
`users.
`
`18. Starting in 1998, I published several papers on my work to develop a
`
`flexible, lightweight, battery-aware network protocol stack. The lightweight
`
`protocols we envisioned were similar in nature to protocols like Universal Plug and
`
`Play (UPnP) and Digital Living Network Alliance (DLNA).
`
`
`
`
`Alacritech Exhibit 2003, Page 7
`
`
`
`
`
`19. From this initial work, I have made wireless networking—including
`
`ad hoc, mesh networks and wireless devices—one of the major themes of my
`
`research. One topic includes developing applications for mobile devices, for
`
`example, virally exchanging and tracking “coupons” through “opportunistic
`
`contact” (i.e., communication with other devices coming into communication
`
`range with a user). Other topics include building network communication among a
`
`set of mobile devices unaided by any other kind of network infrastructure. Yet
`
`another theme is monitoring wireless networks, in particular different variants of
`
`IEEE 802.11 compliant networks, to (1) understand the operation of the various
`
`protocols used in real-world deployments, (2) use these measurements to
`
`characterize use of the networks and identify protocol limitations and weaknesses,
`
`and (3) propose and evaluate solutions to these problems.
`
`20. Protecting networks, including their operation and content, has been
`
`an underlying theme of my research almost since the beginning. Starting in 2000, I
`
`have also been involved in several projects that specifically address security,
`
`network protection, and firewalls. After significant background work, a team on
`
`which I was a member successfully submitted a $4.3M grant proposal to the Army
`
`Research Office (ARO) at the Department of Defense to propose and develop a
`
`high-speed intrusion detection system. Once the grant was awarded, we spent
`
`several years developing and meeting the milestones of the project. I have also
`
`
`
`
`Alacritech Exhibit 2003, Page 8
`
`
`
`
`
`used firewalls in developing techniques for the classroom to ensure that students
`
`are not distracted by online content.
`
`21. As an important component of my research program, I have been
`
`involved in the development of academic research into available technology in the
`
`market place. One aspect of this work is my involvement in the Internet
`
`Engineering Task Force (IETF) including many content delivery-related working
`
`groups like the Audio Video Transport (AVT) group, the MBone Deployment
`
`(MBONED) group, Source Specific Multicast (SSM) group, the Inter-Domain
`
`Multicast Routing (IDMR) group, the Reliable Multicast Transport (RMT) group,
`
`the Protocol Independent Multicast (PIM) group, etc. I have also served as a
`
`member of the Multicast Directorate (MADDOGS), which oversaw the
`
`standardization of all things related to multicast in the IETF. Finally, I was the
`
`Chair of the Internet2 Multicast Working Group for seven years.
`
`22.
`
`I am an author or co-author of approximately 200 technical papers,
`
`published software systems, IETF Internet Drafts and IETF Request for Comments
`
`(RFCs). A list of these papers is included in my CV, which is attached as Exhibit
`
`2005.
`
`23. My involvement in the research community extends to leadership
`
`positions for several journals and conferences. I am the co-chair of the Steering
`
`Committee for the ACM Network and System Support for Digital Audio and
`
`
`
`
`Alacritech Exhibit 2003, Page 9
`
`
`
`
`
`Video (NOSSDAV) workshop and on the Steering Committees for the
`
`International Conference on Network Protocols (ICNP), ACM Sigcomm
`
`Workshop on Challenged Networks (CHANTS), and IEEE Global Internet (GI)
`
`Symposium. I have served or am serving on the editorial boards of IEEE/ACM
`
`Transactions on Networking, IEEE Transactions on Mobile Computing, IEEE
`
`Transactions on Networks and System Management, IEEE Network, ACM
`
`Computers in Entertainment, AACE Journal of Interactive Learning Research
`
`(JILR), and ACM Computer Communications Review.
`
`24. Furthermore, in the courses I teach, the class spends significant time
`
`covering all aspects of the Internet including each of the layers of the Open System
`
`Interconnect (OSI) protocol stack commonly used in the Internet. These layers
`
`include the physical and data link layers and their handling of signal modulation,
`
`error control, and data transmission. I also teach DOCSIS, DSL, and other
`
`standardized protocols for communicating across a variety of physical media
`
`including cable systems, telephone lines, wireless, and high-speed Local Area
`
`Networks (LANs). I teach the configuration and operation of switches, routers, and
`
`gateways including routing and forwarding and the numerous respective protocols
`
`as they are standardized and used throughout the Internet. Topics include a wide
`
`variety of standardized Internet protocols at the Network Layer (Layer 3),
`
`Transport Layer (Layer 4), and above.
`
`
`
`
`Alacritech Exhibit 2003, Page 10
`
`
`
`
`
`25.
`
`In addition, I co-founded a technology company called Santa Barbara
`
`Labs that was working under a sub-contract from the U.S. Air Force to develop
`
`very accurate emulation systems for the military’s next generation internetwork.
`
`Santa Barbara Labs’ focus was in developing an emulation platform to test the
`
`performance characteristics of the network architecture in the variety of
`
`environments in which it was expected to operate, and in particular, for network
`
`services including IPv6, multicast, Quality of Service (QoS), satellite-based
`
`communication, and security. Applications for this emulation program included
`
`communication of a variety of multimedia-based services.
`
`26.
`
`In addition to having co-founded a technology company myself, I
`
`have worked for, consulted with, and collaborated with companies such as IBM,
`
`Hitachi Telecom, Digital Fountain, RealNetworks, Intel Research, Cisco Systems,
`
`and Lockheed Martin.
`
`27.
`
`I am a Member of the Association of Computing Machinery (ACM)
`
`and a Fellow of the Institute of Electrical and Electronics Engineers (IEEE).
`
`28. Additional details about my employment history, fields of expertise,
`
`and publications are further included in my curriculum vitae, attached as Exhibit
`
`2005.
`
`29. From my education, teaching, and consulting experience, I am
`
`familiar with networking protocols in general and in particular the TCP/IP
`
`
`
`
`Alacritech Exhibit 2003, Page 11
`
`
`
`
`
`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
`
`A. The Person of Ordinary Skill in the Art
`
`30.
`
`I understand that a person of ordinary skill in the relevant art (also
`
`referred to herein as “POSITA”) 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.
`
`31.
`
`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.
`
`32. 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
`
`
`
`
`Alacritech Exhibit 2003, Page 12
`
`
`
`
`
`herein around the October 1997 timeframe. I have been advised that the earliest
`
`possible effective filing date of the ’205 Patent is October 14, 1997.
`
`33.
`
`In my opinion, a POSITA at that time would be a person with a
`
`Bachelor's degree in Computer Science, Computer Engineering, or the equivalent,
`
`and several years’ experience in the fields of computer networking and/or
`
`networking protocols.
`
`34.
`
`I am well-qualified to determine the level of ordinary skill in the art
`
`and am personally familiar with the technology of the ’205 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.
`
`35.
`
`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 POSITA would have
`
`understood something as of the alleged effective filing date of the ’205 Patent.
`
`B. My Understanding of Obviousness Law
`
`36.
`
`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
`
`
`
`
`Alacritech Exhibit 2003, Page 13
`
`
`
`
`
`by technical experts in forming opinions regarding the meaning and validity of
`
`patent claims.
`
`37.
`
`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.
`
`38. 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.
`
`39.
`
`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.
`
`
`
`
`Alacritech Exhibit 2003, Page 14
`
`
`
`
`
`40.
`
`I understand that in evaluating the validity of the ’205 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
`
`41.
`
`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.
`
`42.
`
`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.
`
`43.
`
`In this Declaration, I have used the broadest reasonable interpretation
`
`standard when interpreting the claim terms. I reserve my right to amend or alter
`
`my analysis and opinions in view of the Patent Owner’s proposed claim
`
`constructions, if any.
`
`
`
`
`Alacritech Exhibit 2003, Page 15
`
`
`
`
`
`IV. THE ’205 PATENT
`
`A. Overview
`
`44. The ’205 Patent, titled “Network Interface Device That Fast-Path
`
`Process Solicited Session Layer Read Commands,” 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.)
`
`45. As explained in the background of the ’205 Patent, when a
`
`conventional network interface card prepares to send data from a first host to a
`
`second host, “data is divided into packets for transportation over the network, with
`
`each packet encapsulated in layers of control information that are processed one
`
`layer at a time by the CPU of the receiving computer.” (Id. at 1:49-52.) 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.
`
`
`
`
`Alacritech Exhibit 2003, Page 16
`
`
`
`
`
`46. 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 1:49-52.) 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.
`
`47. Because the processing of each layer typically involves a copy and
`
`data manipulation operation (for example a checksum generation or validation
`
`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. An interrupt alerts the
`
`processor to a high-priority condition requiring the interruption of the current code
`
`the processor is executing. 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. Frequent interrupts to the host CPU can be very
`
`
`
`
`Alacritech Exhibit 2003, Page 17
`
`
`
`
`
`disruptive to the host system generally and cause system instability and degraded
`
`system performance.
`
`48. The invention of the ’205 Patent includes a “fast-path” where the host
`
`CPU is relieved of certain TCP/IP processing, which is instead performed by the
`
`INIC.
`
`49. FIG. 1 of the ’205 patent below is a plan view diagram of a network
`
`storage system including a host computer connected to plural networks by an
`
`intelligent network interface card (INIC) having an I/O controller and file cache for
`
`a storage unit attached to the INIC.
`
`
`
`
`Alacritech Exhibit 2003, Page 18
`
`
`
`
`
`
`
`50. The claimed arrangement allows for enhanced network and system
`
`performance, a stark reduction or elimination of interrupts seen by the host CPU,
`
`faster data throughput, increased system stability, and an overall better user
`
`experience.
`
`B.
`
`The ’205 Patent Claims
`
`51. The ‘205 patent includes thirty-six claims. Claims 1, 4-8, 11 and 13
`
`have been challenged in Cavium’s Third Petition. Of the Challenged Claims,
`
`claims 1 and 8 are independent claims, which the other Challenged Claims depend
`
`on.
`
`52. Claim 1 reads as follows:
`
`Claim 1. An apparatus comprising:
`
`
`
`a host computer having a protocol stack and a
`
`destination memory, the protocol stack including a
`
`session layer portion, the session layer portion being for
`
`processing a session layer protocol; and
`
`
`
`a network interface device coupled to the host
`
`computer, the network interface device receiving from
`
`outside the apparatus a response to a solicited read
`
`command, the solicited read command being of the
`
`session layer protocol, performing fast-path processing
`
`on the response such that a data portion of the response
`
`is placed into the destination memory without the
`
`protocol stack of the host computer performing any
`
`
`
`
`Alacritech Exhibit 2003, Page 19
`
`
`
`
`
`network
`
`layer processing or any
`
`transport
`
`layer
`
`processing on the response.
`
`(Ex. 1001.)
`
`53. Claim 8 reads as follows:
`
`Claim 8. A method, comprising:
`
`
`
`issuing a read request to a network storage device,
`
`the read request passing through a network to the
`
`network storage device;
`
`
`
`receiving on a network interface device a packet
`
`from the network storage device in response to the read
`
`request, the packet including data, the network interface
`
`device being coupled to a host computer by a bus, the
`
`host computer having a protocol stack for carrying out
`
`network layer and transport layer processing;
`
`
`
`performing fast-path processing on the packet such
`
`that the data is placed into a destination memory without
`
`the protocol stack of the host computer doing any
`
`network layer processing on the packet and without the
`
`protocol stack of the host computer doing any transport
`
`layer processing on the packet;
`
`
`
`receiving on the network interface device a
`
`subsequent packet from the network storage device in
`
`response to the read request, the subsequent packet
`
`including subsequent data; and
`
`
`
`performing
`
`slow-path
`
`processing
`
`on
`
`the
`
`subsequent packet such that the protocol stack of the host
`
`
`
`
`Alacritech Exhibit 2003, Page 20
`
`
`
`
`
`computer does network layer processing and transport
`
`layer processing on the subsequent packet.
`
`(Ex. 1001.)
`
`V. CLAIM CONSTRUCTION
`
`54. The Third Petition does not assert that the challenged claims require
`
`express construction by the Board. I have accepted the Third Petition’s position
`
`for purposes of this Preliminary Response.
`
`VI. OVERVIEW OF THE PRIOR ART
`
`A. Thia, A Reduced Operation Protocol Engine (ROPE) for a multiple-
`layer bypass architecture (“Thia”)
`
`55. Thia is an academic article theorizing a potential processor
`
`architecture for “bypassing” protocol processing functions within certain layers in
`
`the OSI model, and describes itself as a “feasibility study for a new approach to
`
`hardware assistance.” (Ex. 1015.002.) Thia explicitly declined to create a real-
`
`world device, noting that the “final step of generating a chip layout for
`
`fabrication and fault analysis was not performed.” (Ex. 1015.008.) Thus Thia
`
`presents a feasibility study on the theoretical benefits of bypassing certain layers in
`
`the OSI model. (Ex. 1015.013 (“It can be concluded from this study that it is
`
`feasible to implement the bypass stack (at least for the transport and session layers)
`
`. . . .”)
`
`56. Accordingly, Thia discloses (at best) an inoperative device, and is a
`
`non-enabling reference. (See id.) Thia fails to teach much of the subject matter of
`
`
`
`
`Alacritech Exhibit 2003, Page 21
`
`
`
`
`
`the Challenged Claims. Thia’s feasibility study describes—at a high level—the
`
`idea of offloading presentation, session and transport layer processing to a
`
`Reduced Operation Protocol Engine (“ROPE”) chip, but does not disclose many of
`
`the implementation details required to enable the implementation, let alone enable
`
`it for use with TCP/IP.
`
`57. Thia describes a bypass stack on the ROPE chip that provides a
`
`hardware “fast path” for bulk data transfer. (Ex. 1015.002-003.) Thia’s disclosure
`
`of the ROPE bypass architecture consists of bare flowcharts shown below, which
`
`lack implementation details necessary to implement the device:
`
`
`
`
`Alacritech Exhibit 2003, Page 22
`
`
`
`
`
`
`
`(Ex. 1015.003.)
`
`58. Thia discloses its proposed architecture is applicable to both
`
`transmission and reception of packets at a host computer system. With respect to
`
`reception of packets, which Thia refers to as “Protocol Data Units” or “PDUs,”
`
`Thia discloses the bypass architecture performs a “receive bypass test” (“RX
`
`Bypass Test” in Fig. 1, above) to determine whether certain processing of the
`
`received PDU may be performed by the ROPE chip instead of the Standard
`
`Protocol Stack (or “SPS”) of the host computer system. For example, Thia
`
`theorizes that certain procedures performed in the presentation, session, and
`
`transport layers of OSI protocols may be performed by the ROPE chip as opposed
`
`to the host. These procedures are identified in Table 1 and include such procedures
`
`as header decoding and checking checksums, among others:
`
`
`
`
`Alacritech Exhibit 2003, Page 23
`
`
`
`
`
`
`
`(Ex. 1015.006.)
`
`
`
`59. When a PDU is received, Thia determines whether the ROPE chip
`
`may perform bypassable functions for that PDU by executing the “receive bypass
`
`test.” According to Thia, the receive bypass test matches the header of the
`
`incoming PDU with a template using header prediction:
`
`
`
`
`Alacritech Exhibit 2003, Page 24
`
`
`
`
`
`
`
`(Ex. 1015.003.) However, Thia does not address or disclose how the bypass test is
`
`implemented, what values of the incoming headers must match the template in
`
`order to identify predicted bypassable headers, or what the template even is.