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