UNITED STATES DISTRICT COURT
`EASTERN IDISTRICT OF TEXAS
`MARSHALL DTVISNON
`
`ALACRITECH, INC.,
`
`Plaintiff,
`
`Case No. 2:16-cv-693-RWS
`
`CENTI.]RYLINK COMMUNICATIONS
`LLC, et aI.
`
`Defendants.
`
`ALACRITECH, INC.,
`
`Plaintiff,
`
`WINSTRON COR-PORATION, et al.,
`
`ALACRMECH, [qC.,
`
`DELL INC.^
`
`Defendants.
`
`Pl aintiff,
`
`Defendant.
`
`LEAD CASE
`
`ruRY TRIAL DEMANDED
`
`Case No. 2:15-cv-692-RWS
`
`ruRY TRIAL DEMANDED
`
`MEMBER CASE
`
`Case No. 2:16.cv-695-RWS
`
`ruRY TRIAL DEMANDED
`
`MEMBER CASE
`
`(APPENDIX A)
`REPORT OF ALACRIIIECIN'S EXPERT
`DR. KEVIN C. ALMEROTH
`CONCERNING INTEL'S INFT.INGEMENT
`
`RESIIRICTED - ATTORTIEYS' EYES ONILY - INTEL ADDENIDUM]/RESTRICTED
`CONFIDENTL{L - SOURCE CODE
`
`INTEL EX. 1249.001
`
`

`

`RESTzuMED _ ATTORNEYS' EI'ES ONLY . BIIEL ADDEI'{DUM/'RES:IIRICTED CONFIDENTIAL _
`SOURCE CODE
`
`TABLE OF CONTENTS
`
`I.
`
`INTEL'S RSC PRODUC]IS IN]FRINGE TTM ALA.CRTTECX{ PATENTS......,,..,,.,....... I]
`A.
`
`Background on R.SC
`
`ll
`
`B.
`C.
`
`Intel' s Aacused RSC Product Families....-...-..
`
`5
`
`Each of Intel's RSC Producr Families lnfringe Each ofAlacritsch's Asserted
`"R.eoeive Sirdel Claims................
`.....................9
`11. Intel trnfringes Claims 1 and 22 ofthe'205 Patent
`
`9
`
`2.
`
`3.
`
`4.
`
`5.
`
`Indirect Infringernent
`
`a.
`b.
`Intel )lnfringes Clairns l, 2, 3, and 4 of the '036 Patent........
`a.
`Direct Infringoment......
`b.
`
`Indirect Infringernent
`
`Intel Ilnfiinges Clairn I of the '241 Patent
`
`b.
`
`Indirectlnfringement
`
`23
`
`25
`
`..........25
`
`........_..35
`
`37
`
`........46
`
`Intel Ilnfringes Clairns 32 and41 of the'880 Patent......... ....................... 48
`
`b.
`
`IndirectInfringement............
`
`Intel Infringes Clairns l7 andl 22 of the '948 Patent
`
`b.
`
`Indirect Infringement ............
`
`67
`
`...69
`
`84
`
`D.
`E.
`Response to lkrtel's Disclosed Theories of Noninfrirngement
`88
`III. INTEL'S LSO PR"ODUCTS INFRINGE THE ALACRITEC}I PATENTS...................93
`A.
`
`6/
`
`93
`
`Intel [nad]Pre-suit Hnowledge of the Patents-In-Suit
`
`Background on LSO
`
`INTEL EX. 1249.002
`
`

`

`RESTRICTED - AT'IIORNEYS' EYES ONLY - INTEn- AIDDENTDUM/RESTRICTED CONFIDENTIAL -
`SOURCE COIDE
`
`C.
`
`Each of Intel's LSo Frodluct FanTilies Infringe Eaclh of Anacritech's Assertcd
`"Send Side" C1aims.".......-...-..
`...................... 107
`1.
`Intel lnfringes Clairns I and 12 ofthe '241Patent
`a.
`
`108
`
`10E
`
`Direct Infringement..................
`
`2.
`
`Intel Infringes Claims 1, 15, and 17 of the '072 Patent......................... 151
`
`br
`
`Indirectlnfringernent
`
`?31
`
`Intel Had Pre-suit Knowledge of the Patents-In-Suit
`
`224
`
`D.
`E.
`226
`Response to Intel's Disolosed Theories of Noninfringement
`M. ABSENCE OF'ACCEPTABLE NON-INFRINGI]\IG SUBSI]I.TTUTES............".........,230
`A.
`
`There Are No ,Acceptable Altematives to Performing the Functionality in the
`RISC Claims.......
`
`234
`
`B.
`
`There Are No dcceptable Altematives to Performing thd Funotionality in the
`LS0 Claims.....".
`
`239
`
`lll
`
`INTEL EX. 1249.003
`
`

