`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`________________
`
`INTEL CORP. and
`CAVIUM, INC.,
`
`Petitioners,
`
`v.
`
`ALACRITECH INC.,
`
`Patent Owner.
`________________
`
`Case IPR2017-013921
`U.S. Patent 7,337,241
`________________
`
`
`
`CORRECTED PATENT OWNER’S EXHIBIT 2026
`
`DECLARATION OF KEVIN ALMEROTH, PH.D.
`
`
`
`
`1 Cavium, who filed a Petition in Case IPR2017-01728, has been joined as a
`
`petitioner in this proceeding.
`
`06973-00001/9850380.6
`
`
`
`
`Alacritech Exhibit 2026
`
`
`
`
`
`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 joined
`
`by Cavium, Inc. (“Cavium”)) 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 Patent Owner (“PO”)
`
`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 references:
`
`Erickson (Ex. 1005) is U.S. Patent No. 5,768,618, which
`issued on June 16, 1998 and is assigned to NCR
`Corporation.
`
`
`
`Tanenbaum (Ex. 1006) is the 3rd edition of a textbook
`entitled Computer Networks by Andrew S. Tanenbaum.
`
`
`Alteon (Ex. 1033) is the 1st edition of a technical brief
`entitled “Gigabit Ethernet Technical Brief: Achieving
`End-to-End Performance” by Alteon Networks, Inc.
`
`
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 1
`
`
`
`
`
`3.
`
`I have also considered all other materials cited and discussed herein,
`
`including all other materials cited and discussed in Intel’s Petition for Inter Partes
`
`Review of U.S. Patent No. 7,337,241 (Case IPR2017-01392).
`
`4.
`
`I have also considered the following:
`
`No.
`
`Short Name
`
`Exhibit
`
`2004
`
`Interrupts
`
`Jonathan Corbet; Alessandro Rubini; Greg
`Kroah-Hartman (2005), Linux Device Drivers,
`3rd edition, Chapter 10, “Interrupt Handling”
`
`
`
`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. 2027).
`
`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
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 2
`
`
`
`
`
`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
`
`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
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 3
`
`
`
`
`
`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.
`
`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
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 4
`
`
`
`
`
`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
`
`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
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 5
`
`
`
`
`
`dorms delivered via the campus cable plant. The content of each channel was
`
`delivered using multicast communication.
`
`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.
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 6
`
`
`
`
`
`16. More recently, I have also studied issues concerning how users choose
`
`content, especially when considering the price of that content. My research has
`
`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
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 7
`
`
`
`
`
`protocols we envisioned were similar in nature to protocols like Universal Plug and
`
`Play (UPnP) and Digital Living Network Alliance (DLNA).
`
`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
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 8
`
`
`
`
`
`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
`
`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
`
`2027.
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 9
`
`
`
`
`
`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
`
`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
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 10
`
`
`
`
`
`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.
`
`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).
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 11
`
`
`
`
`
`28. Additional details about my employment history, fields of expertise,
`
`and publications are further included in my curriculum vitae, attached as Exhibit
`
`2027.
`
`29. 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
`
`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
`Alacritech Exhibit 2026, Page 12
`06973-00001/9850380.6
`
`
`
`
`
`
`• 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
`
`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.
`
`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 ’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.
`
`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 ’241 Patent.
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 13
`
`
`
`
`
`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
`
`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
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 14
`
`
`
`
`
`(3) explain how the prior art references could have been combined to create the
`
`inventions claimed in the asserted claim.
`
`40.
`
`I understand that certain objective indicia can be important evidence
`
`regarding whether a patent is obvious or nonobvious. Such indicia include: (1)
`
`commercial success of products covered by the patent claims; (2) a long-felt need
`
`for the invention; (3) failed attempts by others to make the invention; (4) copying
`
`of the invention by others in the field; (5) unexpected results achieved by the
`
`invention as compared to the closest prior art; (6) praise of the invention by the
`
`infringer or others in the field; (7) the taking of licenses under the patent by others;
`
`(8) expressions of surprise by experts and those skilled in the art at the making of
`
`the invention; and (9) the patentee proceeded contrary to the accepted wisdom of
`
`the prior art.
`
`41.
`
`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
`
`42.
`
`I have been instructed by counsel on the law regarding claim
`
`construction and patent claims, and understand that a patent may include two types
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 15
`
`
`
`
`
`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.
`
`43.
`
`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.
`
`44.
`
`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.
`
`45.
`
`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.
`
`46. 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
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 16
`
`
`
`
`
`of the corresponding structure. If the term is understood by a POSITA as referring
`
`to a particular structure, however, this two-step process is not followed.
`
`47.
`
`I understand and have been instructed that, where the claim uses the
`
`word “means,” there is a presumption that it is a means-plus-function claim term. I
`
`also understand and have been instructed that an applicant for a patent must
`
`disclose adequate structure in the specification to perform the recited function, and
`
`that if adequate structure is not recited, the claim is indefinite. I am further
`
`instructed that when the corresponding structure is a general purpose computer or
`
`microprocessor, the specification must disclose the algorithm or process to be
`
`performed by the general purpose computer or microprocessor, or the claim is
`
`indefinite.
`
`48.
`
`In this Declaration, I have used the broadest reasonable interpretation
`
`(“BRI”) standard when interpreting the claim terms.
`
`IV. BACKGROUND OF THE TECHNOLOGY DISCLOSED IN THE ’241
`PATENT
`
`49.
`
`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.
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 17
`
`
`
`
`
`50. The transmission of data over a network usually requires multiple
`
`steps. For example, the data has to be broken up into packets of a certain size that
`
`can be sent over the network. Information needs to be added to packets that, for
`
`example, helps them get to the right recipient. Then, once the intended recipient
`
`receives the data packets, additional processing often needs to be done. For
`
`example, packets often need to be reassembled and sent to a location in memory
`
`where they can be accessed by programs that use the data.
`
`51. 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.
`
`52. 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
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 18
`
`
`
`
`
`the correct format. The data is stored until it is ready to be used by another
`
`program.
`
`53. Although this traditional approach for transferring data is functional
`
`and well-established, it can also be slow and inefficient. The central processor
`
`(CPU), which is responsible for the software layers, uses a lot of processing power
`
`to do this type of layer-by-layer processing. Additionally, moving from one
`
`processing layer to the next may involve making a new copy of the data, further
`
`burdening the CPU.
`
`54.
`
`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.
`
`55. 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
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 19
`
`
`
`
`
`or explained to actually solve the growing problem of overburdened network CPUs
`
`by the late 1990s.
`
`56.
`
`It was not enough to simply theorize that processing could be split or
`
`offloaded from the host CPU in a computer network (this is a basic premise of
`
`distributed processing architectures, after all) —there needed to be concrete
`
`solutions as to how this split or offload would be achieved. None of the proposals
`
`in the 1980s and 1990s—including proposed standards—actually solved the
`
`problem of host CPU overload. And many, many engineers and academics were
`
`working directly on this problem over this time period.
`
`57.
`
`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.
`
`58. 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.
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 20
`
`
`
`
`
`59. Both in 1997 and today, sending and receiving information over the
`
`Internet involves the use of many different protocols that set out the rules for how
`
`devices on the Internet can communicate with one another. Multiple conceptual
`
`models exist for characterizing the interactions between these protocols in the
`
`context of the Internet and other telecommunication or computing systems. The
`
`Open Systems Interconnection model (or “OSI model”) is one well known
`
`example, describing a seven layer stack where a particular layer serves the layer
`
`above it and is served by the layers below it. The seven layers of the OSI model
`
`are:
`
`Layer 7: Application Layer
`
`Layer 6: Presentation Layer
`
`Layer 5: Session Layer
`
`Layer 4: Transport Layer
`
`Layer 3: Network Layer
`
`Layer 2: Data Link Layer
`
`Layer 1: Physical Layer
`
`with layer 1 (the Physical Layer) being the lowest layer in the model. In the
`
`context of network communications, four of these layers are commonly discussed:
`
`the link layer (layer 2, with common examples of link-layer protocols including
`
`Ethernet and WiFi), the network layer (layer 3, with IP being the most common
`
`06973-00001/9850380.6
`
`
`Alacritech Exhibit 2026, Page 21
`
`
`
`
`
`example of a network-layer protocol), the transport layer (layer 4, with TCP and
`
`UDP as two examples of transport-layer protocols), and the application layer (layer
`
`7, with HTTP, SMTP (email), and FTP as examples of application-layer
`
`protocols).
`
`60. The Hypertext Transfer Protocol (or “HTTP”) is an example of a
`
`well-known application (layer 7) protocol. HTTP version 1.1 was published as
`
`RFC 2068 in January 1997. As an application layer protocol, HTTP is a set of
`
`rules for carrying application-specific data between a source and a destination (for
`
`example, carrying HTTP protocol headers and world wide web data between a web
`
`browser and a web site server). Because most Internet traffic uses both IP and
`
`TCP, Internet t
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
