throbber

`
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket