`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________________
`
`BROADCOM CORPORATION
`Petitioner
`
`v.
`
`TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
`Patent Owner
`____________________
`
`Case IPR2013-00636
`Patent 6,424,625
`Title: Method and Apparatus For Discarding Packets In A Data Network Having
`Automatic Repeat Request
`____________________
`
`DECLARATION OF ROBERT AKL, D.Sc.,
`IN SUPPORT OF PATENT OWNER’S RESPONSE
`
`
`
`
`
`TABLE OF CONTENTS
`
`Case IPR2013-00636
`
`
`
`INTRODUCTION .................................................................................................... 4
`QUALIFICATIONS AND COMPENSATION .................................................... 5
`MATERIALS CONSIDERED ................................................................................ 7
`THE LEVEL OF ORDINARY SKILL IN THE ART ......................................... 8
`OPINIONS ................................................................................................................ 9
`A. Overview of the ’625 Patent ............................................................... 9
`B.
`Broadest Reasonable Interpretation ............................................... 12
`C. Claim 1 Is Not Anticipated by Garrabrant .................................... 14
`1.
`Garrabrant does not disclose “commanding a receiver to
`receive” ..................................................................................... 18
`Garrabrant does not disclose “commanding a receiver to
`release” ..................................................................................... 24
`Garrabrant does not disclose “discarding unacknowledged
`packets” .................................................................................... 25
`The SABM command in Garrabrant does not anticipate
`claim 1 of the ’625 patent ....................................................... 27
`D. Claim 1 Is Not Anticipated By Hettich ............................................ 30
`1.
`The Hettich Delay PDU commands a receiver to ignore, and
`not receive cells ........................................................................ 32
`The Hettich Delay PDU does not command a receiver to
`release expectations of receiving outstanding packets ........ 33
`The transmitter in Hettich does not “discard all packets” . 36
`3.
`Claim 1 Is Not Rendered Obvious By Walke ................................. 40
`
`E.
`
`2
`
`2.
`
`3.
`
`4.
`
`2.
`
`
`
`Case IPR2013-00636
`
`
`
`1.
`
`2.
`
`The delay command in Walke commands a receiver to
`ignore, not receive one cell ..................................................... 42
`The delay command in Walke does not command a receiver
`to release expectations of receiving outstanding packets .... 43
`3. Walke does not teach or suggest “discarding” all cells ....... 47
`CONCLUSION ....................................................................................................... 48
`ACKNOWLEDGEMENT ..................................................................................... 50
`
`3
`
`
`
`
`
`
`
`Case IPR2013-00636
`
`
`
`
`
`
`
`DECLARATION BY ROBERT AKL, D.Sc.,
`IN SUPPORT OF PATENT OWNER’S RESPONSE
`
`I, Robert Akl, D.Sc., hereby declare, affirm, and state the following:
`
`INTRODUCTION
`The facts set forth below are known to me personally and I have
`
`1.
`
`firsthand knowledge of them. I am a U.S. citizen over eighteen years of age. I am
`
`fully competent to testify as to the matters addressed in this Declaration. I
`
`understand that this Declaration is being submitted along with Patent Owner’s
`
`response to the March 10, 2014 institution of Inter Partes Review of US Patent No.
`
`6,442,625 (hereinafter, “the ’625 Patent”) by the United States Patent and
`
`Trademark Office (“USPTO”) in IPR No. 2013-00636.
`
`2.
`
`I was asked to give my opinion on whether claim 1 of the ‘625 Patent
`
`is anticipated Garrabrant and Hettich and rendered obvious by Walke. As
`
`described further below, it is my opinion neither Garrabrant nor Hettich anticipates
`
`claim 1, nor does Walke render claim 1 obvious. In particular, each of the
`
`Garrabrant, Hettich, and Walke fail to teach or suggest (1) “commanding a receiver
`
`in the data network to a) receive at least one packet having a sequence number that
`
`is not consecutive with a sequence number of a previously received packet,” (2)
`
`“commanding a receiver . . . to . . . release any expectation of receiving outstanding
`
`packets having sequence numbers prior to the at least one packet,” and (3) “the
`
`4
`
`
`
`Case IPR2013-00636
`
`
`
`transmitter discarding all packets for which acknowledgement has not been
`
`received, and which have sequence numbers prior to the at least one packet” as
`
`recited by claim 1.
`
`
`
`QUALIFICATIONS AND COMPENSATION
`
`3. My resume, including my qualifications, a list of the publications that
`
`I have authored during my technical career, and a list of the cases in which, during
`
`the previous four years, I have testified as an expert at trial or by deposition, is
`
`attached to this declaration as Attachment A.
`
`4.
`
`I have summarized in this section my educational background, career
`
`history, and other relevant qualifications. A true and accurate copy of my
`
`curriculum vitae is attached hereto as Attachment A.
`
`5.
`
`I earned my Bachelor of Science degrees in Electrical Engineering
`
`and Computer Science summa cum laude with a ranking of first in my
`
`undergraduate class from Washington University in Saint Louis in 1994. In 1996 I
`
`earned my Master of Science degree in Electrical Engineering from Washington
`
`University in Saint Louis. I earned my Doctorate of Science in Electrical
`
`Engineering from Washington University in Saint Louis in 2000, with my
`
`dissertation on “Cell Design to Maximize Capacity in Cellular Code Division
`
`Multiple Access (CDMA) Networks.”
`
`5
`
`
`
`Case IPR2013-00636
`
`
`
`6.
`
`After obtaining my Doctorate of Science degree, I worked as a Senior
`
`Systems Engineer at Comspace Corporation from October of 2000 to December of
`
`2001. In this position, I designed, coded in MATLAB, and simulated Viterbi
`
`decoding, Turbo coding, trellis coded modulation (TCM), and Reed-Muller codes.
`
`This work further entailed the optimization of soft decision parameters and
`
`interleavers for additive white Gaussian and Rayleigh faded channels.
`
`7.
`
`In January of 2002, I joined the faculty of the University of New
`
`Orleans in Louisiana as an Assistant Professor in the Department of Electrical
`
`Engineering. While on this faculty, I designed and taught two new courses called
`
`“Computer Systems Design I and II.” I also developed a Computer Engineering
`
`Curriculum with strong hardware-design emphasis, formed a wireless research
`
`group, and advised graduate and undergraduate students.
`
`8.
`
`In September of 2002, I received an appointment as an Assistant
`
`Professor in the Department of Computer Science and Engineering at the
`
`University of North Texas, in Denton, Texas. In May of 2008, I became a tenured
`
`Associate Professor in the Department of Computer Science and Engineering,
`
`where I continue to focus my research on wireless communication, including 4G,
`
`LTE, and wireless sensor networks. I also teach communications systems and
`
`wireless communication courses.
`
`6
`
`
`
`Case IPR2013-00636
`
`
`
`9.
`
`I have authored and co-authored approximately 65
`
`journal
`
`publications, conference proceedings, technical articles, technical papers, book
`
`chapters, and technical presentations, in a broad array of communications-related
`
`technology, including networking and wireless communication. I have also
`
`developed and taught over 70 courses related to communications and computer
`
`system designs, including a number of courses on wireless communication,
`
`communications systems, computer systems design, and computer architecture.
`
`These courses have included introductory courses on communication systems and
`
`sensor networks, as well as more advanced courses on wireless communications.
`
`A complete list of my publications and the courses I have developed and/or taught
`
`is also contained in my curriculum vitae.
`
`10.
`
`I hereby incorporate into this declaration the entire contents of my
`
`curriculum vitae, attached as Attachment A to this declaration.
`
`11.
`
`I am being compensated at the rate of $550 per hour for my work in
`
`connection with this matter. My compensation is not dependent in any way on the
`
`contents of this Declaration, the substance of any further opinions or testimony that
`
`I may provide, or the ultimate outcome of this matter.
`
`MATERIALS CONSIDERED
`In forming the opinions expressed herein, I have reviewed and
`
`12.
`
`considered the following materials:
`
`7
`
`
`
`Case IPR2013-00636
`
`
`
`
`
`
`
`
`
`A. Petition for Inter Partes Review of U.S. Patent No. 6,424,625 Under 35
`U.S.C. §312 and 37 C.F.R. §§42.104 (Paper No. 3) (“Petition”);
`
`B. U.S. Patent No. 6,424,625 (Petitioner’s Exhibit No. 1001) and its file
`history;
`
`C. U.S. Patent No. 5,610,595 to Gary W. Garrabrant, Jay C. Cho, and Joseph T.
`Savarese (Petitioner’s Exhibit No. 1002) (“Garrabrant”);
`
`D. Certified Translation of Andreas Hettich, Development and performance
`evaluation of a Selective Repeat-Automatic Repeata Request (SR-ARQ)
`protocol for transparent, mobile ATM Access (Petitioner’s Exhibit No.
`1007) (“Hettich”);
`
`E. Certified Translation of Walke German Patent DE 19543280 (“Walke”)
`(Exhibit No. 1008);
`
`F. Declaration of Harry Bims, Ph.D. (Petitioner’s Exhibit No. 1006) (“Bims
`Dec.”) and exhibits cited to therein;
`
`G. Rebuttal Expert Report of Scott Nettles, Ph.D. Regarding Validity of U.S.
`Patent Nos., 6,424,625; 6,330,435; 6,519,223; 6,772,215; 6,466,568; and
`6,987,019 (Petitioner’s Exhibit No. 1010); and
`
`H. Decision: Institution of Inter Partes Review—37 C.F.R. §42.108 (IPR2013
`00636, Paper No. 25).
`
`
`THE LEVEL OF ORDINARY SKILL IN THE ART
`
`13.
`
`It is my opinion, based upon a review of the file history of the ’625
`
`Patent and the other evidence addressed herein, that a person of ordinary skill in
`
`the art as of the ’625 Patent would have had, as of October 1998, a bachelor’s
`
`degree in computer science or a similar technical field and at least two years of
`
`experience in telecommunications and network protocols.
`
`8
`
`
`
`Case IPR2013-00636
`
`
`
`OPINIONS
`A. Overview of the ’625 Patent
`14. The ’625 patent “relates to Automatic Repeat Request (ARQ)
`
`techniques for transferring data in fixed/wireless data networks.” ’625 pat. at 1:7-
`
`10. ARQ techniques are “used to ensure reliable data transfer and protect data
`
`sequence integrity.” Id. at 1:13-15. Detecting data sequence integrity allows the
`
`receiver to request retransmission of data packets that have been lost or corrupted.
`
`Id. at 15-20. Data integrity is commonly enforced by applying transmission rules
`
`to sequentially numbered data packets. Id. at 1:20-22.
`
`15. There are three main ARQ protocols for providing transmission rules
`
`for transferring packets to a receiver in a particular order: Stop-and-Wait, Go-
`
`Back-N, and Selective Reject (or Selective Repeat). Id. at 1:23-25. Generally,
`
`“Selective Reject is most efficient, Stop-and-Wait is least efficient, and Go-Back-
`
`N is intermediate.” Id. at 1:28-30. Packets received in the correct order are
`
`forwarded to the next higher layer. Id. at 2:66-67. However, processing is halted
`
`for packets arriving out of order or are not correctly received until the lost or
`
`erroneous packets are received. Id. at 2:3-27, 2:66-3:10.
`
`16. Normally, “it is desirable to transfer all packets without any packet
`
`loss.” Id. at 3:46-47. But in certain applications, stale or delayed (outdated) data
`
`may be useless to the receiver. Id. at 3:47-51. Delay-sensitive applications include
`
`9
`
`
`
`Case IPR2013-00636
`
`
`
`“telephony, video conferencing and delay sensitive control systems.” Id. at 51-53.
`
`In situations where data packets have a limited lifetime, bandwidth usage can be
`
`enhanced by “not sending (or resending) significantly delayed or outdated data
`
`packets.” Id. at 4:9-13.
`
`17. The ’625 patent discloses and claims ARQ techniques that “minimize
`
`bandwidth usage by accounting for data packets that have an arbitrary but limited
`
`lifetime.” Id. at 4:16-19. Go-Back-N and Selective Reject embodiments that
`
`“discard outdated data packets” are disclosed in the ’625 patent. Id. at 22-25. In
`
`particular, the ’625 patent allows receivers to skip or overlook discarded packets
`
`(e.g., release any expectation of receiving discarded packets). Id. at 5:18-25.
`
`Thus, the ’625 patent discards packets that are outdated, and also informs a
`
`receiver that it should not expect to receive those discarded packets. Id. at 5:15-27.
`
`18.
`
`In one embodiment, a transmitter that discards a packet, “orders a
`
`receiver to accept the next packet, by setting a certain Receiver Packet
`
`Enforcement Bit (RPEB) in the ARQ header of the next packet and sending the
`
`packet to the receiver.” Id. at 5:28-32. The RPEB bit forces the receiver to accept
`
`the received packet. Id. at 5:32-33. The preferred embodiment of an ARQ packet
`
`is illustrated in Fig. 8 of the ’625 patent:
`
`10
`
`
`
`Case IPR2013-00636
`
`
`
`
`19. Here the ARQ packet 810 includes an ARQ header 812 and a data
`
`portion 818. Id. at 5:33-35. “The header 812 includes a receive packet
`
`enforcement bit RPEB 814, and a k-bit sequence number N(S) 816.” Id. at 5:35-
`
`37. The ARQ packet 810 can be used under various conditions. First, if a NACK
`
`is sent by an ARQ receiver and is properly received by an ARQ transmitter, and
`
`further if “the NACK is valid for one discarded data packet, then the next data
`
`packet to be retransmitted can have an RPEB set to TRUE.” Id. at 5:43-48.
`
`Alternatively, if a retransmission timer expires for one or more data packets
`
`causing those data packets to be discarded, the “next incoming data packet to be
`
`transmitted, or the first data packet to be retransmitted, can have an RPEB set to
`
`TRUE.” Id. at 5:49-54. In any event, “[w]hen a correct packet with RPEB=TRUE
`
`is received, then all packets preceding this packet and up to the next outstanding
`
`packet will be released from the buffer and forwarded to the next higher layer.” Id.
`
`11
`
`
`
`Case IPR2013-00636
`
`
`
`at 9:1-4.
`
`B. Broadest Reasonable Interpretation
`20.
`I understand that during inter partes review claims are given their
`
`broadest reasonable interpretation in view of the specification of which they are
`
`part. I further understand that a construction that is inconsistent with the
`
`specification is unreasonable and should be rejected.
`
`21. Claim 1 reads as follows:
`
`A method for discarding packets in a data network
`employing a packet transfer protocol including an automatic
`repeat request scheme, comprising the steps of:
`a transmitter in the data network commanding a receiver
`in the data network to
` a) receive at least one packet having a sequence
`number that is not consecutive with a sequence number of a
`previously received packet and
` b) release any expectation of receiving outstanding
`packets having sequence numbers prior to the at least one
`packet; and
`for which
`the
`transmitter discarding all packets
`acknowledgment has not been received, and which have
`sequence numbers prior to the at least one packet.
`22. Broadcom proposes, and the Board agreed, that the “broadest
`
`reasonable construction” of “commanding” is “an instruction represented in a
`
`12
`
`
`
`Case IPR2013-00636
`
`
`
`control field to cause an addressed device to execute a specific control function.”
`
`Pet. at 18-19. In my opinion, this construction does not represent the broadest
`
`reasonable construction. Id. at 19, n.3 (citing IEEE Dictionary).
`
`23.
`
`In my opinion, the broadest reasonable construction of the term
`
`“commanding” requires the commander (i.e., the “transmitter”) to “exercise a
`
`dominating influence over: have command of” or be able “to direct authoritatively:
`
`order.” (Ex. 2021 (Merriam-Webster Dictionary) definition of “command”). The
`
`’625 patent supports such a plain reading of this common term. In certain
`
`circumstances, the transmitter is able to force the receiver to accept any packet.
`
`’625 Patent at 4:40-42 (“transmitter resynchronizes the receiver to accept an
`
`arbitrarily chosen sequence number”); 9:43-44. “Thus, the receiver can be
`
`commanded to skip or overlook” certain packets. Id. at 5:22-25. In the preferred
`
`embodiment, the transmitter “orders the receiver to accept the next packet” by
`
`setting an “Enforcement Bit” in the arbitrarily chosen sequence number packet. Id.
`
`at 5:28-32 (emphasis added). The receiver in the ’625 Patent does not have
`
`discretion about whether to accept or reject the packet—it must accept it. In other
`
`words, the transmitter “exercises a dominating influence over: has command of”
`
`the receiver. Therefore, the broadest reasonable construction of commanding is
`
`“exercising a dominating influence” over the receiver.
`
`24.
`
`In my opinion, Broadcom’s proposed construction for this term
`
`13
`
`
`
`Case IPR2013-00636
`
`
`
`improperly imports limitations from the specification into the construction of this
`
`term. In a preferred embodiment, the ’625 patent discloses setting a bit in the
`
`header (a control field) to command a receiver to accept an out-of-order packet. Id.
`
`at 5:28-33 (“where the transmitter discards a packet, it orders the receiver to accept
`
`the next packet, by setting a certain Receiver Packet Enforcement Bit (RPEB) in
`
`the ARQ header of the next packet and sending the packet to the receiver”). There
`
`is nothing in the patent or its file history, however, that would lead me to conclude
`
`that the invention is limited to the preferred embodiment. For that reason, I
`
`disagree
`
`that
`
`the broadest reasonable
`
`interpretation
`
`includes
`
`the phrase
`
`“represented in a control field.”
`
`C. Claim 1 Is Not Anticipated by Garrabrant
`
`25. Broadcom cannot show that Garrabrant anticipates claim 1 of the ’625
`
`patent because Garrabrant does not teach or suggest: (1) “commanding a receiver
`
`in the data network to a) receive at least one packet”; (2) “commanding a receiver .
`
`. . to . . . b) release any expectation of receiving outstanding packets having
`
`sequence numbers prior to the at least one packet”; and (3) “the transmitter
`
`discarding all packets for which acknowledgement has not been received, and
`
`which have sequence numbers prior to the at least one packet” as recited by claim
`
`1.
`
`26. Garrabrant discloses a radio packet communication system for
`
`14
`
`
`
`Case IPR2013-00636
`
`
`
`wireless communication between a mobile bar code reader and a computer base
`
`station. Garrabrant, 1:21-2:39. Because the mobile bar code reader may be
`
`located outside the range of the base station, the disclosed system includes one or
`
`more repeaters placed between the bar code reader and base station to retransmit
`
`information to the destination. Id. at 2:30-32. By creating a transmission path
`
`between the source and destination, the repeaters increase the communication
`
`range of the bar code reader. Id. at 2:34-37.
`
`27. One problem stemming from the inclusion of repeaters is the
`
`retransmission of duplicate packets. To allow a receiver to reject the reception of
`
`duplicate packets from a destination, Garrabrant discloses a variation of the packet
`
`structure of the X.25 standard (reproduced below):
`
`
`
`Id. at Fig. 4; 6:50-60.
`
`28. Garrabrant proposes two additional fields to this packet structure:
`
`“sequence number field 92 and the 3-bit repeat count field 96.” Id. at 6:58-60.
`
`The sequence number field “records the sequence in which the source of the
`
`message represented by the frame 92 [sic:90] is originally produced” while the
`
`repeat count field “represents the number of remaining times which the message
`
`15
`
`
`
`Case IPR2013-00636
`
`
`
`represented by frame 94 [sic:90] will be repeated before being discarded.” Id. at
`
`6:60-66. A message is transmitted as a frame or a packet in Garrabrant. Id. at
`
`2:13-17. The use of a repeat count field prevents the same frame from being
`
`forwarded in an endless loop “forever.” Id. at 7:1.
`
`29. The transmitter and receiver use the sequence numbers of the packets
`
`to maintain synchronization. The receiver maintains a list of the sequence numbers
`
`that it can receive (“valid window”) and those that it cannot receive (“reject
`
`window”). Packets arriving at the receiver with sequence numbers corresponding
`
`to numbers in the “valid window” are received, whereas those with numbers in the
`
`“reject window” are rejected. Id. at 9:27-31. As shown in the ranges in Fig. 7
`
`(below), a sequence number is included in either the valid window or the rejection
`
`window:
`
`16
`
`
`
`Case IPR2013-00636
`
`
`
`
`
`30. The lower limit of the valid window represents “the sequence number
`
`of the next expected message.” Id. at 9:49-51. Each time a receiver receives a
`
`packet having a sequence number within the valid window, it shifts the lower end
`
`of its valid window to the next sequence number beyond the sequence number of
`
`the received packet. Because the receiver rejects packets (i.e., frames) with a
`
`sequence number outside the “valid window” and falling within the “rejection
`
`window,” the receiver should not receive multiple copies of the same packet.1
`
`31.
`
`In Fig 7A (above), the sequence number of the first entry in the valid
`
`window (the next expected message) is 0. Upon receipt of that packet, as shown in
`
`
`1 The receiver could receive a duplicate packet if such a packet is retransmitted and
`received after the valid window of the receiver has shifted to include the sequence
`number of the duplicate packet.
`
`17
`
`
`
`Case IPR2013-00636
`
`
`
`Fig. 7B, the receiver moves its valid window by one more than the received
`
`sequence number (i.e., 0+1=1). Id. at 9:51-55. If a duplicate of the same packet
`
`(i.e., a packet with sequence number=0) is later received from another repeater
`
`when the reject window of the receiver includes sequence number 0, the packet
`
`will be rejected because its sequence number “is no longer valid,” i.e., it falls
`
`within the “rejection window.” Id. at 9:54-58; see also 12:2-4, 9:5-8, 11:33-35, 56-
`
`57, 14:7-10, 13:55-58.
`
`1. Garrabrant does not disclose “commanding a receiver to
`receive”
`
`32. The receiver in Garrabrant receives and processes every packet in the
`
`same way. The receiver accepts a packet whose sequence number falls within the
`
`valid window and rejects a packet whose sequence number falls within the reject
`
`window. Garrabrant at 9:28-32. The acceptance or rejection of a packet is
`
`determined solely by the receiver maintaining (or updating) its receive and reject
`
`windows. Although Garrabrant does disclose a comprehensive set of commands
`
`and associated responses, it does not disclose a command that commands a
`
`receiver to receive a packet nor does it disclose a command a receiver to accept a
`
`packet whose sequence number falls outside its valid window.
`
`33. Contrary to Broadcom’s arguments, none of the commands disclosed
`
`in Garrabrant relate to commanding a receiver to receive a packet:
`
`18
`
`
`
`Case IPR2013-00636
`
`
`
`
`
`Id. at 6:9-32. Garrabrant explicitly states that the only “commands supported are:
`
`SABM, DISC, TEST, I, RR, and XID.” Id. at 6:47-49. Although each of the
`
`commands is included in a packet that may be received by a receiver, none of those
`
`supported commands specifically force or require a receiver to receive a packet.
`
`34. Broadcom posits that Garrabrant invalidates claim 1 for two reasons.
`
`First, Broadcom contends that the receipt of a “lost” message having a non-
`
`consecutive sequence number that falls within the valid window constitutes
`
`“commanding a receiver … to a) receive at least one packet having a sequence
`
`number that is not consecutive with a sequence number of a previously received
`
`packet.” Pet. at 30-31. But the mere reception of a “lost” message is not a
`
`command. Notably Broadcom does not identify any of Garrabrant’s commands
`
`that allegedly perform this step. Second, Broadcom contends that claim 1 is
`
`anticipated by an “SABM command.” Id. at 35-36. I disagree with Broadcom on
`
`both counts.
`
`35. Broadcom mischaracterizes
`
`the so-called “lost” message
`
`in
`
`19
`
`
`
`Case IPR2013-00636
`
`
`
`Garrabrant. A message (or a packet) can be lost in the Garrabrant system for two
`
`reasons. Either: (1) multiple messages “collided” or arrived at the destination at
`
`the same time; or (2) the mobile bar code reader or destination unit moved out of
`
`the range of any repeater or each other (or the repeaters are too far apart).
`
`(Garrabrant at 9:59-10:2) For example, a “lost” message can occur when the
`
`receiver fails to receive the first transmission of a message. But a “lost” message
`
`need not remain “lost.” Future copies of a message that was not received and thus
`
`“lost” at some earlier time may thereafter be received by a receiver. A “lost”
`
`message is not a unique command (or even a command for that matter); a “lost”
`
`message that is received by a receiver is no different from, nor treated differently
`
`from any other message (or packet) received by the receiver—that is why
`
`Garrabrant puts that term in quotes. (See id. at 10:18-28 (“a ‘lost’ message”).)
`
`Upon receipt of an message, the Garrabrant receiver adjusts its valid window (and
`
`concomitantly the rejection window) based upon the sequence number of every
`
`received message—whether that received message is a “lost” message or one
`
`received in sequence.
`
`36.
`
`In any event, the Garrabrant transmitter does not “command” the
`
`receiver to receive a “lost” message (or even any other message, including the next
`
`received packet). The “lost message” is not a command that instructs the receiver
`
`to move its window forward upon receipt of the next received packet. Rather, the
`
`20
`
`
`
`Case IPR2013-00636
`
`
`
`receiver will adjust its window accordingly upon the receipt of a packet (whether
`
`“lost” or not). If the sequence number of the packet is included in its valid
`
`window, the receiver will accept the packet and shift its valid window range to the
`
`next sequence number after the sequence number of the received packet; and
`
`otherwise the packet will be rejected. (Id. at 9:28-32) Because the transmitter
`
`does not maintain the valid window for the receiver, the transmitter does not know
`
`the range of sequence numbers for the valid window of the receiver.
`
`37. Contrary to claim 1 of the ’625 patent, the transmitter in Garrabrant
`
`never commands or forces a receiver to accept a packet. As a result, the
`
`transmitter does not “exercise dominating influence over” or “have command of”
`
`the receiver. As with any other packet, the receiver accepts packets that fall within
`
`its valid window and rejects those falling within its reject window. Id. at 10:36-38
`
`(“When packet 7 eventually arrives at the destination unit, it falls within the valid
`
`window 164 and is accepted by the destination unit.”).
`
`38. Garrabrant also fails to disclose the commanding limitation as
`
`construed by the Board. The Board’s constructionrequires “an instruction
`
`represented in a control field to cause an addressed device to execute a specific
`
`control function.” But Garrabrant is silent as to the structure of the packets.
`
`Garrabrant does not disclose any field—let alone a control field as required under
`
`Broadcom’s proposed construction—that is included by the transmitter within a
`
`21
`
`
`
`Case IPR2013-00636
`
`
`
`packet.
`
`39. An analysis of Figs. 8A and 8B shows that the “lost” message
`
`disclosed in Garrabrant does not command the receiver to accept anything, let
`
`alone a packet:
`
`
`
`40. Fig. 8A illustrates the status of the receiver after receiving packet #1.
`
`Here, the receiver updates the lower end of its valid window accordingly (i.e.,
`
`1+1=2). Id. at 10:28-30. Garrabrant next posits that the transmitter continues to
`
`transmit packets 2-7, but packets 2-6 are presumed “lost,” i.e., not received by the
`
`receiver. Id. Upon receipt of packet #7—which happens to be the next packet
`
`received after packet #1—the receiver processes packet #7 in the same way as any
`
`other received packet to determine whether to accept (sequence number falls
`
`within the range of sequence numbers in the valid window) or reject (sequence
`
`number falls within the range of sequence numbers in the reject window) the
`
`22
`
`
`
`Case IPR2013-00636
`
`
`
`packet. Id. at 10:37-42. Fig. 8B illustrates the valid window of the receiver after
`
`processing packet #7.
`
`41. There is nothing unique about “lost” packet #7. This packet has the
`
`same format and is treated the same way by the receiver as any other packet. The
`
`receiver does not check the actual “command” in a “control” field to decide
`
`whether to handle this packet any differently than packet #1. Nor could it because
`
`Garrabrant does not disclose a control field to force the reception of an out-of-
`
`sequence packet. Just as with every received packet, the receiver checks whether
`
`the sequence number falls within the valid range. If it does, it is accepted; if not, it
`
`is rejected. Nothing in the packet “commands” or “orders” the receiver to accept
`
`the “lost” packet. To the contrary, if the packet included a sequence number
`
`outside the valid window, the receiver would reject it. Id. at 9:5-8. As a result, the
`
`transmitter does not (nor could it) “exercise a dominating influence over” or “have
`
`command of” the receiver. By maintaining its valid and reject windows, the
`
`receiver directs and controls processing of incoming packets, regardless of any
`
`action by the transmitter. In short, the transmitter in Garrabrant does not control or
`
`command the receiver. For this reason, Garrabrant does not teach “commanding a
`
`receiver … to a) receive at least one packet having a sequence number that is not
`
`consecutive with a sequence number of a previously received packet.”
`
`23
`
`
`
`Case IPR2013-00636
`
`
`
`2. Garrabrant does not disclose “commanding a receiver to
`release”
`
`42. Broadcom’s petition fails to address whether Garrabrant discloses a
`
`transmitter that commands a receiver to release expectation of receiving
`
`outstanding packets having prior sequence numbers, and for that reason, Broadcom
`
`cannot show that Garrabrant anticipates claim 1. In granting the institution of inter
`
`partes review, the Board postulated that merely moving the valid window in
`
`Garrabrant upon receipt of a packet whose sequence number SN falls within the
`
`valid window causes the receiver to release expectation of packets whose sequence
`
`numbers are less than SN. (Paper 25 at 15.) But that conclusion is erroneous
`
`because a receiver could receive the retransmission of a rejected packet whose
`
`sequence number had been previously
`
`included
`
`in
`
`the reject window.
`
`Notwithstanding that the sequence number of a “lost” packet that is retransmitted
`
`may initially fall within the reject window of the receiver, the receipt of additional
`
`packets may shift the receive window sufficiently so that the sequence number of
`
`“lost” packet may thereafter fall within the valid window of the receiver.
`
`43. To illustrate, assume that a receiver has a valid window as shown in
`
`Fig. 8B (above). In this case, the receiver received packets #1 and #7, but packet
`
`#2 is “lost” and is retransmitted. The receiver initially rejects Packet #2 because its
`
`sequence number falls within the reject window. However, upon receipt of packet
`
`24
`
`
`
`Case IPR2013-00636
`
`
`
`#22, the receiver updates its window such that its valid window spans sequence
`
`numbers 23 through 8, and its reject window spans sequence numbers 9 through
`
`22. In this state, the receiver can accept the retransmission of packet #2 since its
`
`sequence number falls within the updated valid window of the receiver. Therefore,
`
`upon reception of an out-of-sequence packet (packet #7), the receiver cannot
`
`release all expectation of receiving packets having prior sequence numbers (packet
`
`#2).
`
`3. Garrabrant does not disclose “discarding unacknowledged
`packets”
`
`44. The “lost” message scenario of Garrabrant also fails to anticipate
`
`claim 1 because Garrabrant does not teach “the transmitter discarding all packe