UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD. INTEL CORPORATION Petitioner. ALACRITECH, INC.

Transcription

1 UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD INTEL CORPORATION Petitioner v. ALACRITECH, INC. Patent Owner Case IPR. No. Unassigned U.S. Patent No. 7,337,241 Title: FAST-PATH APPARATUS FOR RECEIVING DATA CORRESPONDING TO A TCP CONNECTION Petition For Inter Partes Review of U.S. Patent No. 7,337,241 Under 35 U.S.C and 37 C.F.R , Mail Stop PATENT BOARD Patent Trial and Appeal Board U.S. Patent and Trademark Office P.O. Box 1450 Alexandria, VA

2 TABLE OF CONTENTS Page 1. INTRODUCTION REQUIREMENTS FOR PETITION FOR INTER PARTES REVIEW Grounds for Standing (37 C.F.R (a)) Notice of Lead and Backup Counsel and Service Information Notice of Real-Parties-in-Interest (37 C.F.R. 42.8(b)(1)) Notice of Related Matters (37 C.F.R. 42.8(b)(2)) Fee for Inter Partes Review Proof of Service IDENTIFICATION OF CLAIMS BEING CHALLENGED ( (B)) BACKGROUND OF THE TECHNOLOGY TCP/IP UDP/IP Protocol Offload OVERVIEW OF THE 241 PATENT PATENT PROSECUTION HISTORY CLAIM CONSTRUCTION Applicable Law Construction of Claim Terms [first/second] mechanism without an interrupt dividing PERSON HAVING ORDINARY SKILL IN THE ART DESCRIPTION OF THE PRIOR ART U.S. Patent No. 5,768,618 ( Erickson ) Tanenbaum96: A. Tanenbaum, Computer Networks, 3rd ed. (1996) Gigabit Ethernet Technical Brief: Achieving End-to-End Performance by Alteon Networks (Ex.1033, Alteon ) i

3 9.4. Alacritech s expert admits that almost all of the limitations are found in the prior art Motivations To Combine Erickson and Tanenbaum Motivations To Combine Erickson, Tanenbaum96, and Alteon GROUND #1: CLAIMS 1-8, 18, 22, AND 23 ARE UNPATENTABLE AS OBVIOUS OVER ERICKSON IN COMBINATION WITH TANENBAUM96 AND ALTEON Claim 1 is unpatentable as obvious over Erickson in combination with Tanenbaum96 and Alteon [1.P] A method for network communication, the method comprising: [1.1] receiving a plurality of packets from the network, each of the packets including a media access control layer header, a network layer header and a transport layer header; [1.2] processing the packets by a first mechanism, so that for each packet the network layer header and the transport layer header are validated without an interrupt dividing the processing of the network layer header and the transport layer header; [1.3] sorting the packets, dependent upon the processing, into first and second types of packets, so that the packets of the first type each contain data; [1.4] sending, by the first mechanism, the data from each packet of the first type to a destination in memory allocated to an application without sending any of the media access control layer headers, network layer headers or transport layer headers to the destination Claim 2 is unpatentable as obvious over Erickson in combination with Tanenbaum96 and Alteon ii

4 [2.1] The method of claim 1, wherein processing the packets by a first mechanism further comprises: processing the media access control layer header for each packet without an interrupt dividing the processing of the media access control layer header and the network layer header Claim 3 is unpatentable as obvious over Erickson in combination with Tanenbaum96 and Alteon [3.1] The method of claim 1, further comprising: processing an upper layer header of at least one of the packets by a second mechanism, thereby determining the destination, wherein the upper layer header corresponds to a protocol layer above the transport layer Claim 4 is unpatentable as obvious over Erickson in combination with Tanenbaum96 and Alteon [4.1] The method of claim 1, further comprising: processing an upper layer header of at least one of the packets of the second type by a second mechanism, thereby determining the destination Claim 5 is unpatentable as obvious over Erickson in combination with Tanenbaum96 and Alteon [5.1] The method of claim 1, further comprising: processing a transport layer header of another packet by a second mechanism, prior to receiving the plurality of packets from the network, thereby establishing a Transmission Control Protocol (TCP) connection for the packets of the first type Claim 6 is unpatentable as obvious over Erickson in combination with Tanenbaum96 and Alteon [6.1] The method of claim 1, wherein sorting the packets includes classifying each of the packets of the first type as having an Internet Protocol (IP) header and a Transmission Control Protocol (TCP) iii

5 10.7. Claim 7 is unpatentable as obvious over Erickson in combination with Tanenbaum96 and Alteon [7.1.1] The method of claim 1, further comprising: transmitting a second plurality of packets to the network, [7.1.2] each of the second plurality of packets containing a media access control layer header, a network layer header and a transport layer header, [7.1.3] including processing the second plurality of packets by the first mechanism, so that for each packet the media access control layer header, the network layer header and the transport layer header are prepended at one time as a packet header Claim 8 is unpatentable as obvious over Erickson in combination with Tanenbaum96 and Alteon [8.1] The method of claim 1, wherein the first mechanism is a sequencer running microcode GROUND #2: CLAIMS 9-24 ARE UNPATENTABLE AS OBVIOUS OVER ERICKSON IN COMBINATION WITH TANENBAUM Claim 9 is unpatentable as obvious over Erickson in combination with Tanenbaum [9.P] A method for communicating information over a network, the method comprising: [9.1] obtaining data from a source in memory allocated by a first processor; [9.2] dividing the data into multiple segments; [9.3.1] prepending a packet header to each of the segments by a second processor, thereby forming a packet corresponding to each segment, iv

6 [9.3.2] each packet header containing a media access control layer header, a network layer header and a transport layer header, wherein the network layer header is Internet Protocol (IP), the transport layer header is Transmission Control Protocol (TCP) and [9.3.3] the media access control layer header, the network layer header and the transport layer header are prepended at one time as a sequence of bits during the prepending of each packet header; and [9.4] transmitting the packets to the network Claim 10 is unpatentable as obvious over Erickson in combination with Tanenbaum [10.1] The method of claim 9, wherein each packet header is formed based upon a block of information created by the first processor Claim 11 is unpatentable as obvious over Erickson in combination with Tanenbaum [11.1] The method of claim 9, further comprising: receiving another packet from the network, the other packet containing a receive header including information corresponding to a network layer and a transport layer; and [11.2] determining, by the second processor, whether the other packet corresponds to the same TCP connection as the transmitted packets Claim 12 is unpatentable as obvious over Erickson in combination with Tanenbaum [12.1] The method of claim 9, further comprising establishing a Transmission Control Protocol (TCP) connection by the first processor and using the connection to prepend the packet header to each of the segments by the second processor Claim 13 is unpatentable as obvious over Erickson in combination with Tanenbaum v

7 [13.1] The method of claim 9, further comprising creating a template header and forming each packet header based upon the template header Claim 14 is unpatentable as obvious over Erickson in combination with Tanenbaum [14.1] The method of claim 9, wherein obtaining data from the source in memory allocated by the first processor is performed by a Direct Memory Access (DMA) unit controlled by the second processor Claim 15 is unpatentable as obvious over Erickson in combination with Tanenbaum [15.1] The method of claim 9, further comprising prepending an upper layer header to the data, prior to dividing the data into multiple segments Claim 16 is unpatentable as obvious over Erickson in combination with Tanenbaum [16.1] The method of claim 9, further comprising: receiving another packet from the network, the other packet containing a receive header including information corresponding to a network layer and a transport layer; and [16.2] selecting whether to process the other packet by the first processor or by the second processor Claim 17 is unpatentable as obvious over Erickson in combination with Tanenbaum [17.P] A method for communicating information over a network, the method comprising: [17.1] providing, by a first mechanism, a block of data and a Transmission Control Protocol (TCP) connection; [17.2] dividing, by a second mechanism, the block of data into multiple segments; vi

8 [17.3.1] prepending, by the second mechanism, an outbound packet header to each of the segments, thereby forming an outbound packet corresponding to each segment, [17.3.2] the outbound packet header containing an outbound media access control layer header, an outbound Internet Protocol (IP) header and an outbound TCP header, [17.3.3] wherein the prepending of each outbound packet header occurs without an interrupt dividing the prepending of the outbound media access control layer header, the outbound (IP) header and the outbound TCP header; and [17.4] transmitting the outbound packets to the network Claim 19 is unpatentable as obvious over Erickson in combination with Tanenbaum [19.1] The method of claim 17, further comprising creating a template header and using the template header to form each outbound packet header Claim 20 is unpatentable as obvious over Erickson in combination with Tanenbaum [20.1] The method of claim 17, wherein the TCP connection is passed from the first mechanism to the second mechanism Claim 21 is unpatentable as obvious over Erickson in combination with Tanenbaum [21.1] The method of claim 20, further comprising prepending an upper layer header to the block of data, prior to dividing the block of data into multiple segments Claim 24 is unpatentable as obvious over Erickson in combination with Tanenbaum vii

9 [24.1] The method of claim 17, further comprising: processing a transport layer header of another inbound packet, prior to receiving the plurality of packets from the network, thereby establishing a Transmission Control Protocol (TCP) connection for the inbound packets GROUND #3: CLAIMS 18, 22, 23 ARE UNPATENTABLE AS OBVIOUS OVER ERICKSON IN COMBINATION WITH TANENBAUM Claim 18 is unpatentable as obvious over Erickson in combination with Tanenbaum96 and Alteon [18.1] The method of claim 17, further comprising: receiving multiple inbound packets from the network, each of the inbound packets including an inbound media access control layer header, an inbound IP header and an inbound TCP header; [18.2] processing the inbound packets, so that for each packet the inbound IP header and the inbound TCP header are validated without an interrupt dividing the processing of the inbound network layer header and the inbound transport layer header; [18.3] wherein the processing the inbound packets is performed simultaneously with the prepending the outbound packet header to each of the segments Claim 22 is unpatentable as obvious over Erickson in combination with Tanenbaum96 and Alteon [22.1] The method of claim 17, further comprising: receiving multiple inbound packets from the network, each of the inbound packets including an inbound media access control layer header, an inbound IP header and an inbound TCP header; [22.2] processing the inbound packets, so that for each packet the inbound IP header and the inbound TCP header are validated without an interrupt dividing the processing of the inbound network layer header and the inbound transport layer header; and viii

