DOCKET NO: 0111168-00239
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`PATENT:
`
`6,424,625
`
`INVENTOR:
`
`Larsson, P. et al.
`
`TITLE:
`
`METHOD AND APPARATUS FOR DISCARDING PACKETS
`
`IN A DATA NETWORK HAVING AUTOMATIC REPEAT REQUEST
`
`Mail Stop PATENT BOARD
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`
`PO. Box 1450
`
`Alexandria, VA 22313-1450
`
`DECLARATION OF HARRY BIMS, PH.D.
`
`1, Harry Bims, declare as follows:
`
`General Background
`
`1.
`
`My name is Harry Bims.
`
`I have been asked to offer opinions
`
`regarding whether the claims of U.S. Patent No. 6,424,625 (the ‘625 patent) are
`
`anticipated or would have been obvious in View of the prior art, and to review a
`
`Petition for Inter Partes Review of the ‘625 patent.
`
`2.
`
`I received my B.S. in computer and systems engineering from
`
`Rensselaer Polytechnic Institute in 1985, my M.S. in electrical engineering from
`
`Stanford University in 1988, and my Ph.D. in electrical engineering from Stanford
`
`University in 1993. Since receiving my doctorate, I have worked on a number of
`
`ActiveUS 1 1654-8286v.l
`
`1
`
`BROADCOM 1006
`
`
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`PATENT:
`
`6,424,625
`
`INVENTOR:
`
`Larsson, P. et al.
`
`TITLE:
`
`METHOD AND APPARATUS FOR DISCARDING PACKETS
`
`IN A DATA NETWORK HAVING AUTOMATIC REPEAT REQUEST
`
`Mail Stop PATENT BOARD
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`
`PO. Box 1450
`
`Alexandria, VA 22313-1450
`
`DECLARATION OF HARRY BIMS, PH.D.
`
`1, Harry Bims, declare as follows:
`
`General Background
`
`1.
`
`My name is Harry Bims.
`
`I have been asked to offer opinions
`
`regarding whether the claims of U.S. Patent No. 6,424,625 (the ‘625 patent) are
`
`anticipated or would have been obvious in View of the prior art, and to review a
`
`Petition for Inter Partes Review of the ‘625 patent.
`
`2.
`
`I received my B.S. in computer and systems engineering from
`
`Rensselaer Polytechnic Institute in 1985, my M.S. in electrical engineering from
`
`Stanford University in 1988, and my Ph.D. in electrical engineering from Stanford
`
`University in 1993. Since receiving my doctorate, I have worked on a number of
`
`ActiveUS 1 1654-8286v.l
`
`1
`
`BROADCOM 1006
`
`
`
`wireless and mobile technologies, including wireless pagers, wireless home LAN
`
`protocols, cellular products including 2.5G and 3G products, wireless network
`
`infrastructures based on the 802.11 wireless specification, and wireless networks in
`
`the 4G technology known as WiMAX, an implementation of 802.16.
`
`3.
`
`I have been actively involved in the development of the 802.16
`
`standards, which is a series of wireless broadband standards written by the Institute
`
`of Electrical and Electronics Engineers (IEEE), including as a vice-chair of the
`
`802.16 working group, and chair of two task groups. Previously, I was the vice-
`
`chair and secretary of the IEEE 802.16h License Exempt Task Group.
`
`4.
`
`I am currently working as both a technology consultant in the industry
`
`and an expert consultant for litigation matters.
`
`5.
`
`I began my technical career in 1992 just before completing my Ph.D.
`
`as one of the first employees at Glenayre Technologies, where I worked until 1998.
`
`While at Glenayre, I designed and built a 4—channel wireless pager demonstration
`
`based on the ReFLEX wireless protocol developed by Motorola, which led to an
`
`award for Narrowband Personal Communications Service (PCS) development.
`
`I
`
`invented, designed, and built a two-way pager test system for the ReFLEX
`
`protocol that was deployed around the country for testing pagers. Additionally, I
`
`co-developed a wireless application protocol for sending and receiving encrypted
`
`ActiveUS l 1654-8286v.l
`
`
`
`email messages over the paging channel, which was ultimately deployed for
`
`government agencies.
`
`6.
`
`In 1999, I was a member of the technical staff at T—SPAN Systems
`
`Corporation LLC, where I designed a wireless home LAN protocol. In 1999 I also
`
`served as a technical leader to Gigabit Wireless, Inc., where I lead the Wireless
`
`Media Access Control (MAC) design group. My work at Gigabit Wireless
`
`involved analyzing competing wireless MAC protocol standards, creation of a
`
`proprietary MAC protocol specification document, simulation of the protocol, and
`
`ultimate implementation of the protocol in a prototype.
`
`I also participated in
`
`meetings for the 802.16 standards starting at about that time.
`
`7.
`
`From 1999 to 2001, I served as the director of software architecture at
`
`Symmetry Communications Systems LLC, where I was responsible for the
`
`software architecture for their core products for the GPRS market.
`
`In 2001, I also
`
`worked as an entrepreneur in residence at the venture capital firm Bay Partners
`
`LLC, where I served as a technology expert to the partners of the firm on a range
`
`of wireless and networking subjects.
`
`8.
`
`From 2001 to 2004 I founded my own company, AirFlow Networks,
`
`Inc. LLC, where I served as CEO and CTO. AirFlow Networks was involved with
`
`a wireless network infrastructure based on the 802.11 wireless specification.
`
`ActiveUS I 1654-8286v.l
`
`
`
`9.
`
`From 2007 to 2009 I worked as a technology consultant to Apple,
`
`Inc., including participating in IEEE 802.16 standards meetings.
`
`10.
`
`I am a named inventor on nineteen U.S. Patents that involve various
`
`aspects of wireless and mobile communications. Examples of my patents include
`
`U.S. Patent No. 6,788,658 entitled “Wireless communication system architecture
`
`having split MAC layer,” which issued on September '7, 2004; and U.S. Patent No.
`
`6,557,134 entitled “ARQ method for wireless communication,” which issued on
`
`April 29, 2003; and most recently, U.S. Patent No. 8,468,426 entitled
`
`“Multimedia—aware quality-of-service and error correction provisioning,” which
`
`issued on June 18, 2013. Additionally, I have authored or co—authored a number of
`
`articles in the fields of electrical engineering and computer science.
`
`11.
`
`I have been a member or vice~chair of numerous associations,
`
`including the chair of the Silicon Valley Chapter of the IEEE Engineering
`
`Management Society, and vice-chair of the 802.16 Working Group of the IEEE
`
`802 Standards Development Committee.
`
`12.
`
`A copy of my latest curriculum vitae (CV) is attached as Appendix A.
`
`13.
`
`I am being compensated at my normal consulting rate for my work.
`
`My compensation is not dependent on and in no way affects the substance of my
`
`statements in this Declaration.
`
`ActiveUS 11654-8286v.l
`
`
`
`14.
`
`I have no financial interest in Petitioner.
`
`I have been informed that
`
`Ericsson purports to own the patent for which review is requested.
`
`1 have no
`
`financial interest in Ericsson.
`
`U.S. Patent No. 6,424,625
`
`15.
`
`I have reviewed and understand the specification, claims, and file
`
`history of the ‘625 patent.
`
`16.
`
`I have considered certain issues from the perspective of a person of
`
`ordinary skill in the art. In my opinion, a person of ordinary skill in the art for the
`
`‘625 patent would be a person with a bachelor's or graduate degree in a relevant
`
`field, such as electrical or computer engineering or computer science, with some
`
`amount of work experience in communications.
`
`Technical Background
`
`17.
`
`Automatic repeat request (“ARQ”) refers to a class of protocols for
`
`packet data networks that allows a transmitter to automatically retransmit packets
`
`(known also as protocol data units (“PDUS”), cells, frames, or fragments thereof)
`
`to a receiver when those packets are not received or are incorrectly received by the
`
`receiver (e.g., ‘625 patent, 1:34-37, Ex. 1001). A receiver can transmit a positive
`
`acknowledgement (“ACK” or “PACK”) that one or more data units have been
`
`received (and which can include a request for a data unit), and/or a negative
`
`acknowledgement (“NAK” or “NACK”) indicating that one or more packets have
`
`ActiveUS l 1654-8286v.l
`
`
`
`not been received. The transmitter can retransmit the packets if there is a NACK,
`
`or if there is no PACK (e.g., because a timer in the transmitter times out). (Id. at
`
`1:34-49 and 2:28-57, Ex. 1001).
`
`18.
`
`ARQ systems typically associate each packet with a sequence number
`
`(“SN”). The receiver uses the SN to track which packets have been sent,
`
`acknowledged, received, or not received, as well as to allow a receiver to
`
`reassemble a proper order of the packets if packets can be sent out of order.
`
`(See,
`
`e.g., id. at 1:50-2:2, Ex. 1001). The sequence numbers are used in a modulo
`
`manner, and thus can be represented as a circular buffer. That is, they are
`
`numbered, for example, 0, 1, 2, 30, 31, 0, 1, 2,
`
`Thus, the numbers should be
`
`viewed in the sense of earlier and later rather than higher and lower, although both
`
`terms are used.
`
`(See, id. at 7:10-16, Ex. 1001).
`
`19.
`
`There are a number of different types of ARQ systems, including
`
`systems known as “stop—and-wait,” Go-Back—N, and selective reject systems.
`
`Examples of such systems are identified in the Background of the ‘625 patent
`
`(‘625 patent, 1:13-3:40, Ex. 1001); other examples are also well-known. (See, e.g.,
`
`Bertsekas, pp. 58-73, Ex. 1012).
`
`In an example of a Go-Back~N implementation,
`
`the transmitter sends up to :1 packets, and receives acknowledgements with a
`
`request number (RN) requesting the next packet. The RN messages cumulatively
`
`acknowledge packets with SN<RN and request RN=SN. For example, the
`
`ActiveUS l 1654-8286v.l
`
`
`
`transmitter sends packets #1 through #18, while the receiver send RN #2 through
`
`#14 to acknowledge positively received packets #1 through #13.
`
`In this example,
`
`if the transmitter can send and buffer up to 7 packets without receiving an RN
`
`message, it will continue to transmit packets #14 through #20, filling the buffer.
`
`The transmitter then must “go back 7” and retransmit packets #14 through #20.
`
`(See, e.g., Bertsekas, pp. 63-66, Ex. 1012).
`
`20. Another ARQ protocol is known as a selective reject (“SR”) system.
`
`In a SR ARQ system, the transmitter has a transmit window with a range of
`
`sequence numbers it can send (based on the size of a transmit buffer), and the
`
`receiver has a receive window of sequence numbers it can receive (based on the
`
`size of a receive buffer). In a system that has k-bits for the sequence numbers and
`
`thus 21‘ sequence numbers, the window size is often 21“, or one-half the possible
`
`sequence numbers. (See ‘625 patent at 2:57-65, Ex. 1001). Thus, if there are 32
`
`possible sequence numbers (5 bits), the transmit and receive windows often will
`
`have 16 spaces.
`
`21.
`
`If a transmitter successfully transmits packets with SN #0 though #20,
`
`16-bit transmit and receive windows will move forward, e. g., from #0-#15, to #1-
`
`#16, to #2-#17, etc. The Garrabrant prior art, Figures 7A and 7B (Ex. 1002),
`
`shows how a “valid [receive] window” and a corresponding “rejection window”
`
`move in a circular manner:
`
`ActiveUS 1 1654-8286v.l
`
`
`
`
`
`22. According to the Background of the ’625 patent, where packets are
`
`time-sensitive, such as speech or streaming video, the additional delay experienced
`
`at the receiver while waiting for multiple rounds of NACKS and retransmissions
`
`may have a more negative impact on application performance than simply
`
`discarding a missed packet and moving on to receive other packets.
`
`(See, e.g. , id.
`
`at 3:46-67, Ex. 1001).
`
`23.
`
`The ‘625 patent asserts that “current ARQ methods do not recognize
`
`and allow for situations where data packets have a limited lifetime [such as time
`
`sensitive packets, like streaming video], and therefore fail to minimize bandwidth
`
`usage by not sending (or resending) significantly delayed or outdated data
`
`packets.” (Id. at 4:9-13, Ex. 1001).
`
`24.
`
`The ‘625 patent says that it seeks to remedy this situation through the
`
`use of an “enforcement bit” that, in effect, tells the receiver to move its receive
`
`ActiveUS I 1654-8286v.l
`
`
`
`window forward to a new sequence number, and therefore to “release any
`
`expectation of receiving outstanding packets” with lower sequence numbers than
`
`that new sequence number. (Id. at 10:20-21, Ex. 1001).
`
`25.
`
`In the example above where there was a NACK for a packet with
`
`SN#14, but packets with SN #15 through #20 were correctly received, assume the
`
`transmitter decides to discard the packet with SN #14 rather than retransmitting it.
`
`According to the ‘625 patent, the transmitter could transmit a packet with SN #15
`
`with an enforcement bit set to TRUE. Once the receiver receives an enforcement
`
`bit set to TRUE, the receiver can forward packets with SN #15 through #20 to
`
`higher layers for processing, and move the lower end of its window up to a packet
`
`with SN #15, thereby skipping the packet with SN #14. The receiver would then
`
`move the lower end of its window up to the data unit with SN #21 as data units
`
`with SN #15 through #20 are correctly received and forwarded up to higher layers
`
`for processing. (See, e.g., id. 8:24-30, Ex. 1001).
`
`26.
`
`This process is shown, for example, in Garrabrant, Ex. 1002, Figures
`
`8A and 8B. As described in more detail below, the transmitter and receiver start
`
`with a valid window of #2 through #17 (Figure 8A). The transmitter
`
`unsuccessfully transmits, and then decides to discard, packets with SN #2 though
`
`SN #6. The transmitter sends a control message (lost) and a packet with SN #7,
`
`and then the window moves to SN #7 and then to SN #8 (Figure 8B).
`
`ActiveUS 1 1654-8286v.l
`
`
`
`
`
`27.
`
`An example of a window of the ‘625 patent, along with different
`
`sequence number values that are maintained in relation to the window, is
`
`represented in Figure 10B:
`
`
`
`Actual buffer content
`
`Max buffer size
` ....................
`' PL+
`PL+
`PL+
`PL+
`
`
`PL+
`S PL+
`Comp.
`Comp.
`Comp.
`N
`
`
`
`Header
`Header
`Header
`
`
`
`PDUs which have
`not yet been
`ISN re_transmmed
`
`
`
`TSNMAX’
`TSN
`
`PSN
`
`2
`2
`2
`5
`s
`2
`_
`5
`5
`5
`5
`3
`3
`3........3 E........2 S........E
`
`Discarded cells
`DSN
`
`BSN
`
`Camp.
`Header
`
`Camp.
`Header
`
`Comp.
`Header
`
`SW
`PDUs which have
`been re-transmitted
`
`Comp.
`Hader
`
`Comp.
`Headeri
`
`
`
`
`
`PDUs pending
`for transmission
`
`
`
`
`28.
`
`The receive window (W) extends from sequence number values DSN
`
`to TSN,.m, while the “actual buffer” in the transmitter extends from BSN to PSN.
`
`The receive window is typically half of the sequence number space; that is, if the
`
`SN has 5 bits, and thus there are 32 possible sequence numbers, the receive
`
`AetiveUS ll6548286v.1
`
`-10-
`
`
`
`window would have 16 values. (Id. at 5:58-63, 6:20-50, 7:42-47, Ex. 1001). The
`
`DSN in Figure 10B designates the SN below which all packets have been
`
`acknowledged. BSN designates the SN of the lowest non—discarded packet. If
`
`there are no discarded packets, then DSN = BSN. If there are discarded PDUs but
`
`the receiver has not yet been notified, then DSN < BSN, as shown above where
`
`there are 3 discarded packets in window W. (Id. at Figure 10B, 5:65-6:9, Ex.
`
`1001).
`
`29.
`
`TSN,,,,,, designates the top of the window, and has a SN of DSN + W.
`
`(7:42-47). The packets with SNS above TSNM, are PDUs have been buffered, but
`
`are “not allowed to be transmitted.” (Id. at 6:56—60, Ex. 1001). The transmitter
`
`holds packets greater than TSNmax in a buffer because these packets would be
`
`outside the receive window, and therefore cannot be accepted at the receiver.
`
`(Id.
`
`at 7:26-33 and 11:38-48, EX. 1001).
`
`30.
`
`Because the receiver does not yet know that the packets between DSN
`
`and BSN will be discarded, the receiver holds spaces for them. Therefore, the
`
`receive window would extend from DSN to DSN + W. The receive window does
`
`not have room for the packets from TSN to PSN, and therefore these packets
`
`delayed until DSN and perhaps also BSN can move forward.
`
`(Id. at 6:51-65, Ex.
`
`1001).
`
`ActiveUS l 1654-8286v.l
`
`11
`
`
`
`31.
`
`The ‘625 patent identifies 6 situations or rules for operation, referred
`
`to as “cases” (id. at 824-9210, Ex. 1001), which are claimed in dependent claim 6.
`
`(Id. at 11:23-12:64). In a “third case” identified in the ‘625 patent, for example,
`
`the transmitter receives a NACK for an expected sequence number (ESN1) that is
`
`between DSN and BSN — i.e., a NACK is received for a packet that the transmitter
`
`has already decided to discard along with all other packets not acknowledged and
`
`below BSN. (See id. at FIG. 10B, “discarded cells”, Ex. 1001). As shown in FIG.
`
`10B and described in the ‘62S patent, “at least one packet is not yet discarded, and
`
`at least one outstanding packet exists that has a sequence number >= BSN.” In this
`
`case, “the first outstanding packet after BSN is retransmitted with [the Receiver
`
`Packet Enforcement Bit] RPEB = TRUE.” (Id. at 8:24-30, Ex. 1001).
`
`32.
`
`In this case, the first outstanding packet after BSN is retransmitted,
`
`even though there is no indication that it was specifically not acknowledged, but it
`
`is retransmitted anyway. Also, this retransmitted packet just after BSN is within
`
`the transmit and receive window.
`
`33.
`
`The purpose of RPEB = TRUE is to move the window forward and
`
`cause the receiver to not expect any packets below the new lower end of the
`
`window (Id. at 5:28-40, 8:24-30, Ex. 1001). If the sequence number, SN, of a
`
`packet sent with RPEB = TRUE is greater than the window length above the
`
`expected SN (i.e., ESN + W), then the receiver “perform[s] one of a) a restart
`
`ActiveUS l 1654-8286v.l
`
`12
`
`
`
`and b) reporting a failure.” (Id. 11:38-48, Ex. 1001). The packet sent with the
`
`enforcement bit RPEP must therefore be within the window. Similarly, in the Go-
`
`Back—N embodiment and dependent claim 4, the receiver accepts a packet within a
`
`window N(S) < ESN+2"", and rejects if N(S) >= EsN+2"".
`
`(Id. at 10:52-61, Ex.
`
`1001).
`
`Claim Construction
`
`34.
`
`I understand that the claims in an inter parres review should be given
`
`their “broadest reasonable construction in light of the specification” as commonly
`
`understood by a person of ordinary skill in the art.
`
`The term “commanding”
`
`35.
`
`“Commanding” as used in the ‘625 patent should be given a plain and
`
`ordinary meaning of sending a command. In my opinion, in a communications
`
`system, a definition is “an instruction represented in a control field to cause an
`
`addressed device to execute a specific control function.” This definition is
`
`consistent with the claims and specification of the ‘625 patent, where the primary
`
`example of a command is an “enforcement bit” that is in a control field and is
`
`designed to cause a specific control function (move the window).
`
`36.
`
`This construction is also consistent with a definition from the IEEE
`
`dictionary from 2000, which reads “command (1) (logical link control). In data
`
`communications, an instruction represented in the control field of a protocol data
`
`ActiveUS 1 1654-8286v.l
`
`13
`
`
`
`unit (PDU) and transmitted by a logical link control (LL-C).
`
`It causes the addressed
`
`LLC(s) to execute a specific data link control function.” (IEEE Dictionary at 214-
`
`215, Ex. 1011).
`
`I understand that in the Texas Litigation, the Patent Owner took a
`
`view of the meaning of “command” that I believe is too broad. For example,
`
`Patent Owner asserted that the mere act of receiving a data packet is a command
`
`because the receiver knows to receive it:
`
`A. Right. The —— the —— the —— receiving that packet is a command
`
`to receive out of order.
`
`Q. And explain one more time, why is receiving the packet a
`
`command to receive out of order?
`
`A. Because since this particular packet
`
`is out of order and
`
`you're not allowed to not receive it, you're required to receive it,
`
`it's a command. (Trial Transcript at p. 84:19-85:20, Ex. 1014)
`
`37.
`
`This broad reading is inconsistent with the plain and ordinary meaning
`
`of the term as used in the ‘625 specification itself. For example, the ‘625 patent
`
`states that “[i]f a packet is expected which has already been discarded, then the
`
`transmitter resynchronizes by renumbering data packets or by commanding the
`
`receiver to accept an arbitrarily chosen sequence number.” (Id. at 4:39-42, Ex.
`
`1001).
`
`I interpret this to teach that a sequence number is not a command because
`
`A(:tiveUS il6548286v.l
`
`-14-
`
`
`
`the ‘625 patent uses the term “command” separately from a “sequence number” to
`
`refer to different methods that the transmitter can use to resynchronize.
`
`38.
`
`The Patent Owner’s assertions regarding the meaning of
`
`“commanding” are also inconsistent with how one of ordinary skill in the art would
`
`understand this term. The packet and its sequence number are simply data that the
`
`receiver uses; the packet is not an instruction to perform any control function.
`
`Moreover, one of ordinary skill would not view the packet as a command to
`
`receive simply because the receiver receives the packet. Instead, as explained
`
`above, a “command” in the context of the ‘625 patent is “an instruction represented
`
`in a control field to cause an addressed device to execute a specific control
`
`function.” (Id.)
`
`The phrase “commanding. . .to receive... and [to] release any expectations”
`
`39.
`
`The claimed commanding steps are about the releasing of
`
`expectations, also referred to as the “transmitter resynchroniz[ing].” (Id. at 4:37-
`
`42, Ex. 1001). Moving the window forward is the function that the RBEP
`
`enforcement bit has in the selective reject embodiments. The examples in the ‘625
`
`patent teach that the transmitter is commanding the receiver to release expectations
`
`such that the receiver releases any expectation of receiving packets with a
`
`sequence number lower than a certain number.
`
`ActiveUS l 1654-8286v.l
`
`15
`
`
`
`40.
`
`In an expert report submitted by the Patent Owner, it was suggested
`
`that “commanding ...to receive one or more packets” requires that the receiver
`
`must receive packets outside a reception window. (Ex. 1010, discussed infra.) I
`
`disagree.
`
`41.
`
`This interpretation is inconsistent with the ‘625 patent specification
`
`because the transmitter commands the receiver to “expect” a sequence number of a
`
`next packet to be sent from the transmitter, such as by “commanding the receiver
`
`to accept an arbitrarily chosen sequence number.” (‘625 patent at 4:41-42, Ex.
`
`1001). The command does not force a requirement onto the receiver that it “must”
`
`do anything other than “the receiver can be commanded to skip or overlook the
`
`packets which have been discarded.” (Id. at 5:22-23, Ex. 1001).
`
`42.
`
`In the Texas Litigation, the Patent Owner asserted that the claimed
`
`“commanding .
`
`.
`
`. to receive one or more packets” requires that the receiver must
`
`receive packets under circumstances where it otherwise would not do so. The
`
`Patent Owner argued that the asserted prior art did not disclose this limitation
`
`because the prior art “discloses a system in which the receiver may reject an out-
`
`of—sequence packet sent by the transmitter if the packet is outside of the reception
`
`window.” (See e.g., Report at 1H[ 242, 250, 285, etc., Ex. 1010).
`
`I disagree for
`
`several reasons.
`
`43.
`
`The Patent Owner’s assertions are inconsistent with Claim 1. If the
`
`ActiveUS l 1654-8286v.l
`
`16
`
`
`
`“at least one packet” of Claim 1 has an SN that is greater than the window (e.g.,
`
`SN #18, where the window ranges from SN #1 through SN #16), a receiver could
`
`move its window to #3 through #18, but then the receiver would not be “releas[ing]
`
`any expectation of receiving outstanding packets having sequence numbers prior to
`
`the at least one packet,” because that would require moving the window to #18
`
`through #2.
`
`44.
`
`The Patent Owner’s assertions are also inconsistent with the
`
`specification of the ‘625 patent. In the ‘625 patent, the transmitter commands the
`
`receiver to “expect” a sequence number of a next packet to be sent from the
`
`transmitter, such as by “commanding the receiver to accept an arbitrarily chosen
`
`sequence number.” (‘625 patent at. 4:41-42, Ex. 1001). The command does not,
`
`however, require the receiver to receive a packet it would otherwise reject. Indeed,
`
`the claimed receiver is not required to do anything other than “skip or overlook the
`
`packets which have been discarded.” (Id. at 5:22-23, Ex. 1001).
`
`45.
`
`The Patent Owner’s assertions are also inconsistent with dependent
`
`Claims 4 and 6, each of which limits packet acceptance based on the sequence
`
`number, and indicates that the receiver would reject packets received outside the
`
`window.
`
`ActiveUS l 1654-8286v.1
`
`17
`
`
`
`The Challenged Claim Is Anticipated by Garrabrant (Ex. 1002)
`
`46.
`
`I have reviewed and understand Garrabrant, U.S. Patent
`
`No. 5,610,595 (“Garrabrant”).
`
`In my opinion, a person of ordinary skill in the art
`
`would find Garrabrant to be an enabling disclosure of the subject matter it
`
`discusses.
`
`47. Garrabrant is a patent, assigned on its face to Intermec Corp., relating
`
`to a Packet Radio Communication System Protocol for mobile devices, a base
`
`radio unit (BRU), and repeaters. (See Garrabrant, Figures 5 and 6, EX. 1002).
`
`48.
`
`Garrabrant uses a repeat counter to determine how many times to
`
`repeat sending a packet. (Garrabrant, Abstract, Ex. 1002). The repeat counter is
`
`decremented each time the packet is transmitted, and when the counter reaches
`
`zero, the packet is discarded. (Id. at 8:45—-57, Ex. 1002). Garrabrant also discloses
`
`sending a “lost” message to instruct the receiver to move its valid/rej ection
`
`window forward and skip over (release expectations of receiving) the lost packets.
`
`(Id. at 10:14-42, Ex. 1002). Garrabrant discloses the subject matter of claim 1 in
`
`two different ways -— both in recovery from lost packets and in recovery from a
`
`failure state.
`
`49.
`
`The transmitter and receiver have respective windows, including a
`
`valid reception window space that is one—half the Sequence Number (SN) space;
`
`i.e., there are 16 usable SNs in a space of 32 SNs. (Garrabrant, Figures 7a and 7b;
`
`ActiveUS l16548286v.l
`
`
`
`9:9-10:13, Ex. 1002). This is a common approach that is also primarily used in the
`
`‘625 patent. (‘625 patent, 2:58-65, 6:36-50, 7:26-33, 11:44-48, Figures 7A—7C and
`
`12, Ex. 1001).
`
`50.
`
`Errors in transmission can occur, as shown in Garrabrant’s Figures 8A
`
`and 8B. A valid window ranges from SN #2 through #17, and the rejection
`
`window includes SN #18 through #1. (Garrabrant, Figure 8A, 10: 14-23, Ex.
`
`1002). In this example, “packets 2 through 6 were lost. As a consequence, the
`
`‘valid’ Window 164 did not advance further.” (Id. at 10:29-31, Ex. 1002). The
`
`“rejection window is updated in response to the receipt of a ‘lost’ message” and
`
`packet #7 (Id. at 10:23-24, 10:37-38, Ex. 1002). When packet #7 arrives, it is
`
`“accepted by the destination unit”, and then the lower sequence count is set to #8
`
`as shown in Figure 8B. The “lost” message is a command that commands the
`
`receiver that upon receipt of the next received packet (which is non-consecutive
`
`with previously received packet #1), it should move its “rejection” window
`
`forward, and not expect to receive packets #2 through #6.
`
`51.
`
`Claim 1 of the ‘625 patent recites:
`
`1.
`
`[pre] 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]
`
`a transmitter in the data network commanding a receiver
`
`in the data network to a) receive at least one packet having a
`
`ActiveUS l 1654-8286v.l
`
`1
`
`2-;
`
`
`
`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
`
`[b]
`
`the transmitter discarding all packets for which
`
`acknowledgment has not been received, and which have
`
`sequence numbers prior to the at least one packet.
`
`52.
`
`To the extent the preamble is a limitation of claim 1, Garrabrant
`
`discloses “[a] method for discarding packets in a data network employing a packet
`
`transfer protocol including an automatic repeat request.” (See Garrabrant, 2:1—12,
`
`10:13-15, Ex. 1002).
`
`53.
`
`Garrabrant discloses a system with sending and receiving windows,
`
`and where the receiving unit acknowledges transmission or else the transmission is
`
`repeated if there is a time—out.
`
`(See, id. at Figures 7A, 7B, 8A, 8B, and 12; 2:1-2,
`
`and 9:9-10:41, Ex. I002).
`
`54.
`
`Garrabrant teaches “[a] 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.”
`
`ActiveUS 1 1654-8286v.l
`
`20
`
`
`
`55.
`
`Garrabrant discloses a receiver updating its window in response to the
`
`receipt of a “lost” message.
`
`(Id. at 10:21-23, Ex. 1002). Upon receipt, the receiver
`
`receives packet #7, which is non—consecutive with previously received packet #1,
`
`moves the window forward to packet #7, and is then prepared to receive packet #8.
`
`(See id. at Figures 8A and 8B; 10:14-41, Ex. 1002). In Figures 8A and 8B,
`
`“packets 2 through 6 were lost. As a consequence, the ‘valid’ Window 164 did not
`
`advance fiirther.” (Id. at 10:29-31, Ex. 1002) The “rejection window is updated in
`
`response to the receipt of a ‘lost’ message” (Id. at 10:23-24, Ex. 1002); when
`
`packet #7 arrives, it is “accepted by the destination unit” (Id. at 10:37-38, Ex.
`
`1002), and then the lower sequence count is set to #8 as shown in Figure 8B.
`
`56. While I do not believe that the command to receive requires that the
`
`receiver receive a packet it otherwise would not receive, this lost command and the
`
`sending of packet #7 causes the receiver to advance the window to receive packets
`
`that include packets it otherwise would not have been able to receive prior to the
`
`lost command and transmission of packet 7.
`
`57. Garrabrant discloses “[b] the transmitter discarding all packets for
`
`which acknowledgment has not been received, and which have sequence numbers
`
`prior to the at least one packet.” (Garrabrant, 10:23-25, Ex. 1002). Lost packets 2
`
`through 6 would be discarded by having the transmitter move its window forward.
`
`ActiveUS l 1654-8286v.l
`
`21
`
`
`
`(See, e.g., id. at 10:16, Ex. 1002). As also indicated in Figure 12 and at 12:43-
`
`13:3, once the counter reaches zero, the packet is discarded.
`
`Patent Owner’s Response
`
`58.
`
`I understand that in a litigation the Patent Owner submitted a Report
`
`(“Report”, Ex. 1010 in redacted form) in which the Patent Owner disputed that
`
`Garrabrant taught a “command” as claimed in ‘the ‘625 patent.
`
`59.
`
`I disagree. Garrabrant discloses a “command.” Garrabrant discloses a
`
`“lost” message that causes the receiver to move its window forward, and thus
`
`release expectations of receiving certain packets. (Id. at 2:62 — 3:5; 4:6-9; and 10:
`
`17-42, Ex. 1002). The Report never explains why the lost message described in
`
`Garrabrant is not a “command.”
`
`60.
`
`The Report argued that Garrabrant “repeatedly states that if a packet is
`
`received outside of the reception window, the packet will be rejected.” (Report at
`
`p. 123, Ex. 1010).
`
`I believe it is irrelevant whether or not packets with sequence
`
`numbers outside a receive window are rejected. Claim 1 does not require that a
`
`receiver receive packets outside the reception window. As noted above, the
`
`specification and claims of the ‘625 patent indicate that the ‘625 patent method
`
`also rejects packets that are outside a reception window, and thus this is no
`
`difference from the claims.
`
`ActiveUS 1 1654-8286v.l
`
`22
`
`
`
`61.
`
`The Report also asserts that Garrabrant “does not indicate whether a
`
`transmitter discards packets 2 through 6.” (Id. at p. 123, Ex. 1010). But, the
`
`transmitter moves its window forward past the “lost” packets, and this process
`
`discards the packets. Further, Figure 12 shows that when a repeat count = 0 (box
`
`214), a packet is discarded (box 218).
`
`62.
`
`The Report states that Garrabrant “fails to enable one skilled in the art
`
`to implement a discard notification scheme which anticipates the ‘625 patent.”
`
`(Report at p. 12], Ex. 1010). But, the Report provides no basis for this argument,
`
`and never explains what teaching are purportedly absent from Garrabrant. In fact,
`
`Garrabrant does enable a discard notification scheme.
`
`Garrabrant Failure Recovery
`
`63.
`
`Garrabrant also discloses failure modes and recovery that cause the
`
`windows to advance to new values, and cause packets “below” the window to be
`
`discarded at the transmitter and not to be expected at the receiver. (Garrabrant,
`
`10:55-12:4, EX. 1002).
`
`64.
`
`The mobile devices in Garrabrant can move within and outside of a
`
`coverage area. (Garrabrant, 11:1-4, 11:11-13, Ex. 1002). The mobile device and
`
`base radio unit (BRU) (base station) can each be a transmitter and a receiver. (Id.
`
`at 4:46-50; FIGS. 1-2, EX. 1002). In some instances, such as a fail state, a number
`
`of packets are lost and synchronization is lost. (See id. at 10:42-60, Ex. 1002). In
`
`ActiveUS l 1654-8286v.l
`
`23
`
`
`
`such a case, there would be packets that the transmitter sent, but that were not
`
`received when synchronization was lost. (Id. at 9:59-10:13, Ex. 1002).
`
`65.
`
`Column 11 describes a series of steps whereby the mobile sends “an
`
`SABM command” to establish communication, along with a sequence number to
`
`synchronize windows. (Garrabrant, l1:1—12:4, Ex. 1002). There can be multiple
`
`rounds of messages, described in Garrabrant as “events”; eventually, the command
`
`to establish synchronization is received and accepted. (Id. at 11:58—67, Ex. 1002).
`
`66.
`
`To the extent the preamble is a limitation of claim 1, Garrabrant
`
`discloses “[a] method for discarding packets in a data network employing a packet
`
`transfer protocol including an automatic repeat request.” (See Garrabrant, 2: 1-12,
`
`10: 13-15, Ex. 1002). Garrabrant discloses a system with sending and receiving
`
`windows, and where the receiving unit acknowledges transmission or else the
`
`transmission is repeated if there is a time—out.
`
`(See, id.at Figures 7A, 713, 8A, 8B,
`
`and 12; 2:1-2, an
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
