DOCKET NO: 0111168.00239
`Filed on behalf of Broadcom Corp.
`
`By: Dominic E. Massa, Reg. No. 44,905
`
`Michael A. Diener, Reg. No. 37,122
`
`Wilmer Cutler Pickering Hale and Dorr LLP
`
`60 State Street
`
`Boston, MA 02109
`
`Tel: (617) 526-6454
`
`Email: Michael.Diener@wilmerhale.com
`
`Dominic.Massa@wilmerhale.com
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________________________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________________________________________
`
`BROADCOM CORP.
`Petitioner
`
`
`v.
`
`Patent Owner of
`U.S. Patent No. 6,424,625 to Peter Larsson et. al.
`
`IPR Trial No. TBD
`
`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
`
`
`
`
`
`

`
`
`
`I. 
`
`A. 
`B. 
`C. 
`D. 
`E. 
`II. 
`A. 
`B. 
`III. 
`
`A. 
`B. 
`IV. 
`A. 
`B. 
`C. 
`D. 
`E. 
`V. 
`A. 
`B. 
`C. 
`D. 
`VI. 
`A. 
`
`B. 
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`TABLE OF CONTENTS
`
`Page
`
`MANDATORY NOTICES ................................................................... 1 
`Real Parties-in-Interest ...................................................................... 1 
`Related Matters .................................................................................. 1 
`Counsel .............................................................................................. 2 
`Service Information ........................................................................... 2 
`Certification of Grounds for Standing ............................................... 2 
`OVERVIEW OF CHALLENGE AND RELIEF REQUESTED.......... 3 
`Prior Art Patents and Printed Publications ........................................ 3 
`Grounds for Challenge ....................................................................... 4 
`OVERVIEW OF THE ‘625 PATENT – TECHNICAL
`BACKGROUND ................................................................................... 5 
`Automatic Repeat Request Protocols ................................................ 5 
`Alleged Invention of the ‘625 Patent ............................................... 10 
`Claim Construction ............................................................................. 15 
`Claim 1 of the ‘625 patent ............................................................... 15 
`Scope of the Claimed Method Performed by a Transmitter ............ 16 
`The Preamble Is Not Limiting ......................................................... 17 
`“Commanding” ................................................................................ 18 
`“Commanding…to receive… and [to] release any expectations.” .. 21 
`THE CHALLENGED CLAIM IS UNPATENTABLE ...................... 23 
`Garrabrant ........................................................................................ 24 
`Hettich .............................................................................................. 24 
`Walke ............................................................................................... 25 
`Kemp ................................................................................................ 26 
`SPECIFIC GROUNDS FOR PETITION ........................................... 27 
`Grounds of Invalidity for Challenged Claim 1 based on Garrabrant
`as a Primary Reference .................................................................... 28 
`Grounds of Invalidity for Challenged Claim 1 based on Hettich as a
`Primary Reference ........................................................................... 37 
`i
`
`

`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`Grounds of Invalidity for Challenged Claim 1 based on Walke as a
`Primary Reference ........................................................................... 41 
`Grounds of Invalidity for Challenged Claim 1 based on Kemp as a
`Primary Reference ........................................................................... 48 
`CONCLUSION ................................................................................... 55 
`
`
`
`C. 
`
`D. 
`
`VII. 
`
`
`ii
`
`

`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`
`I. MANDATORY NOTICES
`A. Real Parties-in-Interest
`Broadcom Corporation (“Petitioner”) is the real party-in-interest and submits
`
`this Petition for Inter Partes Review (“Petition”) to review Claim 1 of U.S. Patent
`
`No. 6,424,625 (“the ‘625 patent”) (Ex. 1001).
`
`B. Related Matters
`In September 2010, Ericsson Inc. et al. (the “Patent Owner”) filed suit in the
`
`Eastern District of Texas against D-Link Systems, Inc., Netgear, Inc., Belkin
`
`International, Inc., Dell, Inc., Toshiba Corporation, Acer Inc., and Gateway Inc.
`
`(the “Defendants”) alleging infringement of several U.S. patents, including the
`
`‘625 patent. (See Ericsson Inc., et al. v. D-LINK Corp., et al., Civil Action No.
`
`6:10-CV-473 (LED/KGF) (“Texas Litigation”)).1 The Patent Owner’s
`
`infringement allegations were based in part on Defendants’ use of Petitioner’s Wi-
`
`Fi compliant products, such as the BCM4313 and BCM4321. Following an eight
`
`day trial on five patents, the jury found Claim 1 of the ‘625 patent infringed.
`
`The Patent Owner did not allege that Petitioner infringed any patent asserted
`
`in the Texas Litigation, and Petitioner was not a party to the Texas Litigation. As a
`
`result, Petitioner has not had access to many documents in case, such as
`
`1
`On November 19, 2011, Intel Corporation filed a Motion to Intervene in the
`
`Texas Litigation, which the court granted on May 4, 2012.
`
`1
`
`