10 [22.3] sending data from each inbound packet to a destination in memory allocated to an application without sending any of the media access control layer headers, IP headers or TCP headers to the destination Claim 23 is unpatentable as obvious over Erickson in combination with Tanenbaum96 and Alteon [23.1] The method of claim 22, further comprising: processing an upper layer header of at least one of the packets by the second mechanism, thereby determining the destination, wherein the upper layer header corresponds to a protocol layer above the transport layer CONCLUSION ix

11 TABLE OF AUTHORITIES Page(s) Cases Alacritech, Inc. v. CenturyLink, Inc., 2:16-cv JRG-RSP (E.D. Tex.)... 3 Alacritech, Inc. v. Dell Inc., 2:16-cv RWS-RSP (E.D. Tex.)... 3 Alacritech, Inc. v. Microsoft Corp., 3-04-cv-03284, (N.D. Cal)... 3 Alacritech, Inc. v. Wistron Corp., 2:16-cv JRG-RSP (E.D. Tex.)... 3 Flex-Rest, LLC v. Steelcase, Inc., 455 F.3d 1351 (Fed. Cir. 2006) Media Rights Techs., Inc. v. Capital One Fin. Corp., 800 F.3d 1366, 2015 U.S. App. LEXIS (Fed. Cir. 2015) Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) Uniloc USA, Inc. v. Autodesk, Inc., No. 2:15-cv-1187-JRG-RSP, 2016 WL (E.D. Tex. July 7, 2016) Warner-Jenkinson Co., Inc. v. Hilton Davis Chem. Co., 520 U.S. 17 (1997) Williamson v. Citrix Online, LLC, 792 F.3d 1339 (Fed. Cir. 2015) Statutes 35 U.S.C. 102(b)... 38, U.S.C. 102(e) U.S.C. 103(a)... 14, U.S.C U.S.C. 112(6)... 26, 29, 30, U.S.C C.F.R (a)... 1 i

12 37 C.F.R (b) C.F.R (b) C.F.R (a) C.F.R (b) C.F.R (a) C.F.R. 42.8(b)(1) C.F.R. 42.8(b)(2) C.F.R. 42.8(b)(3) C.F.R. 42.8(b)(4) C.F.R C.F.R Fed. Reg (Aug. 14, 2012) M.P.E.P ii

13 Exhibit List Exhibit # Ex.1001 Ex.1002 Ex.1003 Ex.1004 Ex.1005 Ex.1006 Ex.1007 Ex.1008 Ex.1009 Ex.1010 Ex.1011 Ex.1012 Ex.1013 Description U.S. Patent No. 7,337,241 ( 241 Patent ) Excerpts from Prosecution File History of U.S. Patent No. 7,337,241 ( 241 File History ) Declaration of Robert Horst Curriculum Vitae of Robert Horst U.S. Patent No. 5,768,618 ( Erickson ) Tanenbaum, Andrew S., Computer Networks, Prentice-Hall, Inc., New Jersey (1996). ( Tanenbaum96 ) Transmission Control Protocol, Darpa Internet Protocol Specification, RFC: 793, Sept ( RFC 793 ) Stevens, W. Richard, TCP/IP Illustrated Volume 1: The Protocols, Addison-Wesley (1994). ( Stevens1 ) Lilinkamp, J., Mandell. R. and Padlipsky, M., Proposed Host- Front End Protocol, Network Working Group Request for Comments: 929, Dec ( RFC 929 ) Not Used Librarian Declaration of Rice Mayors regarding Andrew S. Tanenbaum, Computer Networks (3rd ed. 1996) (Ex.1006, Tanenbaum96 ) Not Used Stevens, W. Richard and Gary R. Wright, TCP/IP Illustrated Volume 2: The Implementation, Addison-Wesley (1995). ( Stevens2 ) iii

14 Exhibit # Description Ex.1014 Ex.1015 Ex.1016 Ex.1017 Ex.1018 Ex.1019 Ex.1020 Ex.1021 Ex.1022 Ex.1023 Not Used Thia, Y.H., Woodside, C.M., A Reduced Operation Protocol Engine (ROPE) for a Multiple-Layer Bypass Architecture, Protocols for High Speed Networks (Dordrecht), ( Thia ) Biersack, E. W., Rütsche E., Demultiplexing on the ATM Adapter: Experiments with Internet Protocols in User Space, Journal on High Speed Networks, Vol. 5, No. 2, May ( Biersack ) Rütsche, E., Kaiserswerth, M., TCP/IP on the Parallel Protocol Engine, Proceedings, IFIP Conference on High Performance Networking, Liege (Belgium), Dec ( Rütsche92 ) Rütsche, E., The Architecture of a Gb/s Multimedia Protocol Adapter, Computer Communication Review, ( Rütsche93 ) Padlipsky, M. A., A Proposed Protocol for Connecting Host Computers to Arpa-Like Networks Via Directly-Connected Front End Processors, Network Working Group RFC #647, Nov ( RFC 647 ) U.S. Patent No. 5,619,650 ( Bach ) U.S. Patent No. 5,915,124 ( Morris ) Cooper, E.C., et al., Protocol Implementation on the Nectar Communication Processor, School of Computer Science, Carnegie Mellon University, Sept ( Cooper ) Kung, H.T., et al., A Host Interface Architecture for High-Speed Networks, School of Computer Science, Carnegie Mellon University and Network Systems Corporation. ( Kung ) iv

15 Exhibit # Ex.1024 Ex.1025 Ex.1026 Ex.1027 Ex.1028 Ex.1029 Ex.1030 Ex.1031 Ex.1032 Description Exhibit D to Declaration of Dr. Gregory L. Chesson in Support of Microsoft s Opposition to Alacritech s Motion for Preliminary Injunction: Protocol Engine Handbook, Protocol Engines Incorporated, Oct ( Chesson ) Kanakia, H., Cheriton, D.R., The VMP Network Adapter Board (NAB): High-Performance Network Communication for Multiprocessors, Communications Architectures & Protocols, Stanford University, Aug ( Kanakia ) Kung, H.T., Cooper, E.C., et al., Network-Based Multicomputers: An Emerging Parallel Architectures, School of Computer Science, Carnegie Mellon University. ( Kung and Cooper ) Dalton, C., et al., Afterburner: Architectural Support for High- Performance Protocols, Networks & Communications Laboratories, HP Laboratories Bristol, July ( Dalton ) Murphy, E., Hayes, S., Enders, M., TCP/IP Tutorial and Technical Overview Fifth Edition, Prentice-Hall, Inc. New Jersey, (1995). ( Murphy ) MacLean, A.R., Barvick, S. E., An Outboard Processor for High Performance Implementation of Transport Layer Protocols, IEEE Globecom 91, Phoenix, AZ, Dec ( MacLean ) Clark, D.D., et al., An Analysis of TCP Processing Overhead, IEEE Communications Magazine, June ( Clark ) U.S. Provisional Application 60/061,809 ( Alacritech 1997 Provisional Application ) Culler, E.C., et al., Parallel Computing on the Berkeley NOW, Computer Science Division, University of California, Berkeley. ( Culler ) v

16 Exhibit # Ex.1033 Ex.1034 Ex.1035 Ex.1036 Ex.1037 Ex.1038 Ex.1039 Exs Description Gigabit Ethernet Technical Brief: Achieving End-to-End Performance, Alteon Networks, Inc. First Edition, Sept ( Alteon ) Smith, J.A., Primmer, M., Tachyon: A Gigabit Fibre Channel Protocol Chip, Hewlett-Packard Journal, Article 12, Oct ( Smith ) Patterson, D.A., Hennessy, J.L., Computer Architecture: A Quantitative Approach, Morgan Kaufmann Publishers, Inc., San Mateo, CA (1990). ( Patterson ) Internet Protocol, Darpa Internet Protocol Specification, RFC: 791, Sept ( RFC 791 ) Not Used Woodside, C. M., Ravindran, K. and Franks, R. G.. The protocol bypass concept for high speed OSI data transfer. IFIP Workshop on Protocols for High Speed Networks ( Woodside ) Joint Claim Construction and Pre-Hearing Statement Pursuant to Rule 4-3 (Alacritech, Inc. v. Dell Inc, Intel Corporation, et al.) ( JCCS ) Not Used Ex.1051 U.S. Patent No. 4,027,293 Ex.1052 U.S. Patent No. 5,329,630 Ex Ex.1062 Not Used Rebuttal Declaration of Paul S. Min in Support of Plaintiff s Claim Construction Brief ( Min Rebuttal Declaration ) vi

17 Exhibit # Description Ex Ex.1077 Ex Ex.1087 Not Used Deposition of Paul S. Min on March 21, 2017 ( Min Depo ) Not Used Librarian Declaration of Christopher Butler regarding Gigabit Ethernet Technical Brief: Achieving End-to-End Performance, Alteon Networks, Inc. First Edition, Sept (Ex.1033, Alteon ) vii

18 1. INTRODUCTION Pursuant to 35 U.S.C and 37 C.F.R , , Intel Corporation ( Petitioner or Intel Corporation ) hereby petitions the Patent Trial and Appeal Board to institute an inter partes review of claims 1-24 of U.S. Patent No. 7,337,241, titled Fast-Path Apparatus for Receiving Data Corresponding to a TCP connection (Ex.1001, the 241 Patent ), and cancel those claims as unpatentable. 2. REQUIREMENTS FOR PETITION FOR INTER PARTES REVIEW 2.1. Grounds for Standing (37 C.F.R (a)) Petitioner certifies that the 241 Patent is available for inter partes review and that Petitioner is not barred or estopped from requesting inter partes review of the challenged claims of the 241 Patent on the grounds identified herein Notice of Lead and Backup Counsel and Service Information Pursuant to 37 C.F.R. 42.8(b)(3), 42.8(b)(4), and 42.10(a), Petitioner provides the following designation of Lead and Back-Up counsel. Lead Counsel Garland T. Stephens Registration No. 37,242 (garland.stephens@weil.com) Postal & Hand-Delivery Address: Weil, Gotshal & Manges LLP 700 Louisiana St., Suite 1700 Houston, TX T: ; F: Attorney for Intel Corporation Back-Up Counsel Jeremy Jason Lang Registration No. 73,604 (jason.lang@weil.com) Postal & Hand-Delivery Address: Weil, Gotshal & Manges LLP 201 Redwood Shores Parkway Redwood Shores, CA T: ; F:

