`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`________________
`
`
`CAVIUM, INC.,
`
`Petitioners,
`
`v.
`
`ALACRITECH INC.,
`
`Patent Owner.
`________________
`
`Case IPR2017-013921
`U.S. Patent No. 7,337,241
`________________
`
`
`PATENT OWNER’S EXHIBIT 2305
`
`DECLARATION OF KEVIN ALMEROTH, PH.D.
`
`IN SUPPORT OF PATENT OWNER’S REPLY TO PATENT OWNER’S
`
`CONTINGENT MOTION TO AMEND UNDER 37 C.F.R. § 42.121
`
`
`
`
`1 Cavium, who filed a Petition in Case IPR2017-01735, has been joined as a
`
`petitioner in this proceeding.
`
`
`
`
`
`
`Alacritech Exhibit 2305
`
`
`
`
`
`1.
`
`I have been retained on behalf of Alacritech, Inc. (“Alacritech” or
`
`“Patent Owner”) in connection with the above-captioned inter partes review (IPR).
`
`I understand that on January 29, 2018, Alacritech filed its Contingent Motion to
`
`Amend (Paper 25). I further understand that on April 4, 2018, Petitioner Intel
`
`Corp. filed its Opposition to the Contingent Motion to Amend (Paper 40). I have
`
`been retained to provide my opinions in support of Alacritech’s Reply In Support
`
`of its Contingent Motion to Amend. I am being compensated for my time at the
`
`rate of $600 per hour. I have no interest in the outcome of this proceeding.
`
`2.
`
`In preparing this declaration, I have reviewed and am familiar with the
`
`Contingent Motion to Amend (“Contingent Motion”), the Opposition to the
`
`Contingent to Amend (“Opposition”), and the Institution Decision (Paper 11). I
`
`have also considered all other materials cited and discussed in the Contingent
`
`Motion, Opposition, and Institution Decision, including the declarations of Dr.
`
`Robert Horst, the Erickson reference (Ex. 1005), the Tanenbaum reference (Ex.
`
`1006), the Alteon reference (Ex. 1033), and the Institution Decision (Paper 11).
`
`Moreover, I have reviewed the Institution Decision and the materials cited therein.
`
`3.
`
`The statements made herein are based on my own knowledge and
`
`opinion. This Declaration represents only the opinions I have formed to date. I
`
`may consider additional documents as they become available or other documents
`
`
`
`
`Alacritech Exhibit 2305, Page 1
`
`
`
`
`
`that are necessary to form my opinions. I reserve the right to revise, supplement,
`
`or amend my opinions based on new information and on my continuing analysis.
`
`II. QUALIFICATIONS
`
`4. My Qualifications are listed in my Declaration in Support of
`
`Alacritech’s Response. See Ex. 2026 at ¶¶ 6-29; see also Ex. 2027.
`
`III. LEGAL UNDERSTANDING
`
`A. The Person of Ordinary Skill in the Art
`
`5. My understanding and opinions regarding the level of ordinary skill in
`
`the art are set forth in my Declaration in Support of Alacritech’s Response. See
`
`Ex. 2026 at ¶¶ 30-35.
`
`6.
`
`In my opinion, a POSITA at that time would be a person with a
`
`Bachelor's degree in Computer Science, Computer Engineering, or the equivalent,
`
`and several years’ experience in the fields of computer networking and/or
`
`networking protocols.
`
`B.
`
`7.
`
`Legal Principles
`
`I am not a lawyer and will not provide any legal opinions. Though I
`
`am not a lawyer, I have been advised that certain legal standards are to be applied
`
`by technical experts in forming opinions regarding the meaning and validity of
`
`patent claims.
`
`8.
`
`I understand that a patent claim is invalid if the claimed invention
`
`would have been obvious to a person of ordinary skill in the field at the time the
`
`
`
`
`Alacritech Exhibit 2305, Page 2
`
`
`
`
`
`application was filed. This means that even if all of the requirements of the claim
`
`cannot be found in a single prior art reference that would anticipate the claim, the
`
`claim can still be invalid.
`
`9.
`
`To obtain a patent, a claimed invention must have, as of the priority
`
`date, been nonobvious in view of the prior art in the field. I understand that an
`
`invention is obvious when the differences between the subject matter sought to be
`
`patented and the prior art are such that the subject matter as a whole would have
`
`been obvious at the time the invention was made to a person having ordinary skill
`
`in the art.
`
`10.
`
`I understand that to prove that prior art, or a combination of prior art,
`
`renders a patent obvious, it is necessary to: (1) identify the particular references
`
`that singly, or in combination, make the patent obvious; (2) specifically identify
`
`which elements of the patent claim appear in each of the asserted references; and
`
`(3) explain how the prior art references could have been combined to create the
`
`inventions claimed in the asserted claim.
`
`11.
`
`I understand that in evaluating the validity of the ’241 Patent claims,
`
`the content of a patent or printed publication prior art should be interpreted the way
`
`a person of ordinary skill in the art would have interpreted the prior art as of the
`
`effective filing date (October 1997) of the challenged patent. My full analysis
`
`below is based upon these understandings.
`
`
`
`
`Alacritech Exhibit 2305, Page 3
`
`
`
`
`
`12.
`
`I have been instructed by counsel on the law regarding claim
`
`construction and patent claims, and understand that a patent may include two types
`
`of claims––independent claims and dependent claims. An independent claim
`
`stands alone and includes only the features it recites. A dependent claim can
`
`depend from an independent claim or another dependent claim. I understand that a
`
`dependent claim includes all the features that it recites in addition to all the
`
`features recited in the claim from which it depends.
`
`13.
`
`I understand that in this inter partes review the claims must be given
`
`their broadest reasonable interpretation, but that interpretation must be consistent
`
`with the patent specification.
`
`14.
`
`It is my understanding that a patent must contain a written description
`
`of the claimed invention. The written description must clearly convey to those
`
`skilled in the art that, as of the filing date sought, the applicant was in possession
`
`of the invention claimed.
`
`IV. THE SUBSTITUTE CLAIMS
`
`15.
`
`I understand that Patent Owner has proposed substitute claims 25-48.
`
`I further understand that the substitute claims are reproduced in Appendix A and B
`
`of the Contingent Motion to Amend.
`
`16.
`
`I understand that substitute independent claim 25 (and dependent
`
`claims 26-32) correspond to original independent claim 1 (and dependent claims 1-
`
`
`
`
`Alacritech Exhibit 2305, Page 4
`
`
`
`
`
`8). I also understand that substitute independent claims 33 and 41 (and dependent
`
`claims 34-40 and 42-48) correspond to original independent claims 9 and 17 (and
`
`dependent claims 10-16 and 18-24).
`
`17.
`
`I understand that Patent Owner has proposed a single amendment in
`
`substitute claims 25-32:
`
`sending by the first mechanism, the data from each
`
`packet of the first type to a destination in memory
`
`allocated to an application running on a host computer
`
`without sending any of the media access control layer
`
`headers, network layer headers, or transport layer headers
`
`to the destination or to a host protocol stack running on
`
`the host computer.
`
`Contingent Motion, Appendix A at i-iii.
`
`18.
`
`I understand that for Patent Owner has proposed a single amendment
`
`for substitute claims 33-48 as well:
`
`Transmitting the packets to the network, wherein the
`
`dividing, prepending, and transmitting occur without the
`
`second processor generating an interrupt to the first
`
`processor.
`
`Contingent Motion, Appendix A at iii-vii.
`
`
`
`
`Alacritech Exhibit 2305, Page 5
`
`
`
`
`
`V. A PERSON OF SKILL IN THE ART WOULD UNDERSTAND THAT
`THE SUBSTITUTE CLAIMS ARE SUPPORTED BY THE ‘878
`APPLICATION AND THE ‘809 PROVISIONAL APPLICATION
`
`19.
`
`In my opinion, the ’878 Application and ’809 Provisional Application
`
`provide adequate written description support for the substitute claims.
`
`A.
`
`20.
`
`Substitute Claims 25-32
`
`I have reviewed the ’878 Application and its is my opinion that it
`
`supports substitute claims 25-32. For example, the embodiments illustrated in
`
`Figures 3 and 4 and described at paragraphs 55 to 64 of the ’878 Application
`
`provide written description support for the substitute claims. Id. These disclosures
`
`teach a first mechanism (e.g., a CPD 30) sends “application data” from each packet
`
`of a first type (e.g., those where a hash and a CCB are matched) to a destination in
`
`memory allocated to an application running on a host computer (e.g., storage 35 on
`
`the host where the “application data” is stored), without sending header
`
`information to the destination or to a host protocol stack running on the host
`
`computer (e.g., a protocol stack housed in storage 35). Ex. 2021 at Abstract,
`
`[0055]-[0064], Figs. 3-4.
`
`21. Figures 4A-4D describe the ways packets that are received from a
`
`remote host 22 via network 25 may be handled. Id. at Fig. 4A-4D; [0059]-[0064].
`
`Figure 4C (reproduced below) depicts the scenario where packets received at the
`
`communication processed device (“CPD”) 30 are from the “same connection as the
`
`initial packet”:
`
`
`
`Alacritech Exhibit 2305, Page 6
`
`
`
`
`
`
`
`Id. at [0061]; Fig. 4C. In this scenario, “the packet headers and data are validated
`
`by the receive logic 32.” Id. The “headers are parsed to create a summary of the
`
`message packet and a hash for finding a corresponding CCB,” and the summary
`
`and hash are “stored in memory 60 along with the packet.” Id. The processor on
`
`the receive logic 32 then “checks for a match between the hash and each CCB that
`
`is stored in cache 62 and, finding a match, send the data (D2) 70 via a fast-path
`
`directly to the destination in storage 35, as shown by arrow 72.” Id. The data (D2)
`
`bypasses the host protocol stack 44 and is sent to the destination in memory
`
`allocated to an application running on a host computer (storage 35) without any of
`
`the media access control layer headers, network layer headers, or transport layer
`
`headers. Id.; see also [0051]; Fig. 4C.
`
`22. Figure 3 and its corresponding written disclosures also support
`
`substitute claims 25-32. For example, these disclosures explain that packets that
`
`“match a CCB held by the CPD” are sent via a fast-path where “[u]pon confirming
`
`such a match, the CPD removes lower layer headers and sends [in step] 69 [of
`
`
`
`
`Alacritech Exhibit 2305, Page 7
`
`
`
`
`
`Figure 3] the remaining application data from the frame directly into its final
`
`destination in the host.” Id. at [0057] (emphasis added); Fig. 3. These
`
`embodiments and disclosures are examples of the more than adequate written
`
`description support for the substitute claims that exist in the ’878 Application. See
`
`also, e.g., id. at Abstract (“INIC to move data, free of headers, directly to or from a
`
`destination or source in the host.”); [0017] (“this fast-path bypasses conventional
`
`protocol processing of headers that accompany the data”).
`
`23.
`
`I have also reviewed the ’809 Provisional Application, and it is my
`
`opinion that the substitute claims are supported by the ’809 Provisional
`
`Application. For example, Section 2.1 teaches that “[i]n order to keep the system
`
`CPU from having to process the packet header or checksum the packet, we must
`
`perform [transport level processing] on the INIC.” Ex. 2019 at 138. The ’809
`
`Provisional Application goes on to describe how to implement a “fast-path” and a
`
`“slow-path,” wherein “[i]n the fast path case, network data is given to the host after
`
`the headers have been processed and stripped.” Id. at 140 (emphasis added). This
`
`disclosure provides clear support for substitute claims 25-32.
`
`B.
`
`24.
`
`Substitute Claims 33-48
`
`I have reviewed the ’878 Application and it is my opinion that it
`
`supports substitute claims 33-48.
`
`
`
`
`Alacritech Exhibit 2305, Page 8
`
`
`
`
`
`25. An interrupt is a signal to the processor emitted by hardware or
`
`software indicating an event that needs immediate attention. One popular textbook
`
`I am familiar with, Linux Device Drivers by A. Rubini and J. Corbert, was
`
`published in June 2001 and explains “[a]n interrupt is simply a signal that the
`
`hardware can send when it wants the processor’s attention.” Ex. 2004 at 258. The
`
`purpose of the interrupt is to “let the processor know when something has
`
`happened.” Id. While computers attempt to run multiple processes simultaneously,
`
`a single processor can operate on only one task at a time. Interrupts are used to
`
`inform the processor as to which tasks are ready for work to be done by the
`
`processor. Because the processing of each layer typically involves a copy and data
`
`manipulation operation (for example a checksum computation operation), the host
`
`CPU must be “interrupted” at least one time per layer in order to process the data
`
`and construct (transmit side) or deconstruct (receive side) the packet.
`
`26. The ’878 Application teaches how the fast-path transmit procedures of
`
`the inventions “relieve[] the host CPU of per-frame processing,” such that “an
`
`interrupt only occurs (at the most) at the beginning and end of an entire upper-layer
`
`message transaction, and there are no interrupts for sending or receiving of each
`
`lower layer portions or packet of that transaction.” See, e.g., Ex. 2021 at [0063]-
`
`[0064]. These disclosures teach those of skill in the art solutions that allow an
`
`INIC to acquire “network-sized portions of the message” data, perform “processor
`
`
`
`
`Alacritech Exhibit 2305, Page 9
`
`
`
`
`
`division of the data into packet and addition of full headers for network
`
`transmission” in order to “minimiz[e] CPU processing and interrupts.” Id. at
`
`[0077]-[0080]; see also id. [0075] (“When INIC microcode comparator circuits
`
`detect a match with the CCB, a DMA controller places the data from the packet in
`
`the destination 168, without any interrupt by the CPU, protocol processing or
`
`copying.”), [0160]-[0165]. In addition to these disclosures, the ’878 Application
`
`walks through specific examples and the interrupts that would issue with the
`
`present invention. Id. at [0221]-[0223], [0229]-[0231]. Just as with claims 25-32,
`
`these disclosure provide clear support for substitute claims 33-48.
`
`27.
`
`I have also reviewed the ’809 Provisional Application, and it is my
`
`opinion that the substitute claims are supported by the ’809 Provisional
`
`Application. For example, the ’809 Provisional Application identifies the reasons
`
`that prior art systems have “too many interrupts.” Ex. 2019 at 2-3. It continues by
`
`providing a “Summary of the Invention” explaining that its invention reduces the
`
`number of interrupts and that “[t]he remainder of this document [] describe[s] how
`
`we accomplish” the reduction in interrupts. Id. at 7. For example, Sections 2 and
`
`5 of the ’809 Provisional Application provides a detailed disclosure of the transmit
`
`processing, including the “affect on interrupts” of these techniques. Id. at 60-62
`
`(describing “transmit processing,” including “main loop,” “transmit events,” and
`
`
`
`
`Alacritech Exhibit 2305, Page 10
`
`
`
`
`
`“transmit details”), 12-13 (explaining that in the transmit direction, “we actually
`
`only receive a single interrupt” after the transmit step completes).
`
`28.
`
`I have reviewed the argument in Petitioner’s Response (Opp. at 5) that
`
`the example given in Section 2.4.3 does not support the substitute claims. I
`
`disagree. The example given in Section 2.4.3 the Provisional Application actually
`
`fully supports substitute claims 33-48. A “[f]ast-path 400 byte send” using the
`
`INIC is completed “in one interrupt”
`
`
`
`Ex. 2019.016. Petitioner’s argument regarding a lack of disclosure about “when
`
`the interrupt occurs” is mistaken because this is made clear in another portion of
`
`the disclosure: “[o]n transmit, we actually only receive a single interrupt when the
`
`send command that has been given to the INIC completes.” Ex. 2019. 013. Thus,
`
`one skilled in the art would understand that the single interrupt does not occur
`Alacritech Exhibit 2305, Page 11
`
`
`
`
`
`
`
`
`during the dividing, prepending, or transmitting steps, but rather after these steps
`
`are completed. It is clear, therefore, that the ’809 provisional application provides
`
`adequate written description and enablement support for sending multiple packets
`
`of data on the fast-path without an interrupt generated during ‘the dividing,
`
`prepending, and transmitting’ steps. This is because only a single interrupt is
`
`generated, after the entire send process has completed.
`
`VI. A PERSON OF SKILL IN THE ART WOULD UNDERSTAND THAT
`THE SUBSTITUTE CLAIMS ARE NOT ANTICIPATED OR
`OBVIOUS
`
`29.
`
`In my opinion, the substitute claims are not anticipated or obvious by
`
`the prior art. Indeed, in my opinion the substitute claims further distinguish the
`
`claims from the Erickson, Tanenbaum, and Alteon prior art that the Petitioner is
`
`relying upon. It is my opinion that none of these references, alone or in
`
`combination, teaches the proposed amendments.
`
`A.
`
`30.
`
`Substitute Claims 25-32
`
`I understand Claim 25 has been amended to clarify that the data from
`
`each packet of the first type is sent to “a destination in memory allocated to an
`
`application running on a host computer without sending any of the media access
`
`control layer headers, network layer headers, or transport layer headers to the
`
`destination or to a host protocol stack running on the host computer.” It is my
`
`opinion that the proposed amendments further distinguish Erickson, Tanenbaum,
`
`
`
`
`Alacritech Exhibit 2305, Page 12
`
`
`
`
`
`and Alteon, and these references fail to disclose the limitations of the substitute
`
`claims, either alone or in combination.
`
`31.
`
`I understand that the substitute claims have now been amended to
`
`expressly clarify that the headers cannot be sent to a “host protocol stack running
`
`on the host computer.” Alteon describes the opposite of this amendment because it
`
`states that the “first 64 bytes of the packet,” which “includes the header
`
`information” is sent to the “protocol stack” on the host:
`
`
`
`Ex. 1033 at 21 (yellow highlights and red annotation added); see also id. at 20
`
`(“protocol stack entity on the host”). One skilled in the art would understand that
`
`the first 64 bytes of a packet would at least include the media access control layer
`
`header.
`
`32. Petitioner’s Opposition does not explain how Erickson would be
`
`modified in view of the cited disclosures in Tanenbaum, and, in my opinion, one
`
`skilled in the art would not do so. A review of Tanenbaum confirms its disclosures
`
`
`
`
`Alacritech Exhibit 2305, Page 13
`
`
`
`
`
`do not teach or suggest the proposed amendment, either alone or in combination
`
`with other references. Tanenbaum does not teach or suggest that the MAC layer
`
`headers, network layer headers, and transport layer headers should not be sent to
`
`the destination or to a host protocol stack running on the host computer. To the
`
`contrary, Tanenbaum states that all TCP/IP protocol processing should be done by
`
`the host CPU:
`
`A tempting way to go fast is to build fast network
`
`interfaces in hardware. The difficulty with this strategy is
`
`. . . hardware just means a plug-in board with a second
`
`CPU . . . . The consequence of this design is that much of
`
`the time the main (fast) CPU is idle waiting for the
`
`second (slow) CPU to do the critical work. . . .
`
`Furthermore . . . race conditions can occur, so elaborate
`
`protocols are needed between the two processors . . . .
`
`Usually, the best approach is to make the protocols
`
`simple and have the main CPU do the work.
`
`See Ex. 1006 at 588-589. One skilled in the art would understand Tanenbaum’s
`
`recommendation to “have the main CPU do the work” involves the host CPU
`
`receiving the MAC layer headers, network layer headers, and transport layer
`
`headers. Tanenbaum thus discloses “traditional header processing by the host” and
`
`
`
`
`Alacritech Exhibit 2305, Page 14
`
`
`
`
`
`teaches the opposite of the substitute claims. While Petitioner cites to some
`
`alleged “[t]est to determine whether to process incoming packet on the fast path or
`
`slow path” in Tanenbaum, this “test” does not implicate any header processing by
`
`the NIC or processing any received packets “without sending any of the media
`
`access control layer headers, network layer headers, or transport layer headers to
`
`the destination or to a host protocol stack running on the host computer,” as recited
`
`by the substitute claims.
`
`33.
`
`It is my opinion that Erickson, alone or in combination with
`
`Tanenbaum and Alteon, also does not disclose or suggest this limitation. Erickson
`
`almost exclusively relates to the transmit side and does not disclose or suggest that
`
`that data from received packets are sent to a destination in memory allocated to an
`
`application running on a host computer without sending any of the media access
`
`control layer headers, network layer headers or transport layer headers to a host
`
`protocol stack running on the host computer. Indeed, Erickson’s discussion of
`
`header information is in the context of transferring data away from the destination
`
`or to a host protocol stack running on the host computer. Ex. 1005 at 6:47-50
`
`(“Fig. 6 shows the actual bytes of a sample UDP datagram 602 as it might be
`
`transmitted over an Ethernet media.”); 7:38-48 (“Fig. 7 is a block diagram
`
`illustrating a UDP datagram template . . . I/O device adapter . . . transmits the
`
`completed UDP datagram 702 over the media.”). The claims, in contrast, require
`
`
`
`
`Alacritech Exhibit 2305, Page 15
`
`
`
`
`
`data flow in the opposite direction and this distinction is not trivial, as explained
`
`below.
`
`34.
`
`In fact, Erickson teaches the opposite of the claimed invention. For
`
`example, Figure 4 of Erickson and the corresponding description of Figure 4 teach
`
`that “[t]he information coming from interconnect 410 is routed directly to a
`
`process 402 or 404.” Ex. 1005 at 5:8-11. The word “directly” indicates that the
`
`information from interconnect 410 is not processed before it is routed to process
`
`402 or 404, and is instead transferred in its entirety with the header information.
`
`Similarly, Figure 5 and its corresponding written description teaches that in
`
`Erickson “endpoint table 514 points to various protocol data 518 in the memory
`
`512 in order to accommodate multiple communication protocols . . . which indicate
`
`how data or information is to be transferred from the memory 512 of the I/O device
`
`adapter to the portion of main memory 502 associated with a user process.” Ex.
`
`1005 at 5:59-67. In other words, the “data or information” in memory 512,
`
`including the “protocol data,” is transferred to the main memory associated with
`
`the user process. One skilled in the art would understand “protocol data” includes
`
`header information. Erickson thus teaches sending header information to the
`
`destination, which is the opposite of what the substitute claims require.
`
`35. Figure 3 of Erickson and its corresponding written description also
`
`fail to mention headers and certainly do not teach how headers would be processed
`
`
`
`
`Alacritech Exhibit 2305, Page 16
`
`
`
`
`
`without sending the headers to the destination in memory allocated to an
`
`application. Additionally, the arrows in Figure 3 point from applications 302 and
`
`304 to the I/O device adapter 314, thereby making it clear that information is
`
`actually being transmitted away from the alleged destination in memory allocated
`
`to an application. The substitute claims relate to information transfer in the
`
`opposite direction (i.e., to the destination), and the difference in the direction of
`
`data flow is not trivial. Indeed, the challenges of offloading receive-side
`
`processing are different than for transmit-side processing. For example, with
`
`transmit side processing the information of the packet is largely known, so there is
`
`not the same level of uncertainty as exists in receive side coalescing.
`
`36. Erickson’s statement that “a user process can use the virtual hardware
`
`of the present invention to provide a direct streamlined path to a given I/O device
`
`adapter” (Ex. 1005 at 8:65-9:7), also does not teach or suggest the proposed
`
`amendment similarly misplaced. This disclosure again relates to data flow in the
`
`wrong direction, namely from the I/O device to the user process. And, in any
`
`event, by teaching a “direct” path to a given I/O device the cited disclosure teaches
`
`transferring entire blocks of information without any processing to remove header
`
`information.
`
`
`
`
`Alacritech Exhibit 2305, Page 17
`
`
`
`
`
`B.
`
`37.
`
`Substitute Claims 33-48
`
`I understand substitute independent claims 33 and 41 (and dependent
`
`claims 34-40 and 42-48) correspond to original independent claims 9 and 17 (and
`
`dependent claims 10-16 and 18-24). I also understand that claims 33 and 41 have
`
`been amended to clarify that the “dividing, prepending, and transmitting, occur
`
`without the second mechanism generating an interrupt to the first mechanism.”
`
`Erickson, Tanenbaum, and Alteon do not disclose the proposed amendment, either
`
`alone or in combination.
`
`38. There is no functionality within Erickson’s I/O device adapter for
`
`dividing a large block of user data into multiple segments and prepending a packet
`
`header to each of the segments. The word “interrupt” does not appear in Erickson,
`
`nor is the interrupt limitation inherent in the system of Erickson. Tanenbaum is
`
`also silent regarding interrupts.
`
`39.
`
`I also disagree with Petitioner that “all processing to generate headers
`
`for packets to be sent from the network interface device of Erickson is performed
`
`by the processing capability of Erickson’s network interface device with no reason
`
`to interrupt the processing of the host computer requesting transmission.” Opp. at
`
`16. Erickson teaches and suggests reasons why the host would need to be
`
`interrupted to perform the dividing, prepending, or transmitting steps. For
`
`example, Erickson teaches that within its “udpscript procedure” there is a “nextid()
`
`
`
`
`Alacritech Exhibit 2305, Page 18
`
`
`
`
`
`function” which “provides a monotonically increasing 16-bit counter.” Ex. 1005 at
`
`8:10-13. One skilled in the art would understand that the host processor and the
`
`network interface processor would want to maintain consistency between the
`
`count, and that to do so the network interface processer would issue interrupts to
`
`the host processor during these steps.
`
`40. Numerous interrupts would also be generated by Erickson’s system at
`
`other times. See supra ¶ 29. For example, each time a packet is transmitted, the
`
`“senduserdatagram” process must be called. Before calling this process, Erickson
`
`explains that the “user process” holds the user data of the datagram and certain
`
`pointers, memory addresses, and “virtual registers” must be set by the user process.
`
`Ex. 1005 at 7:5-18. This would require triggering multiple interrupts to the host
`
`after each packet is transmitted in order to configure the “senduserdatagram”
`
`process for the next packet. Erickson, even when combined with Tanenbaum,
`
`therefore cannot disclose that the “dividing, prepending, and transmitting, occur
`
`without the second mechanism generating an interrupt to the first mechanism”
`
`because Erickson only supports a single packet transmission at a time. This
`
`operation is in stark contract to the requirements of the substitute claims that
`
`require the creation of multiple packets for transmission by dividing a block of data
`
`into multiple segments, prepending a packet header to each of the segments, and
`
`transmitting the packets to the network, wherein the dividing, prepending, and
`
`
`
`
`Alacritech Exhibit 2305, Page 19
`
`
`
`
`
`transmitting all occur without the second processor generating an interrupt to the
`
`first processor.
`
`41. Finally, Alteon does not teach or suggest the proposed amendments,
`
`either alone, or in combination with Erickson or Tanenbaum. Alteon teaches that
`
`its “Gigabit Ethernet adapters have an interrupt timer that determines when to
`
`interrupt a host CPU” and “allows a single interrupt to be issued for multiple data
`
`packets that are sent into the operating system buffer space.” Ex. 1033 at 18-19.
`
`But sending data “into the operating system” involves a mere copy operation on
`
`the receive path and is irrelevant and a completely distinct process from the
`
`claimed dividing, prepending, and transmitting steps. Petitioner has not cited and
`
`there is no disclosure in Alteon of the dividing, prepending, and transmitting steps
`
`all being performed without the generation of an interrupt.
`
`VII. CONCLUSION
`
`42.
`
`In signing this declaration, I recognize that the declaration will be
`
`filed as evidence in a contested case before the Patent Trial and Appeal Board of
`
`the United States Patent and Trademark Office. I also recognize that I may be
`
`subject to cross-examination in the case and that cross-examination will take place
`
`within the United States. If cross-examination is required of me, I will appear for
`
`cross-examination within the United States during the time allotted for cross-
`
`examination.
`
`
`
`
`Alacritech Exhibit 2305, Page 20
`
`
`
`
`
`43.
`
`I hereby declare that all statements made herein of my own
`
`knowledge are true and that all statements made on the information and belief are
`
`believed to be true; and further that these statements were made with the
`
`knowledge that willful false statements and the like so made are punishable by fine
`
`or imprisonment, or both, under Section 1001 of Title 18 of the United States
`
`Code.
`
`
`
`Executed: May 18, 2018
`
`
`
`
`
`Kevin C. Almeroth, Ph.D.
`
`
`
`
`
`
`Alacritech Exhibit 2305, Page 21
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