`
`
`depositions of inventors.
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`On September 20, 2013, Petitioner filed Petitions for Inter Partes Review
`
`for U.S. Patent Nos. 6,772,215 (IPR2013-00601) and 6,466,568 (IPR2013-00602).
`
`Because at least the IPR2013-00601 proceeding and this current Petition involve
`
`automatic repeat request (“ARQ”) technology, Petitioner respectfully requests
`
`consolidation of these actions.
`
`C. Counsel
`Lead Counsel: Dominic E. Massa (Registration No. 44,905)
`
`Backup Counsel: Michael A. Diener (Registration No. 37,122)
`
`Service Information
`
`D.
`Email: Michael A. Diener, michael.diener@wilmerhale.com
`
`Post and Hand Delivery: Wilmer Cutler Pickering Hale and Dorr, LLP, 60
`
`State St., Boston MA 02109
`
`Telephone: 617-526-6454
`
`
`
`Facsimile: 617-526-5000
`
`E. Certification of Grounds for Standing
`Petitioner certifies pursuant to Rule 42.104(a) that the patent for which
`
`review is sought is available for inter partes review and that Petitioner is not
`
`barred or estopped from requesting an inter partes review challenging the patent
`
`claims on the grounds identified in this Petition.
`
`
`
`2
`
`

`
`
`II. OVERVIEW OF CHALLENGE AND RELIEF REQUESTED
`Pursuant to Rules 42.22(a)(1) and 42.104 (b)(1)-(2), Petitioner challenges
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`Claim 1 of the ‘625 patent, (Ex. 1001) as either anticipated under 35 U.S.C. § 102
`
`or obvious under 35 U.S.C. § 103, in view of the references set out below.
`
`Prior Art Patents and Printed Publications
`
`A.
`Petitioner relies upon the following patents and printed publications to show
`
`that Claim 1 is anticipated and obvious, and therefore invalid:
`
`1.
`
`Garrabrant et al., U.S. Patent No. 5,610,595 (“Garrabrant”) (Ex.
`
`1002), which issued March 11, 1997, is prior art under (pre-AIA) 35 U.S.C. §
`
`102(b).
`
`2.
`
`Hettich, Development and performance evaluation of a Selective
`
`Repeat – Automatic Repeat Request (SR-ARQ) protocol for transparent, mobile
`
`ATM access,” 1996 (“Hettich”) (Ex. 1003), which published in 1996, is prior art
`
`under (pre-AIA) 35 U.S.C. § 102(b). A certified translation is provided as Exhibit
`
`1007.
`
`3. Walke, DE 19543280 (“Walke”) (Ex. 1004), which published on May
`
`22, 1997, is prior art under (pre-AIA) 35 U.S.C. § 102(b). A certified translation is
`
`provided as Exhibit 1008.
`
`4.
`
`Kemp, U.S. Patent No. 6,621,799 (“Kemp”) (Ex. 1005), which was
`
`filed on October 5, 1998, prior to the filing date of the ‘625 patent, and therefore is
`
`3
`
`

`
`
`prior art under (pre-AIA) 35 U.S.C. § 102(e).
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`5.
`
`Bertsekas, et al., DATA NETWORKS, Prentice-Hall, 1987, pp. 58-74
`
`“Bertsekas”) (Ex. 1012), which is prior art under (pre-AIA) 35 U.S.C. § 102(b).
`
`B. Grounds for Challenge
`Petitioner requests cancellation of Claim 1 as unpatentable under 35 U.S.C.
`
`§§ 102 and 103, as set out in the Grounds below:
`
`Ground 1: Challenged Claim 1 is Anticipated under 35 U.S.C. § 102 by
`
`Garrabrant (Figures 8A and 8B).
`
`Ground 2: Claim 1 is Anticipated under 35 U.S.C. § 102 by Garrabrant
`
`(Failure Recovery).
`
`Ground 3: Claim 1 is Anticipated under 35 U.S.C. § 102 by Hettich.
`
`Ground 4: Claim 1 Would Have Been Obvious Over Walke under 35
`
`U.S.C. § 103.
`
`Ground 5: Claim 1 is Anticipated under 35 U.S.C. § 102 by Kemp.
`
`Ground 6: Claim 1 Would Have Been Obvious Over Bertsekas and Go-
`
`Back-N Technology, in View of Walke and the Teaching to Discard Packets
`
`in an ARQ System under 35 U.S.C. § 103.
`
`This Petition, supported by the Declaration of Harry Bims, Ph.D (“Bims
`
`Declaration” or “Bims Decl.”) (Ex. 1006) filed with this Petition, demonstrates that
`
`there is a reasonable likelihood that Petitioner will prevail with respect to
`
`4
`
`