19 Lead Counsel Back-Up Counsel Anne Cappella Registration No. 43,217 Postal & Hand-Delivery Address: Weil, Gotshal & Manges LLP 201 Redwood Shores Parkway Redwood Shores, CA T: ; F: Adrian Percer Registration No. 46,986 Postal & Hand-Delivery Address: Weil, Gotshal & Manges LLP 201 Redwood Shores Parkway Redwood Shores, CA T: ; F: Attorneys for Intel Corporation Petitioner consents to service by electronic mail at the following address: Pursuant to 37 C.F.R (b), a Power of Attorney for Petitioner is attached Notice of Real-Parties-in-Interest (37 C.F.R. 42.8(b)(1)) Petitioner, Intel Corporation, is the real-party-in-interest. No other parties exercised or could have exercised control over this petition; no other parties funded or directed this Petition. See Office Patent Trial Practice Guide, 77 Fed. Reg

20 2.4. Notice of Related Matters (37 C.F.R. 42.8(b)(2)) The following judicial or administrative matters may affect or be affected by a decision in this proceeding: Alacritech, Inc. v. CenturyLink, Inc., 2:16-cv JRG-RSP (E.D. Tex.), Alacritech, Inc. v. Wistron Corp., 2:16-cv JRG-RSP (E.D. Tex.); Alacritech, Inc. v. Dell Inc., 2:16-cv RWS-RSP (E.D. Tex.). In addition to this Petition, Petitioner is filing petitions for U.S. Patent Nos. 7,124,205; 8,805,948; 7,237,036; 7,673,072; 7,945,699; 8,131,880; and 9,055,104. Alacritech has asserted one or more of the Asserted Patents or patents related to the Asserted Patents in the following actions: 1. U.S. Patent Nos. 6,427,171 and 6,697,868 were asserted in Alacritech, Inc. v. Microsoft Corp., 3-04-cv-03284, (N.D. Cal); 2. U.S. Patent Nos. 7,124,205; 7,237,036; 7,337,241; 7,673,072; 8,131,880; 8,805,948; and 9,055,104 are asserted in Alacritech, Inc. v. Wistron Corp., 2:16-cv JRG-RSP (E.D. Tex.); 3. U.S. Patent Nos. 7,124,205; 7,237,036; 7,337,241; 7,673,072; 8,131,880; 8,805,948; 9,055,104; and 7,945,699 are asserted in Alacritech, Inc. v. Dell Inc., 2:16-cv RWS-RSP (E.D. Tex.). 4. U.S. Patent Nos. 7,124,205; 7,237,036; 7,337,241; 7,673,072; 8,131,880; 8,805,948; 9,055,104; and 7,945,699 are asserted in Alacritech, Inc. v. CenturyLink, Inc., 2:16-cv JRG-RSP (E.D. Tex.). 3

21 The patent family to which the 036 Patent belongs contains 19 additional U.S. patents: 1. U.S. Patent Application No. 11/821,820 (filed Jun. 25, 2007, issued Mar. 2, 2010 as 7,673,072 patent); 2. U.S. Patent Application No. 10/092,967 (filed Mar. 6, 2002, issued Jul. 8, 2003 as 6,591,302 patent); 3. U.S. Patent Application No. 10/023,240 (filed Dec. 17, 2001, issued Nov. 15, 2005 as 6,965,941 patent); 4. U.S. Patent Application No. 09/970,124 (filed Oct. 2, 2001, issued Oct. 17, 2006 as 7,124,205 patent); 5. U.S. Patent Application No. 09/855,979 (filed May 14, 2001, issued Nov. 7, 2006 as 7,133,940 patent); 6. U.S. Patent Application No. 09/802,426 (filed Mar. 9, 2001, issued May 9, 2006 as 7,042,898 patent); 7. U.S. Patent Application No. 09/802,550 (filed Mar. 9, 2001, issued Dec. 2, 2003 as 6,658,480 patent); 8. U.S. Patent Application No. 09/802,551 (filed Mar. 9, 2001, issued Jul. 11, 2006 as 7,076,568 patent); 4

22 9. U.S. Patent Application No. 09/801,488 (filed Mar. 7, 2001, issued Feb. 3, 2004 as 6,687,758 patent); 10. U.S. Patent Application No. 09/789,366 (filed Feb. 20, 2001, issued Jun. 29, 2004 as 6,757,746 patent); 11. U.S. Patent Application No. 09/675,700 (filed Sept. 29, 2000, issued Dec. 31, 2013 as 8,621,101 patent); 12. U.S. Patent Application No. 09/675,484 (filed Sept. 29, 2000, issued Oct. 19, 2004 as 6,807,581 patent); 13. U.S. Patent Application No. 09/514,425 (filed Feb. 28, 2000, issued Jul. 30, 2002 as 6,427,171 patent); 14. U.S. Patent Application No. 09/464,283 (filed Dec. 15, 1999, issued Jul. 30, 2002 as 6,427,173 patent); 15. U.S. Patent Application No. 09/439,603 (filed Nov. 12, 1999, issued Jun. 12, 2001 as 6,247,060 patent); 16. U.S. Patent Application No. 09/416,925 (filed Oct. 13, 1999, issued Oct. 22, 2002 as 6,470,415 patent); 17. U.S. Patent Application No. 09/384,792 (filed Aug. 27, 1999, issued Aug. 13, 2002 as 6,434,620 patent); 18. U.S. Patent Application No. 09/141,713 (filed Aug. 28, 1998, issued May 14, 2002 as 6,389,479 patent); 5

23 19. U.S. Patent Application No. 60/098,296 (expired); 20. U.S. Patent Application No. 09/067,544 (filed Apr. 27, 1998, issued May 1, 2001 as 6,226,680 patent); 21. U.S. Patent Application No. 60/061,809 (expired). The patent family to which the 205 Patent belongs contains 5 additional U.S. patents: 1. U.S. Patent Application No. 10/092,967 (filed Mar. 6, 2002, issued Jul. 8, 2003 as 6,591,302 patent); 2. U.S. Patent Application No. 10/260,112 (filed Sept. 27, 2002, issued Jul. 26, 2007 as 7,237,036 patent); 3. U.S. Patent Application No. 10/261,051 (filed Sept. 30, 2002, issued Sept. 13, 2011 as 8,019,901 patent); 4. U.S. Patent Application No. 11/821,820 (filed Jun. 25, 2007, issued Mar. 2, 2010 as 7,673,072 patent); 5. U.S. Patent Application No. 11/582,199 (filed Oct. 16, 2006, issued Feb. 16, 2010 as 7,664,883 patent). The patent family to which the 072 Patent belongs contains 19 additional U.S. patents: 1. U.S. Patent Application No. 10/260,112 (filed Sept. 27, 2002, issued Jul. 26, 2007 as 7,237,036 patent); 6

24 2. U.S. Patent Application No. 10/092,967 (filed Mar. 6, 2002, issued Jul. 8, 2003 as 6,591,302 patent); 3. U.S. Patent Application No. 10/023,240 (filed Dec. 17, 2001, issued Nov. 15, 2005 as 6,965,941 patent); 4. U.S. Patent Application No. 09/970,124 (filed Oct. 2, 2001, issued Oct. 17, 2006 as 7,124,205 patent); 5. U.S. Patent Application No. 09/855,979 (filed May 14, 2001, issued Nov. 7, 2006 as 7,133,940 patent); 6. U.S. Patent Application No. 09/802,426 (filed Mar. 9, 2001, issued May 9, 2006 as 7,042,898 patent); 7. U.S. Patent Application No. 09/802,550 (filed Mar. 9, 2001, issued Dec. 2, 2003 as 6,658,480 patent); 8. U.S. Patent Application No. 09/802,551 (filed Mar. 9, 2001, issued Jul. 11, 2006 as 7,076,568 patent); 9. U.S. Patent Application No. 09/801,488 (filed Mar. 7, 2001, issued Feb. 3, 2004 as 6,687,758 patent); 10. U.S. Patent Application No. 09/789,366 (filed Feb. 20, 2001, issued Jun. 29, 2004 as 6,757,746 patent); 11. U.S. Patent Application No. 09/675,700 (filed Sept. 29, 2000, issued Dec. 31, 2013 as 8,621,101 patent); 7

25 12. U.S. Patent Application No. 09/675,484 (filed Sept. 29, 2000, issued Oct. 19, 2004 as 6,807,581 patent); 13. U.S. Patent Application No. 09/514,425 (filed Feb. 28, 2000, issued Jul. 30, 2002 as 6,427,171 patent); 14. U.S. Patent Application No. 09/464,283 (filed Dec. 15, 1999, issued Jul. 30, 2002 as 6,427,173 patent); 15. U.S. Patent Application No. 09/439,603 (filed Nov. 12, 1999, issued Jun. 12, 2001 as 6,247,060 patent); 16. U.S. Patent Application No. 09/416,925 (filed Oct. 13, 1999, issued Oct. 22, 2002 as 6,470,415 patent); 17. U.S. Patent Application No. 09/384,792 (filed Aug. 27, 1999, issued Aug. 13, 2002 as 6,434,620 patent); 18. U.S. Patent Application No. 09/141,713 (filed Aug. 28, 1998, issued May 14, 2002 as 6,389,479 patent); 19. U.S. Patent Application No. 60/098,296 (expired); 20. U.S. Patent Application No. 09/067,544 (filed Apr. 27, 1998, issued May 1, 2001 as 6,226,680 patent); 21. U.S. Patent Application No. 60/061,809 (expired). The patent family to which the 948 Patent belongs contains 2 additional U.S. patents: 8