`

`RESTRICTED - ATTORNEYS, EYES ONLY - INTEL ADDENDUI?URESTRICTED CONFIDENTIAL _
`.SOI]RCE CODE
`
`I.
`
`INTEL'S R.SC PRODUCTS INFRII{GE THE ALACRITECH PA.TENTS
`A.
`Background on RSC
`1. As I discuss in the Background of Networking Technology seclion in the mairn
`
`report, network processing typically progresses throurgh a series of layers. When receiving data
`
`from a network, those layers generally require stripping various headers off the packets and
`
`checking for the various error conditions that can arise. As discussed abovq these repeated
`
`verification, and headler removal steps are traditionally performed by the CPU, which (for large
`
`receives) can eat up a lot of the processing power of the CPU.
`2.
`
`"RSC" is short for "Receive Segment Coalescing" or "Receive Side Coa,lescing."
`
`"RSC is a stateless offload technology that helps reduce CPU utilization for network processing
`
`on the receive sidb by offloading tasks from the CPU to an RSC-capable network adapter."
`
`(Receive Segment Coalescing, BATES ALA00009425-26 ("Microsoft RSC').) "RSC enables an
`
`FiISC-capable network interface card to do the following:
`, . Plrse multiple TCF/IP packets and strip the headers frorn subsequent pachets while
`preserving the payload of each packet.
`. Join the oombinod payloads of the multiple packets into one packet.
`r Send the single packet, which contains the payload of multiple packets, to the network
`stack for subsequent delivery to applications."
`
`(.Id.) In other words, RSC allows the metwork interface card to process and remove the TCP and
`
`IP layers frorn incoming packets, combine the data or "payload" for those packets into one large
`
`logical packet, then send that packet-which contains the data frorn multiple packets-to the host
`
`computer.
`3.
`Iarger receive segments." (BATES 88800DOC031036 - 32447 ("Niantic Datasheet") at $
`
`Intel's documents confirm that "RSC coalesces incoming TCPim paekets into
`
`1
`
`INTEL EX. 1249.004
`
`