`
`
`Challenged Claim 1 and that the claim is unpatentable. See 35 U.S.C. § 314(a).
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`III. OVERVIEW OF THE ‘625 PATENT – TECHNICAL BACKGROUND
`A. Automatic Repeat Request Protocols
`Automatic repeat request (“ARQ”) refers to a class of protocols for packet
`
`data networks that allow a transmitter to retransmit packets that are not received or
`
`are incorrectly received by a receiver. (See, e.g., ‘625 patent, 1:34-37, Ex. 1001).
`
`These packets may also be referred to interchangeably as protocol data units
`
`(“PDUs”), cells, or frames.
`
`A receiver receives packets. In response to receipt of a packet, a receiver
`
`can transmit back to the transmitter a positive acknowledgement (“ACK” or
`
`“PACK”) that one or more data packets have been received, and/or a negative
`
`acknowledgement (“NAK” or “NACK”) indicating that one or more data packets
`
`have not been received. The transmitter can retransmit the packets if the
`
`transmitter has received a NACK, if the transmitter has not received a PACK (e.g.,
`
`because a timer in the transmitter times out), or if the transmitter’s transmit buffer
`
`fills up. (See, e.g., id. at 1:34-49 and 2:28-57, Ex. 1001).
`
`ARQ systems typically assign sequence numbers (“SNs”) to packets and use
`
`those SNs to identify and to track packets. (See, e.g., id. at 1:50-2:2, Ex. 1001).
`
`Sequence numbers can be re-used in a modulo manner, and thus can be represented
`
`as a circular buffer. The sequence numbers can be numbered, for example, 0, 1, 2,
`
`5
`
`

`
`
`… 29, 30, 31, 0, 1, 2, 3, …. Thus, a packet with SN=2 can be “higher” than a
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`packet with SN=28 if SN=2 is transmitted later in time. (See, e.g., id. at 7:10-16,
`
`Ex. 1001; see also Bims Decl. at ¶ 18, Ex. 1006).
`
`A basic type of ARQ system is referred to as a “stop-and-wait” system. In a
`
`stop-and-wait system, after the transmitter has transmitted a packet, the transmitter
`
`waits to transmit future packets until the current packet has been positively
`
`acknowledged. A series of alternating messages between the transmitter and
`
`receiver carries out this process. For example, one possible configuration of
`
`alternating messages between a transmitter and receiver could be: transmitter sends
`
`a packet with SN #1, receiver sends ACK #1 (acknowledging the successful receipt
`
`of packet #1), transmitter sends packet #2, receiver sends ACK #2, transmitter
`
`sends packet #3, receiver sends NACK #3 (negatively acknowledging packet #1 –
`
`indicating an unsuccessful receipt) or transmitter receivers no ACK or NACK
`
`within a given time, then transmitter retransmits packet #3. This configuration is
`
`illustrated below:
`
`Alternatively, rather than sending an ACK for a received packet, the receiver
`
`
`
`6
`
`