26 1. U.S. Patent Application No. 09/692,561 (filed Oct. 18, 2000, issued Jan. 14, 2014 as 8,631,140 patent); 2. U.S. Patent Application No. 09/067,544 (filed Apr. 27, 1998, issued May 1, 2001 as 6,226,680 patent); 3. U.S. Patent Application No. 60/061,809 (expired). The patent family to which the 699 Patent belongs contains 14 additional U.S. patents: 1. U.S. Patent Application No. 10/881,271 (filed Jun. 29, 2004, issued Dec. 2, 2008 as 7,461,160 patent); 2. U.S. Patent Application No. 09/789,366 (filed Feb. 20, 2001, issued Jun. 29, 2004 as 6,757,746 patent); 3. U.S. Patent Application No. 09/748,936 (filed Dec. 26, 2000, issued Dec. 25, 2001 as 6,334,153 patent); 4. U.S. Patent Application No. 09/692,561 (filed Oct. 18, 2000, issued Jan. 14, 2014 as 8,631,140 patent); 5. U.S. Patent Application No. 09/675,484 (filed Sept. 29, 2000, issued Oct. 19, 2004 as 6,807,581 patent); 6. U.S. Patent Application No. 09/675,700 (filed Sept. 29, 2000, issued Dec. 31, 2013 as 8,621,101 patent); 9

27 7. U.S. Patent Application No. 09/514,425 (filed Feb. 28, 2000, issued Jul. 30, 2002 as 6,427,171 patent); 8. U.S. Patent Application No. 09/464,283 (filed Dec. 15, 1999, issued Jul. 30, 2002 as 6,427,173 patent); 9. U.S. Patent Application No. 09/439,603 (filed Nov. 12, 1999, issued Jun. 12, 2001 as 6,247,060 patent); 10. U.S. Patent Application No. 09/416,925 (filed Oct. 13, 1999, issued Oct. 22, 2002 as 6,470,415 patent); 11. U.S. Patent Application No. 09/384,792 (filed Aug. 27, 1999, issued Aug. 13, 2002 as 6,434,620 patent); 12. U.S. Patent Application No. 09/141,713 (filed Aug. 28, 1998, issued May 14, 2002 as 6,389,479 patent); 13. U.S. Patent Application No. 60/098,296 (expired) 14. U.S. Patent Application No. 09/067,544 (filed Apr. 27, 1998, issued May 1, 2001 as 6,226,680 patent); 15. U.S. Patent Application No. 60/061,809 (expired); 16. U.S. Patent Application No. 13/108,729 (filed May 16, 2011, issued Sept. 17, 2003 as 8,539,112 patent). The patent family to which the 880 Patent belongs contains 6 additional U.S. patents: 10

28 1. U.S. Patent Application No. 10/005,536 (filed Nov. 7, 2001, issued Jan. 23, 2007 as 7,167,926 patent); 2. U.S. Patent Application No. 09/514,425 (filed Feb. 28, 2000, issued Jul. 30, 2002 as 6,427,171 patent); 3. U.S. Patent Application No. 09/464,283 (filed Dec. 15, 1999, issued Jul. 30, 2002 as 6,427,173 patent); 4. U.S. Patent Application No. 09/384,792 (filed Aug. 27, 1999, issued Aug. 13, 2002 as 6,434,620 patent); 5. U.S. Patent Application No. 09/141,713 (filed Aug. 28, 1998, issued May 14, 2002 as 6,389,479 patent); 6. U.S. Patent Application No. 60/098,296 (expired); 7. U.S. Patent Application No. 09/067,544 (filed Apr. 27, 1998, issued May 1, 2001 as 6,226,680 patent); 8. U.S. Patent Application No. 60/061,809 (expired). The patent family to which the 104 Patent belongs contains 1 additional U.S. patents: 1. U.S. Patent Application No. 10/413,256 (filed Apr. 22, 2003, issued Jun. 2, 2009 as 7,543,087 patent); 2. U.S. Patent Application No. 60/374,788 (expired). The patent family to which the 241 Patent belongs contains 19 additional U.S. 11

29 patents: 1. U.S. Patent Application No. 10/092,967 (filed Mar. 6, 2002, issued Jul. 8, 2003 as 6,591,302 patent); 2. U.S. Patent Application No. 10/023,240 (filed Dec. 17, 2001, issued Nov. 15, 2005 as 6,965,941 patent); 3. U.S. Patent Application No. 09/464,283 (filed Dec. 15, 1999, issued Jul. 30, 2002 as 6,427,173 patent); 4. U.S. Patent Application No. 09/439,603 (filed Nov. 12, 1999, issued Jun. 12, 2001 as 6,247,060 patent); 5. U.S. Patent Application No. 09/067,544 (filed Apr. 27, 1998, issued May 1, 2001 as 6,226,680 patent); 6. U.S. Patent Application No. 60/061,809 (expired); 7. U.S. Patent Application No. 09/384,792 (filed Aug. 27, 1999, issued Aug. 13, 2002 as 6,434,620 patent); 8. U.S. Patent Application No. 09/141,713 (filed Aug. 28, 1998, issued May 14, 2002 as 6,389,479 patent); 9. U.S. Patent Application No. 60/098,296 (expired); 10. U.S. Patent Application No. 09/416,925 (filed Oct. 13, 1999, issued Oct. 22, 2002 as 6,470,415 patent); 12

30 11. U.S. Patent Application No. 09/514,425 (filed Feb. 28, 2000, issued Jul. 30, 2002 as 6,427,171 patent); 12. U.S. Patent Application No. 09/675,484 (filed Sept. 29, 2000, issued Oct. 19, 2004 as 6,807,581 patent); 13. U.S. Patent Application No. 09/675,700 (filed Sept. 29, 2000, issued Dec. 31, 2013 as 8,621,101 patent); 14. U.S. Patent Application No. 09/789,366 (filed Feb. 20, 2001, issued Jun. 29, 2004 as 6,757,746 patent); 15. U.S. Patent Application No. 09/801,488 (filed Mar. 7, 2001, issued Feb. 3, 2004 as 6,687,758 patent); 16. U.S. Patent Application No. 09/802,551 (filed Mar. 9, 2001, issued Jul. 11, 2006 as 7,076,568 patent); 17. U.S. Patent Application No. 09/802,426 (filed Mar. 9, 2001, issued May 9, 2006 as 7,042,898 patent); 18. U.S. Patent Application No. 09/802,550 (filed Mar. 9, 2001, issued Dec. 2, 2003 as 6,658,480 patent); 19. U.S. Patent Application No. 09/855,979 (filed May 14, 2001, issued Nov. 7, 2006 as 7,133,940 patent); 20. U.S. Patent Application No. 09/970,124 (filed Oct. 2, 2001, issued Oct. 17, 2006 as 7,124,205 patent); 13

31 21. U.S. Patent Application No. 09/464,283 (filed Dec. 15, 1999, issued Jul. 30, 2002 as 6,427,173 patent) Fee for Inter Partes Review The Director is authorized to charge the fee specified by 37 C.F.R (a), and any other required fees, to Deposit Account No Proof of Service Proof of service of this Petition on the Patent Owner at the correspondence address of record for the 241 Patent is attached. 3. IDENTIFICATION OF CLAIMS BEING CHALLENGED ( (B)) Ground #1: Claims 1-8 of the 241 Patent are invalid under (pre-aia) 35 U.S.C. 103(a) on the ground that they are obvious over: a) U.S. Pat. No. 5,768,618, to Erickson, titled Method for Performing Sequence of Actions in Device Connected to Computer in Response to Specified Values Being Written Into Snooped Sub Portions of Address Space, filed on Dec. 21, 1995 and issued on Jun. 16, 1998 (Ex.1005, Erickson ) in combination with b) Computer Networks, A. Tanenbaum, 3rd ed. (1996) (Ex.1006, Tanenbaum96 ) and 14

32 c) Gigabit Ethernet Technical Brief: Achieving End-to-End Performance by Alteon Networks (Ex.1033, Alteon ) Ground #2: Claims 9-17, 19-21, and 24 of the 241 Patent are invalid under (pre-aia) 35 U.S.C. 103(a) on the ground that they are obvious over: a) Erickson in combination with b) Tanenbaum96 Ground #3: Claims 18, 22, and 23 of the 241 Patent are invalid under (pre- AIA) 35 U.S.C. 103(a) on the ground that they are obvious over: a) Erickson in combination with b) Tanenbaum96 and c) Alteon 4. BACKGROUND OF THE TECHNOLOGY This section provides a brief background on the technology at issue, focusing on the TCP, UDP and IP protocols and offloading protocol processing from a host computer to a network interface card (NIC). Petitioner s declarant Dr. Horst provides a more thorough tutorial on the technology and discusses the state of the art as well. See generally Ex.1003, Horst Decl. at Section V. 15

33 4.1. TCP/IP The 241 Patent relates to network interface device that provides a fast-path that avoids protocol processing TCP/IP packets. Ex.1001, 241 Patent at Abstract. TCP/IP stands for Transmission Control Protocol/Internet Protocol. TCP/IP is the main protocol used for Internet communications Web pages are served using TCP/IP. Ex.1003, Horst Decl. 27. By October 14, 1996, the critical date of the 241 Patent, TCP/IP was one of the most popular wide area networking protocols. Id. TCP/IP was standardized in a series of publicly available Request for Comments (RFCs) published by the Internet Engineering Task Force, including RFC 793, entitled Transmission Control Protocol. Ex.1007, RFC 793. Free implementations of the protocol were widely available and widely used. Ex.1003, Horst Decl. 27. TCP/IP consists of two parts: (1) Transmission Control Protocol (TCP), which provides virtual bi-directional connections that provide guaranteed in-order, error-free delivery of arbitrary amounts of data between programs running on different computers over the internet; and (2) Internet Protocol (IP), which provides delivery of datagrams (IP packets) to any routable Internet address, without any reliability or ordering guarantees. TCP/IP can be transmitted over a variety of physical media, such as Ethernet. Id