`

`RESTRICTED _ ATTORNIEYS' EYES ONLY _ INTEL ADDENDUM/RESTRICTED CONFIDEhITIAL _
`SOIURCE CODE
`
`7.1L.3
`
`Flow ldentiflcnt***n and RSC Csntext
`I'{atching
`
`TCp/lP Facketis R6!{ is ld€rrtittrd by its four tud:s: SotJrc. / nestlnatiort In tddmsset dld
`tr.ides are cornpared agalnst tie Iiorry
`Source,/ Oes*instiffi TCP p{rt nutnbers. ']'t'tes€
`Jdan$ficaaiorl fields storcd in th+ a(cfvB RS.c coril*xts {fised in lbhl* ?-*:}, CDmparison
`ls d$ne ln filo Slas€s:
`' |.iinh Compare - Hardvrara comrutes a hash valle of S1c fo{r rlp,es {ar €adr
`fle$.
`The hash v6lue ts storEd ki the &5C coltext til$e" Il i. u6ed for rl$con opomhathbh 6f
`inc.omirqg pack€t 16 corfipired agEinit the
`the carnp*re bgic. ltre hash valu€ of tfte
`hnsh val$e5 ol al} RSC (rfltexlt, l{o mateh b€t$.etn
`the tr?o hash valuds rfieafts t}|al
`xs no valid cpntext of tiE sarne ftrcw.
`tll€l€
`r FerfE{t t iatdr * llardlvare d}ecks tt}e four tuphs of Sle RSC cofitBxt &at pess€d the
`firsn stes with the recdved fram*.
`* A rfiatch betideefi tha fwo maans that en ac0\E RSC sr}text ts fuurd,
`tie t$ro irldice&s a hash c{rllisio{r. whi{fi causes a aomplduan
`- lttgmatdl betw€en
`0f the tollided RSC.
`. In a y (3s* sf contrxt rfiisrngtdr, , ns,1, cont€xi miBht bu op€ned ar dssshed in
`s*f,{irfi 7.11.3"
`. tf the pad{et5 fls{s matt,tes an fi*lve fisc {fitex alxen the packet mtght be
`appended to ttp existing RSC as descr&ed in sEtfkr} ].i1.4.
`
`(Niantic Datasheet at $ 7.11.2; see a/so Sageville Datasheet at $ 7.10.2; Twinville Datasheet at $
`
`7.1 1 .2; Broadwell DE Datasheet at $ 7.9.2; Denverton Datasheet at $ 5.9.2; llouzon Dep. Tl. 198:4
`
`through 200:19; id. 217:15-25; Sarangam Dep. Tr.23912 ttnough 240:23.)
`61 . Claim 32[cl: "generating a flow key from saidl source identifier and said destination
`
`identifier to identify a cornrnunication flow comprising said packet, wherein said flow key includles
`
`a TCP connection for the communication flow and a frrst hop medium access control (MAC) Iayer
`
`address" After extractirng the source and destination TCF ports and the source and destinatiion IP
`
`addresses, the accusedl RSC products generate a hash value based on those four tuples. Tbat hash
`
`value is then used to identify an active RSC context, and is thus a flow key or "context identirfier"
`
`as construed by the Court:
`
`50
`
`INTEL EX. 1249.005
`
`

`

`RESTRICTED _ ATTORNEYS' EYES ONLY - INTEIL ADDENDUM],'RESTR]CTE]D CONFIDENTIAL _
`SOURCE CODE
`
`7.11.?
`
`FIow [dentificatisn and R$C Cnntext
`Matching
`
`-fCP/lP ptcketk flow is idefitilied by its f$ur tuples: s*urca / D.stinauon Ip sddrersrs snd
`Ssurcs,1 Pestinatiofl TCP port nurnbers. ftese trples ars cemparcd &Saln* the fisqr
`Idanti$aation lieldr stsred in the xtive R$C csrltexB {licle{, ln hble 7-S?}, Comparison
`l$ dofie h two pha$*s:
`+ lle$h Cornpar€ - fNard$ara ernprrtcs a hash valirt 0{ ttB four tudes for eadt flovi.
`. Ttre hash r4aluc as sto.dd ifl th* RSC conre$ tabl€.
`i! i$ used f,ar silicon dp$mizaliofi of
`li€
`rompare lo$ic. Th€ ha6h r,alre ef the incor13ing packet l$ erhpared againgt the
`ha$fi valu€s of all qSC coflt€rts,
`l'i6 r'iatch bettsreo S'te tv{o harh values rr}e6 s that
`t*ere is no rralid mnt€}ft sf the safie fi€$.
`. Psfe* &atcil - l*irdr,yarc {trteck'. the iour tuFlG rf ttf RSC csfiext that pa$6ed 9]e
`first itep with the received frarne,
`* A rnatch het$eea the n{o mean: that a aEtive *SC corito$ l$ found.
`- l'lisrnatrh be{lneeri th6lwo 1nd.{citc6 a hash ealll{lon. !,rfilrh caus&6 b cofirplettrBn
`0f the coHide{ RSC,
`r In any (ase of contdxt rni$ftatch, i new cor*ext might ba opanEd as d6{(ribed ifi
`5*ctiril 7.11.3"
`. lf the paqkett flgw rnatctres an a$ive *$E eontext thed 6re pad{€t migln be
`:ppended to the Existing R$C as described in s&.?iol} x,i:.{.
`
`(Niantic Datasheet at E'1 "11.2; see also Sageville Datasheet at $ 7.10.2; Twinville Datasheet at $
`
`7.11,2; Broadwell DE Datasheet at fi 7.9.2; Denverton Datasheet at $ 5"9.2; see also Sarungarn
`
`Dep. Tr. 239 :12 through 240: 23.)
`62. Clailm 32[d]: "determining whether a header in said header portion confonns to d
`
`pre-selected protocol" The accused RSC products perforrn a variety of tests on an incoming packet
`
`to determine whether it is eligible for RSC processing. Among other things, they test whettrer the
`packet conlorms to the pre-selected TCP/P protocol, specifically whether it (l) contains no
`
`TCP/IP checksurn emors, (2) irs of the TCP/IPv4 packet type, (3) droes not contain a fragmented
`
`TCP segment, (4) dloes not have ce tain flags active, and (5) does not carry any TCF option headers.
`
`(Niantic Datasheet at $ 7.11.1; see alsa Sageville Datasheet at $ 7.10.1; Twinville Datasheet at $
`
`7.i 1.1; Broadwell DE at $ 7.9.1; Denverton Datasheet at $ 5.9.11 Gutman Dep, Tr. 79: l6 through
`
`80:8; llouzon Dep. Tr. 198:4 through 200:19; id.2l'l:15-251, Sarangam Dep.'1i.r.220:8 tkough
`
`221:13.)
`
`51
`
`INTEL EX. 1249.006
`
`