`
`
`can request a next packet by SN. This request acknowledged all packets with
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`lower SN. A stop-and-wait approach can be inefficient compared to other ARQ
`
`protocols because the time spent waiting for an ACK could be used more
`
`efficiently. (Id. at 1:23-33, Ex. 1001; see also Bertsekas, pp. 59-62, Ex. 1012).
`
`Another version of ARQ is called Go-Back-N. Go-Back-N protocols
`
`typically require each packet to be received in order. (Id. at 3:41-44, Ex. 1001; see
`
`also Bims Decl. at ¶ 19, Ex. 1006). In one type of Go-Back-N protocol, a series of
`
`packets are transmitted by the transmitter until the receiver sends a NACK. The
`
`transmitter has a transmit buffer that holds some number of packets until they are
`
`acknowledged. For example, the transmitter may send packets #1 through #20 as
`
`shown below:
`
`
`
`In the illustration above, the transmitter receives PACKs for packets #1
`
`through #13, but before the transmitter sends packet #21, it receives from the
`
`receiver a NACK for packet #14. The transmitter must then “go back 7” and
`
`retransmit packets starting with packet #14. This Go-Back-N protocol requires
`
`retransmitting packets #15 through #20, even though they had already been
`
`7
`
`

`
`
`correctly transmitted. Instead of individually sending PACKs for each positively
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`acknowledged packet, the receiver can send a PACK to cumulatively acknowledge
`
`all packets below a certain SN (in the above example, PACK #13 would positively
`
`acknowledge receipt of packets #1 through #13). By sending a NACK, the
`
`receiver is deemed to cumulatively acknowledge all packets with an SN below the
`
`NACK SN. In the above example, NACK #14 positively acknowledges receipt of
`
`packets #1 through #13 and negatively acknowledges packet #14. (Id. at 1:34-49
`
`and 2:3-27, Ex. 1001).
`
`In another example of a Go-Back-N implementation, the transmitter sends
`
`up to n-packets while it 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 transmitter sends packets #1
`
`through #20, 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, thus filling the transmit buffer. The transmitter
`
`then must “go back 7” and retransmit packets #14 through #20. (See, e.g.,
`
`Bertsekas, pp. 63-66, Ex. 1012).
`
`Another ARQ protocol is known as a selective reject (“SR”) system. In an
`
`SR ARQ system, the transmitter has a transmit window with a range of sequence
`
`8
`
`