34 TCP runs on top of IP by first dividing application data to be transmitted into segments that become the data payloads of TCP packets and concatenating each payload with a TCP header to form a TCP packet, a process called TCP segmentation. Ex.1003, Horst Decl TCP/IP then places the resulting TCP packet (TCP header + payload) into the data payload of an IP packet by concatenating the TCP packet (IP data payload) with an IP header. Id Shown in the figure below, in typical TCP/IP processing, a packet is built from the top down, i.e., each layer encapsulates what it receives from the layer above by concatenating a header. When receiving a packet from the network, the layers work in reverse, with each layer stripping its header and providing the resulting packet to the layer above. Separate entities typically perform each layer of the protocol processing. The collection of entities for processing the various layers is often called a protocol stack. Id. 17

35 Ex.1008, Stevens1 at.034, Fig. 1.7 Starting from the lowest layer, the MAC layer (e.g., Ethernet) handles the actual transmission on a physical medium (e.g., Ethernet cables). The header of this layer includes a MAC address that is the address of a network interface on a local area network. Ex.1003, Horst Decl. 31. Next is the Internet layer (IP layer). The IP header includes source and destination IP addresses for identifying a computer or router at each end of the connection. Id. 33. Above the IP layer is the TCP layer. The TCP header includes port numbers, corresponding to the end points (e.g., client or server programs) sending 18

36 and receiving data. For example, the usual port number for World Wide Web (HTTP) servers is port 80. Id. 34. Considerable information must be tracked to guarantee reliability and maintain an open TCP connection, including sequence numbers, acknowledgement numbers, the sliding windows, TCP, IP and MAC addresses and more. Typically, the state information needed to maintain a TCP connection is held in a connection record also called the Transmission Control Block (TCB) in RFC 793. Ex.1007, RFC 793 at.024; Ex.1003, Horst Decl. 35. The combination of an IP address and TCP port number is called a socket. A TCP connection can be formed with a pair of sockets one for the source and another for the destination. Ex.1003, Horst Decl. 41. Establishing a connection over TCP is sometimes called opening a socket. Id. 43. To open a socket, an IP address and TCP port for an application endpoint at the other end of the connection are specified by the application opening the socket. Each user application typically has one or more areas of host memory in which it can (1) place data for transmission so that the protocol stack can retrieve it, encapsulate it in packets, and transmit it, and (2) receive data from the network placed there by the protocol stack (after stripping the MAC, IP and TCP headers from the packet). Id

37 4.2. UDP/IP Internet Protocol supports a second transport-layer protocol, the User Datagram Protocol (UDP). UDP is a connectionless protocol with no reliability or ordering guarantees. Id It is often used by client-server applications that use one request and one response instead of going to the trouble of establishing a continuing connection. Like TCP, UDP uses source and destination IP addresses and port numbers to identify the end points on the network. Ex.1006, Tanenbaum96 at Protocol Offload Protocol processing requires several operations on the data. To increase performance and reduce the demands on a host computer, many prior art solutions offload some (partial offload), or all (full offload), of this processing to a separate device, e.g., a network interface controller (NIC). See generally, Ex.1003, Horst Decl. Section V.C. As early as 1974, front-end protocol offload was already being considered for standardization as described in RFC 647, which describes a broad consensus that front-ending (i.e., protocol offloading) was desirable. Id. 55. RFC 929, published in 1984, describes several motivations for offloading protocol processing to an outboard processor: 20

38 There are two fundamental motivations for doing outboard processing. One is to conserve the Hosts resources (CPU cycles and memory) in a resource sharing intercomputer network, by offloading as much of the required networking software from the Hosts to Outboard Processing Environments (or "Network Front-Ends") as possible. The other is to facilitate procurement of implementations of the various intercomputer networking protocols for the several types of Host in play in a typical heterogeneous intercomputer network, by employing common implementations in the OPE. A third motivation, of basing a network security approach on trusted mandatory OPEs, will not be dealt with here, but is at least worthy of mention. Ex.1009, RFC 929 at.002; Ex.1003, Horst Decl. 57. RFC 929 identifies many protocols for offloading, including TCP and UDP. Ex.1009, RFC 929 at.013; Ex.1003, Horst Decl. 58. Between the publication of RFC 929 in 1984 and the October 14, 1996 critical date for the 1997 provisional application to which the 072 Patent claims priority, a great deal of work was published in the area of protocol offloading. See generally, Ex.1003, Horst Decl. Sections V.C.-V.D. This work specifically teaches the alleged inventions claimed in the 241 Patent. 5. OVERVIEW OF THE 241 PATENT The 241 Patent relates to offloading TCP protocol processing from a host onto an intelligent network interface card (INIC). Ex.1001, 241 Patent at 21

39 Abstract. The INIC permits two modes of operation: a fast-path (illustrated in red, below) in which protocol processing from the physical layer through the TCP layer is performed on the INIC, and a slow-path (illustrated in blue, below) in which network frames are handed to the host at the MAC layer and passed up through the host protocol stack conventionally. The concept is illustrated in Fig. 24, shown and described below: Ex.1001, 241 Patent Fig. 24 (annotated). The INIC uses a connection context to determine which path should be used for a received packet. The host may create the context by processing an initial request packet, e.g., as part of opening a connection. Id. at 10:8-16. The connection context for a packet is checked against a list. If the connection context is on the list, the packet is fast-pathed; otherwise it is slow-pathed. Id. 22

40 Independent claim 1 of the 241 Patent is directed to receive processing. It requires that packet headers are processed without an interrupt between network and transport layers, sorted into two types with one type including only data packets, and then data from data packets is placed into memory without any headers. Independent claims 9 and 17 are directed to transmit processing. Each requires that data be transferred to a network interface device, that the network interface device divides the data into segments, and that transmit packets are formed by the addition of multiple headers either at the same time or without an interrupt between layers. Independent claims 9 and 17 are substantially similar to each other. The dependent claims include processing a MAC layer header without an interrupt between the MAC and network layers (claim 2), processing an upper layer header to determine the destination in memory (claims 3 and 4), establishing a TCP connection (claim 5), determining if a packet has TCP/IP headers (claim 6), creating transmit packets by adding multiple headers at the same time (claim 7), and using a sequencer with microcode (claim 8). The dependent claims include that the data be created by a processor (claim 10), determining if incoming packets are part of the same transmission as outgoing packets (claim 11), establishing a TCP connection (claims 12, 24), using a template 23

41 header (claims 13, 19), using a Direct Memory access unit (claim 14), prepending an upper layer header (claims 15, 21), selecting whether a packet is processed by the network adapter or host (claim 16), receiving packets and processing multiple headers without an interrupt (claims 18, 22), a TCP connection is passed between the host and the adapter (claim 20), and using the upper layer header to determine a location in memory (claim 23) PATENT PROSECUTION HISTORY The application for the 241 Patent was filed on September 27, The then-pending claims were rejected on January 27, 2006 as unpatentable over several different combinations of prior art. After several amendments and further rejections, the Examiner allowed the claims, stating: Ex.1002, 241 File History, Notice of Allowability at.601. The 241 patent issued on February 26,

42 7. CLAIM CONSTRUCTION Applicable Law The broadest reasonable construction in light of the specification of the patent in which it appears applies to the 241 Patent C.F.R (b). Any ambiguity regarding the broadest reasonable construction of a claim term is resolved in favor of the broader construction absent amendment by the patent owner. Final Rule, 77 Fed. Reg , (Aug. 14, 2012) Construction of Claim Terms All claim terms not specifically addressed in this Section have been accorded their broadest reasonable interpretation as understood by a person of ordinary skill in the art and consistent with the specification of the 241 Patent. Petitioner respectfully submits that the following terms shall be construed for this IPR. 1 Petitioner expressly reserves the right to challenge in district court litigation one or more claims (and claim terms) of the 241 Patent for failure to satisfy the requirements of 35 U.S.C Petitioner expressly reserves the right to argue different or additional claim construction positions under Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) standard applied in district court. 25

43 [first/second] mechanism The term mechanism appears in challenged claims 1-5, 7, 8, 17, 20, and 23. Because mechanism is a nonce word and the claims fail to provide sufficient structure for the claimed mechanism, the term should be construed under 35 U.S.C. 112(6). Accordingly, the limitation requires disclosure in the patent specification of adequate corresponding structure to perform the claimed function. Here, the specification fails to provide adequate disclosure of the structures necessary to perform the functions and thus, the terms are indefinite Patent Owner s expert gives no weight to the claim terms In a co-pending litigation, Patent Owner contends that first mechanism should not be construed under 35 U.S.C Ex.1039, JCCS at.027. Instead, Patent Owner s expert argued in the co-pending litigation that the terms first mechanism and second mechanism should be given no weight at all. Specifically, Patent Owner s expert argued that first mechanism and second mechanism can be literally stricken from the claims because the terms do[] not change the scope of the claims. Ex.1062, Min Rebuttal Declaration at.124. Alacritech s expert provided the following exhibit to demonstrate that the terms first mechanism and second mechanism can be crossed out without changing the scope of the claims: 26

44 27

45 Ex.1062, Min Rebuttal Declaration at It is axiomatic, however, that all claim terms are consequential, and none can be so unimportant as to be ignored. See Flex-Rest, LLC v. Steelcase, Inc., 455 F.3d 1351, 1361 (Fed. Cir. 2006) (patentee s attempt to avoid the sidewall limitation by characterizing it as inconsequential disregards the basic patent law doctrine that every limitation of a claim is material. ). See also Warner-Jenkinson Co., Inc. v. Hilton Davis Chem. Co., 520 U.S. 17, 29 (1997) ( Each element contained in a patent claim is deemed material to defining the scope of the patented invention. ). 28

46 In the case where a claim limitation does not recite means there is a rebuttable presumption that does not apply. The presumption is overcome, however, when the claim term fails to recite sufficiently definite structure or else recites function without reciting sufficient structure for performing that function. Williamson v. Citrix Online, LLC, 792 F.3d 1339, 1348 (Fed. Cir. 2015)(en banc)(internal citations omitted). Williamson further states that, The standard is whether the words of the claim are understood by persons of ordinary skill in the art to have a sufficiently definite meaning as the name for structure. ). Id. at Patent Owner s expert inability to ascribe meaning to the term mechanism simply confirms that mechanism should be treated under As recited by the claims, mechanism is defined by what it does, without any regard to what it is. This is the classic case of a nonce word. See id. at 1339, ( Generic terms such as mechanism, element, device, and other nonce words that reflect nothing more than verbal constructs may be used in a claim in a manner that is tantamount to using the word means because they typically do not connote sufficiently definite structure and therefore may invoke 112, para. 6. ); see generally M.P.E.P Patent Owner, in the District Court, has argued that mechanism cannot be construed under because the claims in which mechanism appears are method 29

47 claims. For support, Patent Owner cites Uniloc USA, Inc. v. Autodesk, Inc., No. 2:15-cv-1187-JRG-RSP, 2016 WL , at *19-20 (E.D. Tex. July 7, 2016). In Uniloc, the District Court concluded that means-plus-function claiming is only permitted in apparatus claims. This District Court decision, however, directly contravenes well established Federal Circuit law that method claims may include means-plus-function elements. In Media Rights Techs., Inc. v. Capital One Fin. Corp., 800 F.3d 1366, 2015 U.S. App. LEXIS (Fed. Cir. 2015), for example, the Federal Circuit concluded that the term compliance mechanism in a method claim (even without the presumption) was properly construed under because [w]e have never found that the term mechanism without more connotes an identifiable structure; certainly, merely adding the modifier compliance to that term would not do so either. Id at Accordingly, mechanism should be construed under First mechanism: corresponding functions For claim 1, the first mechanism performs the functions of (1) processing the packets, so that for each packet, the network layer header and the transport layer header are validated without an interrupt being sent to the host computer dividing the processing of the network layer header and the transport layer header and (2) sending the data from each packet of the first type to a destination in memory allocated to an application without sending any of the media access 30

48 control layer headers, network layer headers or transport layer headers to the destination. Dependent claim 2 requires that the first mechanism perform the function of processing the headers without an intermediate interrupt dividing the processing. Dependent claim 7 requires the first mechanism performs the functions of (1) transmitting a second plurality of packets to the network, each of the second plurality of packets containing a media access control layer header, a network layer header and a transport layer header, (2) including processing the second plurality of packets, so that for each packet the media access control layer header, the network layer header and the transport layer header are prepended at one time as a packet header. Dependent claim 8 requires that the first mechanism is a sequencer running microcode. For claim 17, the first mechanism performs the function of providing a block of data and a TCP connection First mechanism: insufficient corresponding structure The 241 Patent does not disclose structure for performing the corresponding structures. At best, dependent claim 8 implies that the corresponding structure is a sequencer running microcode i.e., some type of software algorithm is necessary to perform the functions. The 241 Patent, however, does not provide any 31

49 description of an algorithm that addresses the recited functions and is therefore indefinite. Patent Owner argues in the District Court that should the term be treated under 112 6, the corresponding structure is a network interface device, a processor in a network interface device, and equivalents thereof or a host CPU operating a TCP protocol stack Ex.1039, JCCS at This corresponding structure, however, is nothing more than a recitation of generic, non-specific hardware and conflicts with dependent claim 8, which specifically states that the structure embodies microcode. Indeed, the specification support identified by Patent Owner in the litigation (7:42-58, 17:20-36; and Fig. 11) recites no code whatsoever. Moreover, the 241 Patent does not describe a generic, non-specific network interface device and processor. Instead, the 241 Patent discloses, for example, an intelligent network interface device. Ex.1001, 241 Patent at Abstract. That is, the 241 Patent only describes specialized devices for performing the claimed method. Ex.1003, Horst Decl Second mechanism: corresponding functions Dependent claim 3 (from claim 1) requires a second mechanism that performs the function of processing an upper layer thereby determining the destination. Dependent claim 4 requires that the second mechanism perform the function of processing for processing an upper layer header of at least one of the 32

50 packets of the second type. Dependent claim 5 requires that the second mechanism perform the function of processing a transport layer header of another packet. For claim 17, the second mechanism performs the functions of (1) dividing the block of data into multiple segments, and (2) prepending an outbound packet header to each of the segments without an interrupt dividing the prepending of the MAC layer header, the IP header, and the TCP header. Dependent claim 23 requires the first mechanism performs the function of processing an upper layer header of at least one of the packets, thereby determining the destination, wherein the upper layer header corresponds to a protocol layer above the transport layer Second mechanism: insufficient corresponding structure Like the first mechanism, the functions performed by the second mechanism would be performed by software code. The 241 Patent, however, does not provide any description of an algorithm that addresses the recited functions and is therefore indefinite. Similarly, the specification support identified by Patent Owner in the litigation (9:34-48, 9:66-10:23, 39:32-45, 43:9-35, Fig.4B) is devoid of code performing the recited functions. 33

51 without an interrupt dividing The term without an interrupt dividing appears in the following limitation of asserted claim 1 of the 241 Patent (Exhibit 4a) (claims 18 and 22 have similar limitations): processing the [received] packets by a first mechanism, so that for each packet the network layer header and the transport layer header are validated without an interrupt dividing the processing of the network layer header and the transport layer header Ex.1001, 241 Patent at claim 1 3. Petitioner contends that this term is indefinite. A person of ordinary skill in the art ( POSA ) would not understand the term because it does not make sense that a host processor interrupt divides processing that does not occur on the host processor. Ex.1003, Horst Decl Nor does it make sense to interrupt the processor to notify it that validation has occurred between the network layer and the transport layer because the processor is not involved in the validation of the headers for either protocol layer. Id. The specification makes clear that unlike much of the protocol processing at the network and transport layer (which occurs on the host processor on the slow-path), header validation for the network and 3 Emphasis added unless otherwise noted. 34

52 transport layers never occurs on the host processor. Id. An interrupt to the host processor would therefore not divide header validation processing. Id. 8. PERSON HAVING ORDINARY SKILL IN THE ART A person having ordinary skill in the art ( POSA ) with respect to the technology described in the 241 Patent would be a person with at least the equivalent of a B.S. degree in computer science, computer engineering or electrical engineering with at least five years of industry experience, including experience in computer architecture, network design, network protocols, software development, and hardware development. See id DESCRIPTION OF THE PRIOR ART 9.1. U.S. Patent No. 5,768,618 ( Erickson ) 4 Erickson describes an I/O device adapter that performs fast-path network protocol processing for UDP/IP and TCP/IP. Specifically, Erickson discloses an I/O device adapter that pre-negotiates most of the protocol header information for a transport layer communication. Basically, the I/O adapter receives during prenegotiation most of the information about the incoming/outgoing datagram (e.g., 4 Erickson was filed on Dec. 21, 1995 and issued on Jun. 16, 1998, and is therefore prior art at least under 102(e). See Ex.1005, Erickson. Erickson was not cited to or by the Examiner during prosecution of the 241 Patent. 35

53 most of the fields of the headers) except for the data following the headers. An exemplary header template is shown in Figure 7: Ex.1005, Erickson at Fig. 7, see also 2: The dotted lines in the figure (circumscribed in red) indicate the fields that change in consecutive packets. The solid lines in the figure (circumscribed in green) indicate fields that remain unchanged in consecutive packets. These constant fields are the pre-negotiated fields. Erikson discloses that almost everything about the datagram (much of the MAC, IP and transport layer (UDP or TCP) headers) is included in the pre-negotiated fields. Id. at 6:57-7:4, see also Figs. 6 36

54 and 7. A template, which is based on this pre-negotiated data, is stored in the I/O device memory. Id. at 7: To send data, the user process identifies a block of raw data to be transmitted and spanks (sets to 1) a GO register. Spanking the GO register triggers a script in the adapter. In response, the adapter takes the raw data, encapsulates it into a packet with UDP, IP, and MAC headers using a header template identified by the script, and transmits the packet. See id. at 7:39-8:6. As part of creating the final packet, the script populates the header template with the appropriate data for those fields that were not pre-negotiated. While Erickson provides a detailed example for UDP (a transport protocol that, like TCP/IP, runs on top of IP), Erickson describes scripts for a variety of protocols, including TCP/IP. Id. at 5: Moreover, in the case of TCP, Erickson directs the user to the 1981 edition of Tanenbaum s Computer Networks textbook for details on TCP. Id. at 4: The 1996 edition of Tanenbaum is discussed above, and was the current version of the textbook as of the October 14, 1996, the critical date for the provisional application from which the 241 Patent claims priority. 37

55 9.2. Tanenbaum96: A. Tanenbaum, Computer Networks, 3rd ed. (1996) 5 Tanenbaum, Computer Networks, (Tanenbaum96) is a widely-cited textbook covering network hardware, software, protocols and standards. It was published on or before August 9, 1996 and is therefore at least 102(b) prior art to the earliest possible priority date for the 241 Patent claims. Ex.1011, Librarian Declaration of Rice Majors. An earlier version of Tanenbaum96 was incorporated by reference by Erickson. Tanenbaum96 recognizes that an obstacle to fast networking is protocol software, and teaches fast-path processing for TCP as a solution. Ex.1006, Tanenbaum96 at Specifically, Tanenbaum96 teaches that in the normal case of an established TCP connection, only a few fields of the header change in consecutive packets. The fields that are the same between packets are shaded in the illustration below. 5 Tanenbaum96 was cited by Applicant, along with roughly 100 additional references, during the prosecution of the 241 Patent; it was not discussed in the prosecution. 38