`
`
`numbers it can send (based on the size of a transmit buffer), and the receiver has a
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`receive window with a range of sequence numbers it can receive (based on the size
`
`of a receive buffer). In a system that has 2k sequence numbers, the window size is
`
`often 2k-1, or one-half of the possible sequence numbers. (’625 Patent, 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. (See also Bims Decl. at ¶ 20, Ex.
`
`1006).
`
`Figures 7A and 7B of Garrabrant (Ex. 1002) describe an SR ARQ system.
`
`As shown below, the “valid window,” which has 16 entries (one-half of the 32
`
`possible sequence numbers) moves in a circular motion:
`
`Figures 7A and 7B, Garrabrant (Ex. 1002)
`
`
`
`Before packet #0 is sent (Figure 7A), the valid window includes #0 through
`
`#15. After packet #0 is sent and received, the valid window moves to #1 through
`
`9
`
`

`
`
`#16 (Figure 7B). (See Bims Decl. at ¶¶ 21 and 25, Ex. 1006).
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`If the transmitter in an SR ARQ system sends packets #1 though #20, but
`
`does not receive a PACK for packet #14 within a certain time (or receives a NACK
`
`for packet #14), the receiver would hold packets #15 through #20 in its receive
`
`buffer (if they had been correctly received), allowing the transmitter to retransmit
`
`only packet #14. Alternatively, if a transmitter receives a cumulative PACK for
`
`packets #1 through #13, but receives no PACK within a certain time for packet
`
`#14, the transmitter can resend packet #14 without receiving a specific request. If
`
`multiple packets are lost, a Go-Back-N system may require multiple
`
`retransmissions of correctly received packets, whereas an SR ARQ system can
`
`retransmit and receive only the lost packets by using out-of-order transmission and
`
`reception. (See, e.g., ‘625 patent, 2:58-3:45, Ex. 1001; see also Bims Decl. at ¶¶
`
`19-21, Ex. 1006).
`
`B. Alleged Invention of the ‘625 Patent
`According to the Background of the ‘625 patent, where packets are time-
`
`sensitive, such as in the transmission of speech or streaming video, the delay
`
`experienced by the receiver waiting for multiple rounds of NACKs and
`
`retransmissions may have more of a negative impact on application performance
`
`than the receiver simply discarding a missed packet and moving on to receive
`
`subsequent packets. (See, e.g., id. at 3:46-67, Ex. 1001; see also Bims Decl. at ¶
`
`10
`
`

`
`
`22, Ex. 1006).
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`According to the Background of the ‘625 patent, in an ARQ system the
`
`transmitter must have a method for determining the lifetime of a packet, and the
`
`receiver must have the ability to give up on receiving a packet that the transmitter
`
`has discarded. (Id. at 3:46-4:13, Ex. 1001). 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 speech or streaming video] ,
`
`and therefore fail to minimize bandwidth usage by not sending (or resending)
`
`significantly delayed or outdated data packets.” (See, e.g., ‘625 patent, 4:9-13, Ex.
`
`1001).
`
`The alleged invention of the ‘625 patent seeks to remedy this failing through
`
`the use of an “enforcement bit.” This bit causes a receiver to move its receive
`
`window forward to a new sequence number, and to “release any expectation of
`
`receiving outstanding packets” with lower sequence numbers. (See, e.g., id. at
`
`10:20-21, Ex. 1001; see also Bims Decl. at ¶ 24, Ex. 1006).
`
`In the example above where there was a NACK for packet #14, but packets
`
`#15 through #20 were correctly received, the transmitter may decide to discard
`
`packet #14 rather than to resend it. Using the alleged invention of the ‘625 patent,
`
`the transmitter could retransmit packet #15 with an enforcement bit set to TRUE.
`
`When the receiver receives this transmission, it moves the lower end of its receive
`
`11
`
`

`
`
`window from #14 to #15, thereby skipping packet #14. The receiver then forwards
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`packets #15 through #20 to other layers of the system, causing the lower end of its
`
`window to move to packet #21. (See, e.g., id. at 8:24-30, Ex. 1001; see also Bims
`
`Decl. at ¶ 25, Ex. 1006 ).
`
`Figure 10B of the ‘625 patent (below) illustrates an example of a window
`
`(W). (See, e.g., Bims Decl. at ¶ 27, Ex.1006).
`
`
`
`‘625 Patent, Figure 10B (Ex. 1001)
`
`In Figure 10B, DSN 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 packets,
`
`but the receiver has not yet been notified, then DSN < BSN, as shown above
`
`(where there are 3 discarded cells in window W). (See, e.g., id. at Figure 10B,
`
`5:65-6:9, Ex. 1001; see also Bims Decl. at ¶ 28, Ex. 1006).
`
`The receive window extends from sequence number DSN to TSNmax,
`
`12
`
`

`
`
`because it is still expecting to receive the packets between DSN and BSN. The
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`“actual buffer” in the transmitter extends from BSN to P, because it has discarded
`
`the packets between DSN and BSN. 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 window would have 16 spaces. (See, e.g., id. at
`
`5:58-63, 6:20-50, 7:42-47, Ex. 1001; see also Bims at ¶ 28, Ex. 1006).
`
`The receive window thus continues to hold spaces for the discarded packets
`
`between DSN and BSN, until the receiver is notified that those packets are being
`
`discarded. (See, e.g., Bims Decl. at ¶¶ 29-30, Ex. 1006). Because the receive
`
`window does not have room for the packets from TSN to PSN, the transmitter
`
`delays sending these packets. (See, e.g., Bims Decl. at ¶ 30, Ex. 1006).
`
`TSNmax designates the top of the window. (See, e.g., id. at 7:42-47, Ex.
`
`1001). The packets above TSNmax are packets that have been buffered and are
`
`ready to be transmitted, but are “not allowed to be transmitted.” (See, e.g., id. at
`
`6:56-60, Ex. 1001; see also Bims Decl. at ¶ 29, 1006). Because the receiver does
`
`not yet know that the packets between DSN and BSN have been discarded, the
`
`receiver is holding buffer space for them. Therefore, the receive window would
`
`extend from DSN to DSN + W. The transmitter holds packets greater than TSNmax
`
`in a buffer, because these packets are outside the receive window, and therefore
`
`cannot be accepted at the receiver. (See, e.g., id. at 7:26-33 and 11:38-48, Ex.
`
`13
`
`

`
`
`1001; see also Bims Decl. at ¶¶ 29-30, 1006).
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`The ‘625 patent identifies situations or rules for operation, referred to as
`
`“cases”, (Ex. 1001), which are essentially claimed in dependent Claims 6-13.
`
`(‘625 patent, 8:4-9:10, 11:23-12:64, Ex. 1001; see also Bims at ¶ 31, Ex. 1006).
`
`Dependent Claim 6 includes steps performed at the transmitter and the receiver,
`
`including the receiver accepting a packet if “enforcement bit” RBEP = TRUE, and
`
`if the packet is within a window. If the packet is not within the window, the
`
`receiver restarts or reports a failure. (Id. at 11:38-48, Ex. 1001; see also Bims
`
`Decl. at ¶ 33, Ex. 1006).
`
`In the “third case” identified in the ‘625 patent, 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 (see id. at FIG. 10B, “discarded cells”, Ex. 1001). As shown in FIG. 10B
`
`and as described in the ‘625 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.” (See, e.g., id. at 8:24-30, Ex. 1001).
`
`In this case, the first outstanding packet after BSN is retransmitted even
`
`though there is no indication that the transmitter had received a NACK for that
`
`packet. Also, this retransmitted packet is within the receive window and could
`
`14
`
`

`
`
`have been received and accepted by the received without RPEB = TRUE. (See
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`also Bims Decl. at ¶¶ 31-33, Ex. 1006).
`
`It is also true in the Go-Back-N embodiment and dependent Claim 4 that the
`
`receiver accepts a packet within a window N(S) < ESN+2k-1 and rejects if N(S)
`
`>= ESN+2k-1. (Id. at 10:52-61, Ex. 1001).
`
`IV. Claim Construction
`The claims in an inter partes review should be given their “broadest
`
`reasonable construction in light of the specification” as commonly understood by
`
`those of ordinary skill in the art.2
`
`A. Claim 1 of the ‘625 patent
`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
`
`
`2
`A person of ordinary skill in the art for the ‘625 patent would have 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. (See Bims Decl. at ¶ 16, Ex. 1006).
`
`15
`
`

`
`
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`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
`
`the transmitter discarding all packets for which
`acknowledgment has not been received, and which have
`sequence numbers prior to the at least one packet.
`
`Scope of the Claimed Method Performed by a Transmitter
`
`B.
`Claim 1 recites a method with steps that are performed by a transmitter.
`
`Claim 1 was amended to expressly recite that the functions were performed by the
`
`transmitter. In particular, in the single Office Action, the examiner rejected claim
`
`1 (and others) as unpatentable over Nakamura in view of Yoshioka. The examiner
`
`noted that Nakamura had a receiving station for discarding a packet that had not
`
`been acknowledged. The Patent Owner emphasized that Nakamura “fails to
`
`disclose or suggest a transmitter in the data network discarding at least one packet
`
`that has been sent by the transmitter.” (October 31, 2001 Amendment at p. 4, Ex.
`
`1013). The Patent Owner therefore amended Claim 1 to add the following
`
`underlined text: “a transmitter in the data network commanding a receiver in the
`
`16
`
`

`
`
`data network to …” and “the transmitter discarding all packets …” (Id. at p. 8, Ex.
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`1013).
`
`C. The Preamble Is Not Limiting
`The determination of whether a preamble limits a claim is made on a case-
`
`by-case basis in light of the facts in each case; there is no litmus test defining when
`
`a preamble limits the scope of a claim. Catalina Mktg. Int’l v. Coolsavings.com,
`
`Inc., 289 F.3d 801, 808 (Fed. Cir. 2002). “If the claim preamble, when read in the
`
`context of the entire claim, recites limitations of the claim, or, if the claim
`
`preamble is ‘necessary to give life, meaning, and vitality’ to the claim, then the
`
`claim preamble should be construed as if in the balance of the claim.” Pitney
`
`Bowes, Inc. v. Hewlett-Packard Co., 182 F.3d 1298, 1305 (Fed. Cir. 1999).
`
`The body of Claim 1 sets forth all of the limitations of the claimed invention.
`
`The preamble recites “A method for discarding packets in a data network
`
`employing a packet transfer protocol including an automatic repeat request
`
`scheme.” The terms “packet transfer protocol” and “automatic repeat request
`
`scheme” are not later referred to or necessary to understand the language in the
`
`body of Claim 1. Rather, the preamble merely states the purpose or intended use
`
`of the invention, rather than any distinct definition of any of the claimed
`
`invention’s limitations. Pitney Bowes, Inc. v. Hewlett-Packard Co., 182 F.3d
`
`17
`
`

`
`
`1298, 1305 (Fed. Cir. 1999) (explaining that if “the body of the claim fully and
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`intrinsically sets forth the complete invention, including all of its limitations, and
`
`the preamble offers no distinct definition of any of the claimed invention’s
`
`limitations, but rather merely states, for example, the purpose or intended use of
`
`the invention, then the preamble is of no significance to claim construction because
`
`it cannot be said to constitute or explain a claim limitation.”).
`
`Moreover, the Patent Owner did not use the preamble to distinguish over the
`
`prior art. See, e.g., Catalina Mktg., 289 F.3d at 808-09 (“[C]lear reliance on the
`
`preamble during prosecution to distinguish the claimed invention from the prior art
`
`transforms the preamble into a claim limitation because such reliance indicates use
`
`of the preamble to define, in part, the claimed invention.…Without such reliance,
`
`however, a preamble generally is not limiting when the claim body describes a
`
`structurally complete invention such that deletion of the preamble phrase does not
`
`affect the structure or steps of the claimed invention.”).
`
`In all grounds below, the prior art would anticipate or render obvious
`
`whether or not the preamble is a limitation of the claim.
`
`“Commanding”
`
`D.
` “Commanding” as used in the ‘625 patent should be given a plain and
`
`ordinary meaning of sending a command, which in communications is “an
`
`18
`
`

`
`
`instruction represented in a control field to cause an addressed device to
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`execute a specific control function.”
`
`This definition is consistent with the claims and specification of the ‘625
`
`patent, which describes the commanding step as being carried out by an
`
`enforcement bit that is separate from the sequence number. The abstract refers to
`
`the RBEP bit as “a bit [] set in the ARQ packet header.” (‘625 patent, Abstract, Ex.
`
`1001). Claim 3 of the ‘625 patent recites an enforcement bit as one example of
`
`the claimed “commanding” step.3
`
` In the Texas Litigation, the Patent Owner took an unduly broad view of the
`
`meaning of “command” as used in the claims of the ‘625 patent. For example, the
`
`Patent Owner asserted that the mere act of receiving a data packet is a command:
`
`
`3 This construction is also consistent with a definition from the IEEE
`
`dictionary from about 2000:
`
`command (1) (logical link control). In data communications, an
`instruction represented in the control field of a protocol data unit
`(PDU) and transmitted by a logical link control (LLC). It causes
`the addressed LLC9s) to execute a specific data link control
`function. (See, e.g., IEEE Dictionary, pp. 214-215, Ex. 1011).
`The proposed construction herein is not specific to an LLC layer. (See Bims Decl.
`
`at ¶¶ 36-37, Ex. 1006).
`
`19
`
`

`
`
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`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 Morning June 5, 2013 at p. 85:3-9, Ex. 1014).
`
`This broad reading of “commanding” is inconsistent with the plain and
`
`ordinary meaning of the term as used in the ‘625 patent. 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).
`
`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. Applying the Patent Owner’s logic, any data packet received by a receiver
`
`would be a command to receive. But the packet and its sequence number are
`
`simply data that the receiver uses; the packet is not an instruction to perform any
`
`control function. (Bims Decl. at ¶ 38, Ex. 1006). 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
`
`20
`
`

`
`
`the ‘625 patent is “an instruction represented in a control field to cause an
`
`U.S. Patent 6,424,625
`Petition for Inter Partes Review
`
`addressed device to execute a specific control function.” (Id., Ex. 1006).
`
`In all grounds below, the prior art would anticipate or render obvious under
`
`a construction that would include just packets as a command.
`
`“Commanding…to receive… and [to] release any expectations.”
`
`E.
`The claimed commanding steps are designed to cause the release of
`
`expectations, also referred to as the “transmitter resynchroniz[