56 Ex.1006, Tanenbaum96 at.584, Fig (emphasis added). Tanenbaum96, like Erickson, takes advantage of the similarity of packets in a normal data flow and stores a prototype header (i.e., the expected normal case) in a transport entity. The transport entity can be in the operating system kernel, in a separate user process, in a library package bound into network applications, or on the network interface card. Id. at.498. When packets are to be sent, a test is made to determine whether the packets match the prototype header (i.e., conforms to the normal case). If so, the packets are fast-pathed, otherwise the packets are processed normally (i.e., in the slow-path). Id. at.583. ( If all conditions are met, 39

57 no further tests are needed and the fast-path through the sending transport entity can be taken. ) Tanenbaum96 also teaches TCP fast-path receiving. Specifically, when a packet is received, the source and destination addresses and ports are hashed. The hash is used to determine whether the incoming packet corresponds to the connection record of a previously received packet. A connection record maintains the TCP state and includes the source and destination addresses and ports. If the connection record matches, the packet is sent to the fast-path and the connection record is updated in the hash table to reflect the new packet. Id. at This is also known as header prediction. Id Gigabit Ethernet Technical Brief: Achieving End-to-End Performance by Alteon Networks (Ex.1033, Alteon ) Alteon, Gigabit Ethernet Technical Brief: Achieving End-to-End Performance is a technical brief describing multiple generations of Ethernet adapters, including Alteon s third generation intelligent network adapter with an on board processor. Alteon was published on or before January 26, 2007 and is therefore at least 102(a) prior art to the earliest possible priority date for the 241 Patent claims. Ex.1011, Librarian Declaration of Rice Majors. 40

58 The Alteon adapter was able to transfer the data of packets directly into the application memory space (via a buffer) without passing through the TCP/IP protocol stack on the host as shown in Figure 16. Ex.1033, Alteon at.022, Fig.16. The Alteon adapter would validate the packets, but the protocol stack would still be involved in the process as it was responsible for ensuring that the data arrives in the application memory buffer. Id. at.023. This technology allows a single interrupt to be issued for multiple data packets. Id. at.022. Alteon also discloses an older Second Generation Ethernet Adapter. This adapter would utilize a protocol stack on the host analyze transport and network layer headers as well as headers above the transport layer for incoming packets. 41

59 Once the protocol stack would return a location, the network adapter would place the data of the packet directly into the application memory. Ex.1033, Alteon at.021, Fig Alacritech s expert admits that almost all of the limitations are found in the prior art As part of the claim construction proceedings during the related district court litigation, Alacritech submitted the declaration of Dr. Paul Min in support of its claim construction positions. During his deposition, Dr. Min admitted that each element of claim 17 (which is substantially similar to claim 9) was met by a generic prior-art computer used to browse the web in 1996 with the exception of the Wherein the prepending of each outbound packet header occurs without an interrupt dividing the prepending of the outbound media access control layer 42

60 header, the outbound IP header, and the outbound TCP header limitation, at least in isolation: Ex.1077, Min Depo at 269: Motivations To Combine Erickson and Tanenbaum96 Erickson s disclosure, which provides several exemplary embodiments for UDP, is equally applicable to TCP. Ex.1005, Erickson at 5: ( Each type of protocol will have its own script. Types of protocols include, but are not limited to, TCP/IP, UDP/IP, BYNET lightweight datagrams, deliberate shared memory, 43

61 active message handler, SCSI, and File [sic] Channel. ). Erickson, however, directs most of its discussion to UDP. Details of TCP, however, are provided by Tanenbaum96. It would have been obvious to a POSA to have consulted Tanenbaum96 and combined it with Erickson. First, Erickson provides an express motivation to the user to consult the 1981 version of the Tanenbaum textbook Erickson incorporates it by reference. Ex.1005, Erickson at 4:34-43; Ex.1003, Horst Decl Tanenbaum96, the prior art used in this petition, is the third edition of the 1981 Tanenbaum book ( Tanenbaum81 ). Ex.1006, Tanenbaum96 at.005. The 1996 version was the current edition as of the October 14, 1996 critical date for the October 14, 1997 provisional application of which the 241 Patent claims priority. A POSA working on October 13, 1996 would have been motivated, in view of the incorporation by reference, to consult Tanenbaum96, the then-current edition of the Tanenbaum81 textbook cited by Erickson. Ex.1003, Horst Decl In 1996, with the growth of the Internet and World Wide Web, TCP/IP was becoming very popular. Id Accordingly, a POSA would have been motivated to implement the TCP/IP fast-path protocol processing described by Erickson, using Erickson s Ethernet I/O device adapter, and would have further been motivated to consult Tanenbaum96 to do so. Id. Indeed, given TCP/IP s popularity among the finite number of networking protocols, it would have been 44

62 obvious to try, i.e., look to Tanenbaum96 and accordingly try to implement a TCP/IP connection on the Erickson I/O device adapter. Id Further, given that a POSA would have understood TCP/IP well, and that the standards for TCP/IP are set forth in well-known Request for Comments (RFCs), a POSA would have had a high expectation of success in implementing TCP/IP on Erickson s I/O device adapter. Id. A POSA would have readily understood that Tanenbaum96 s teachings of fast-path TCP processing using a prototype header, connection records, and header prediction correspond to, and could be used to improve, Erickson s template header, endpoint information, pre-negotiated protocol information, and UDP script to perform TCP protocol processing. Id For transmission, Erickson teaches an adapter script that performs fast-path UDP/IP processing by updating IP protocol information including IP Length, IP Datagram ID, IP Checksum, and transport-layer UDP protocol information, including UDP Length and UDP Checksum. Ex.1005, Erickson at 7:48-63; Ex.1003, Horst Decl These fields are shown as shaded in Erickson Figure 6. The specification states that Only the shaded fields in FIG. 6, and the user data 610, need to be changed on a per-datagram basis. Ex.1005, Erickson at 7:

63 Tanenbaum96 also teaches an adapter that performs fast-path TCP/IP protocol processing by updating the same IP protocol information, including IP Length, IP Datagram ID, IP Checksum, and directly corresponding transport-layer TCP information, including the TCP Sequence number and TCP Checksum. Ex.1003, Horst Decl These fields are shown as unshaded in Tanenbaum96 Fig (Erickson has them shaded). The corresponding text states: Fig. 6-50(a) shows the TCP header. The fields that are the same between consecutive TPDUs on a one-way flow are shaded. Ex.1006, Tanenbaum96 at.584. A POSA would therefore be motivated to use Tanenbaum96 s teachings of fast-path TCP transmit processing using a TCP prototype header to improve Erickson s fast-path TCP transmit processing using a header template. Ex.1003, Horst Decl For receiving, Erickson discloses an endpoint table and protocol scripts which store protocol information and indicate how data is to be transferred from the network interface device to portions of main memory associated with a user process. Ex.1005, Erickson at 5:59-67; Ex.1003, Horst Decl A POSA would understand that Erickson s endpoint table, pre-negotiated protocol information and protocol scripts correspond to Tanenbaum96 s connection records, and that Erickson s looking up endpoint protocol information in the endpoint table corresponds to Tanenbaum96 s looking up a connection record. Ex.1006, 46

64 Tanenbaum96 at ; Ex.1003, Horst Decl A POSA would therefore be motivated to use the Tanenbaum96 teachings to improve Erickson s fast-path receive processing by including TCP. Ex.1003, Horst Decl Combining Tanenbaum96 s TCP/IP processing with Erickson would have been understood as combining known methods to yield predictable results. Id As Dr. Horst explains, the TCP/IP protocols and fast-path TCP processing that Tanenbaum96 teaches were well-known, were directly applicable to Erickson s I/O device adapter, and a POSA would have had a high expectation of success in adapting Erickson s I/O device adapter to offload a TCP/IP protocol processing. Id. at Section X.A Motivations To Combine Erickson, Tanenbaum96, and Alteon A chief concern of Erickson is to avoid intervention of the operating system on a per I/O basis. Ex.1005, Erickson at 3:9-10; Ex.1003, Horst Decl Erickson partially addresses this problem by using scripts on the I/O device to process data. Alteon addresses a similar problem but addresses the problem by reducing the number of interrupts to the host: Using an intelligent adapter with an onboard RISC-based processor specially designed for embedded application processing, Alteon s Gigabit Ethernet technology not only reduces the number of times data is copied among processing entities, it allows a single interrupt to be issued for multiple data packets radically altering the ratio of 47

65 interrupts to packets, and eliminating the scalability problems inherent in older adapter designs. Ex.1033, Alteon at.022. A POSA would have recognized that it would have been obvious to improve the combination of Erickson and Tanenbaum96 by adapting Erickson to include Alteon s single interrupt processing. Ex.1003, Horst Decl A POSA would have been motivated to make such an adaption because, as Alteon teaches, single interrupt processing reduces the need for the host computer to insert itself into the process. Id. Such a combination of Erickson and Tanenbaum96 with Alteon would have provided an I/O device that would even better address the problems Erickson is seeking to solve. Id. Moreover, Erickson and Tanenbaum96 in combination with Alteon would not have frustrated the operation of Erickson and Tanenbaum96. Id Erickson in combination with Tanenbaum96 is already offloading processing (as much as it can) to the I/O device. Id. Alteon simply reduces the number of interrupts needed to process the data, but the data is still being processed at an I/O device. Id. Accordingly, Alteon provides a significant increase in performance yet does not alter Erickson and Tanenbaum96 in a way that would frustrate the operation of Erickson and Tanenbaum96. Id. Put differently, Alteon is simply makes clear that intra-packet host interrupts are not needed. Id. 48

66 10. GROUND #1 6 : CLAIMS 1-8, 18, 22, AND 23 ARE UNPATENTABLE AS OBVIOUS OVER ERICKSON IN COMBINATION WITH TANENBAUM96 AND ALTEON As set forth below, Erickson in combination with Tanenbaum96 and Alteon renders obvious claims 1-8 of the 241 Patent. As discussed above, Erickson discloses an I/O device that performs fast-path network protocol processing. While Erickson discloses that its method and system works equally well for TCP/IP, Erickson s embodiment focuses heavily on UDP and not TCP. Erickson does, however, incorporate Tanenbaum81 for its description and discussion of TCP. Erickson at 4: The combination below simply takes the disclosure of Erickson and uses Tanenbaum96 (a later version of Tanenbaum81) to fill in the missing, yet well-known aspects of TCP. Ex.1003, Horst Decl. at Section X.A. Erickson and Tanenbaum96 are further combined with Alteon. Alteon provides a specific disclosure that stack processing can be achieved with a single interrupt. Id. at Section X.B. Motivations for the combination are set forth above. 6 Ground #1 is supported by Dr. Horst s Declaration as set forth in Appendix A. Ex.1003, Horst Decl., Appendix A. 49

67 10.1. Claim 1 is unpatentable as obvious over Erickson in combination with Tanenbaum96 and Alteon [1.P] A method for network communication, the method comprising: Erickson discloses this limitation. Specifically, Erickson discloses an I/O device adapter 314 for communications over a network. Ex.1005, Erickson at 1:63-67 ( To overcome the limitations in the prior art described above the present invention discloses a method of controlling an input/output (I/O) device connected to a computer to facilitate fast I/O data transfers. ), id. at 3:23-36 ( FIG. 1. is a flow diagram illustrating a conventional I/O data flow between a sender and a receiver. ) [1.1] receiving a plurality of packets from the network, each of the packets including a media access control layer header, a network layer header and a transport layer header; Erickson discloses this limitation. Specifically, Erickson discloses receiving packets over an Ethernet network having a MAC layer header (Ethernet), a 7 Note that Erickson also refers to the computer as a sender and receiver when discussing the computer sending data (sender) and receiving data (receiver). Id. at 3:

68 network layer header (IP), and a transport layer header (UDP/TCP) as shown in Fig. 6: Ex.1005, Erickson at Fig. 6 (annotated), 6:48-56; see Ex.1003, Horst Decl. A-2 (describing that a POSA would understand the Ethernet layer to be the MAC layer, the IP layer to be the network layer, and UDP/IP to be the transport layer). 51

69 While Fig. 6 is specific to UDP, Erickson discloses that it is equally applicable to other protocols, including TCP. See Ex.1005, Erickson at 5:47-51 ( Types of protocols include... TCP/IP ). As described in Tanenbaum96, TCP includes transport layer connections. Ex.1006, Tanenbaum96 at.539 ( The Internet has two main protocols in the transport layer, a connection oriented protocol and a connectionless one. In the following sections we will study both of them. The connection-oriented protocol is TCP. ). See also id. at Fig Accordingly, Erickson discloses this limitation. 52

70 [1.2] processing the packets by a first mechanism 8, so that for each packet the network layer header and the transport layer header are validated without an interrupt dividing the processing of the network layer header and the transport layer header; Erickson in combination with Alteon discloses this limitation. Specifically, Erickson discloses an I/O device ( first mechanism ) that processes packets by executing scripts (program code). A script is prepared by the operating system for the I/O device adapter to execute each time the specific user process programs its specific virtual hardware. Ex.1005, Erickson at 4: The script validates the network and transport layer 8 Petitioner maintains that this term and all other claimed mechanisms require construction as means plus function terms. The specification does not provide adequate structural disclosure for any claimed mechanism and accordingly the terms are indefinite. However, to the extent that the PTAB determines that mechanism is not subject to 112(6), the prior art performs the claimed functions as detailed in these sections. Similarly, if the PTAB adopts the Petitioner s 112(6) corresponding structure, all the prior art use a network interface device, a processor in a network interface device or a host CPU operating a TCP protocol stack for performing the functions. 53

71 headers by performing checksum on each header. Id. at 8:10-25 (disclosing a checksum check on the IP and UDP layer). See also id. at 7:50-64 (example script that executes arithmetic functions to calculate a checksum); see further Ex.1003, Horst Decl. A-5 (discussing that the purpose of a checksum is for validation.). Erickson, however, does not disclose whether there is an interrupt issued between validation of the network and transport layer header. Alteon discloses the absence of interrupts between validation of the network and transport layer headers by disclosing a single interrupt for multiple data packets. If there was an interrupt after validation of every network layer header, it would not be possible to have only one interrupt for multiple data packets. Id. Alteon, like Erickson, discloses that it validates network and transport layer headers by performing a checksum. Ex.1033, Alteon at.015. ( Interacting with protocol layers adding protocol headers, removing protocol headers, generating checksums, and so on ). Alteon discloses that the layer processing occurs without an intermediate interrupt. Id. at.022. ( Alteon s Gigabit Ethernet technology not only reduces the number of times data is copied among processing entities, it allows a single interrupt to be issued for multiple data packets ), see also id.: Alteon Gigabit Ethernet adapters have an interrupt timer that determines when to interrupt a host CPU. This allows a single interrupt to be issued for multiple data packets that are sent into the 54

72 Id. at.023. operating system buffer space. It also allows for adaptive interrupts; that is, the NIC can alter the number of interrupts issued per second based on network usage. Accordingly, Erickson in combination with Alteon discloses processing the packets by a first mechanism (I/O device), so that for each packet the network layer header and the transport layer header are validated (checksum) without an interrupt dividing the processing of the network layer header and the transport layer header (Alteon s processing method) [1.3] sorting the packets, dependent upon the processing, into first and second types of packets, so that the packets of the first type each contain data; Erickson discloses that packets are processed. Erickson further discloses that consecutive packets typically have substantially similar header information. See Ex.1005, Erickson at Fig. 6. Erickson incorporates Tanenbaum81 by reference. Id. at 4: Tanenbaum96, the later edition of Tanenbaum81, discloses that the substantial similarity in header information can be used to establish a fast-path processing path for packets that conform to the expected pattern (called header prediction). Ex.1006, Tanenbaum96 at In Tanenbaum96, the fast-path is triggered when certain conditions are met. That is, Tanenbaum96 teaches that a subset of the expected information is checked, and if 55

73 confirmed, that packet is fast-pathed without checking the remaining information. Id. at.585. ( The general scheme of first making a quick check to see if the header is what is expected, and having a special procedure to handle that case, is called header prediction. Many TCP implementations use it. ). Accordingly, Erickson in combination with Tanenbaum96 discloses an I/O device with packet sorting functionality (fast or slow path). Tanenbaum96 notes that many TCP implementations [do this]. Id. Tanenbaum96 also discloses that this sorting can occur at an I/O device. Id. The packets of the first type contain data. See Ex.1005, Erickson at Fig. 6 (having User Data 610) [1.4] sending, by the first mechanism, the data from each packet of the first type to a destination in memory allocated to an application without sending any of the media access control layer headers, network layer headers or transport layer headers to the destination. Erickson in combination with Tanenbaum96 and Alteon discloses this limitation. In the previous limitation, packets are sorted by type with the first type containing data. To finish processing the data packets, data is written into memory. FIG. 4 is a block diagram describing a direct application interface (DAI) and routing of data between processes and an external data connection which is compatible with the present invention. Processes 402 and 404 transmit and receive information directly to and from an 56

74 interconnect 410 (e.g., I/O device adapter) through the DAI interface 408. The information coming from the interconnect 410 is routed directly to a process 402 or 404 by use of virtual hardware and registers, rather than using a traditional operating system interface 406. Ex.1005, Erickson at 4:53-5:14, Fig. 4, see also id. at Fig. 3 (illustrating that I/O device adapter 314 sends data to applications 302 and 304 that reside within the memory of the host computer), see also id. at 6:1-41, 8:17-37; and Ex.1003, Horst Decl. at Section V.H.1 (explaining using pointer to write data directly from I/O device to host memory). Alteon discloses a second generation NIC detailing how data may be moved into the application space. For example, the second generation Alteon NIC moves data directly into application space after receiving a location from the protocol stack. Ex.1033, Alteon at

75 Step 2 above says that the protocol stack moves the data minus the header (i.e., Ethernet, IP, and TCP headers) to the application memory. Alteon clarifies that the transfer of data to application memory is without headers. Ex.1003, Horst Decl. A-13, A Claim 2 is unpatentable as obvious over Erickson in combination with Tanenbaum96 and Alteon [2.1] The method of claim 1, wherein processing the packets by a first mechanism further comprises: processing the media access control layer header for each packet without an interrupt dividing the processing of the media access control layer header and the network layer header. Erickson in combination with Alteon discloses this limitation. As discussed in claim limitation [1.2], Alteon discloses processing headers without an interrupt dividing the processing. Ex.1033, Alteon at Accordingly, Erickson in combination with Alteon discloses wherein processing the packets by a first mechanism (I/O device) further comprises: processing the media access control layer header (Ethernet header) for each packet without an interrupt dividing the processing (method of Alteon) of the media access control layer header (Ethernet header) and the network layer header (IP header). 58

76 10.3. Claim 3 is unpatentable as obvious over Erickson in combination with Tanenbaum96 and Alteon [3.1] The method of claim 1, further comprising: processing an upper layer header of at least one of the packets by a second mechanism, thereby determining the destination, wherein the upper layer header corresponds to a protocol layer above the transport layer. Tanenbaum96 discloses this limitation. As discussed above, Erickson in combination with Tanenbaum96 teaches that packets are sorted for fast or slow path processing at the I/O device. In the case of slow-path processing (i.e., where a packet header does not conform to an expected packet header and may be a control packet that does not contain data), full protocol stack processing occurs on the host. Tanenbaum96 discloses that full protocol stack occurs at a TCP transport entity, which may be part of the kernel, i.e., host computer. Ex.1006, Tanenbaum96 at Accordingly, when a packet is slow-pathed, it will be sent to the kernel (a second mechanism) for processing including application layer headers, which are above the TCP header. Tanenbaum96 discloses many different application layers above the transport layer in the TCP/IP model, including electronic mail (SMTP): 59

77 Id. at.055, Fig In the case of electronic mail, Tanenbaum96 discloses that the (upper layer) electronic mail headers include fields that identify the destination of the packet, including the To: field that identifies the address(es) of primary recipients: Id. at.669, Fig Tanenbaum96 also discloses that a system may allow users to create mailboxes to store incoming . Id. at.663. Thus, the To: field of an message header provides a destination to the location in memory for a particular mailbox as recited by this limitation. Ex.1003, Horst Decl. A-16, A