UNITED STATES PATENT AND TRADEMARK OFFICE
`
`_________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_________________
`
`MICROSOFT CORPORATION,
`Petitioner,
`
`v.
`
`UNILOC 2017 LLC,
`Patent Owner.
`
`IPR2019-01026
`Patent 6,993,049
`
`
`_________________
`
`
`PETITIONER’S REPLY TO
`PATENT OWNER’S RESPONSE TO PETITION
`
`
`
`
`
`_________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_________________
`
`MICROSOFT CORPORATION,
`Petitioner,
`
`v.
`
`UNILOC 2017 LLC,
`Patent Owner.
`
`IPR2019-01026
`Patent 6,993,049
`
`
`_________________
`
`
`PETITIONER’S REPLY TO
`PATENT OWNER’S RESPONSE TO PETITION
`
`
`
`
`
`TABLE OF CONTENTS
`
`IPR2019-01026
`Patent 6,993,049
`
`Page(s)
`
`EXHIBIT LIST ........................................................................................................ iii
`
`I.
`
`INTRODUCTION ........................................................................................... 1
`
`II.
`
`CLAIM CONSTRUCTION ............................................................................ 1
`
`A.
`
`B.
`
`“Additional Data Field” ........................................................................ 1
`
`“Inquiry Message[s]” ............................................................................ 3
`
`III. GROUND 1: THE LARSSON-BASED
`COMBINATION SATISFIES THE CLAIMED “ADDING TO
`AN INQUIRY MESSAGE … AN ADDITIONAL DATA FIELD …” ......... 7
`
`A.
`
`Larsson’s Piggybacking Of RfR And Other
`Messages Satisfies The Claimed “Additional Data Field” ................... 7
`
`B.
`
`Larsson’s RFR Satisfies The Claimed Inquiry Message .................... 13
`
`1.
`
`Larsson’s RfR Messages Are Inquiry Messages;
`They Seek Route Information That Allows
`Unconnected Source And Destination Nodes
`To Establish Communications Paths ........................................ 14
`
`2.
`
`Larsson’s RfRs Satisfy PO’s More Narrow Construction ........ 14
`
`IV. GROUND 2: 802.11 SATISFIES THE
`“ADDING . . . AN ADDITIONAL DATA FIELD” LIMITATION ............ 16
`
`A.
`
`The Petition Consistently Relies
`On 802.11’s Targeted And Broadcast Probe Requests ....................... 17
`
`B.
`
`802.11 Discloses The “Additional Data Field” Element .................... 18
`
`V.
`
`CONCLUSION .............................................................................................. 23
`
`CERTIFICATE OF COMPLIANCE ....................................................................... 24
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page i
`
`
`
`TABLE OF AUTHORITIES
`
`IPR2019-01026
`Patent 6,993,049
`
`Page(s)
`
`Cases
`
`In re Anderson,
`662 F. App’x 958 (Fed. Cir. 2016) ......................................................................... 6
`
`Organic Seed Growers & Trade Ass’n v. Monsanto Co.,
`718 F.3d 1350 (Fed. Cir. 2013) .............................................................................. 4
`
`SunRace Roots Enter. Co. v. SRAM Corp.,
`336 F.3d 1298 (Fed. Cir. 2003) .............................................................................. 2
`
`Board Decisions
`
`Amneal Pharm. LLC v. Allergan, Inc.,
`IPR2018-00608, 2019 WL 4047036 (P.T.A.B. Aug. 27, 2019) ............................ 3
`
`Cisco Sys. Inc. v. Uniloc 2017 LLC,
`IPR2019-00965, Paper 7 (P.T.A.B. Nov. 8, 2019) ................................................ 3
`
`Microsoft Corp. v. Uniloc 2017 LLC,
`IPR2019-01188, Paper 9 (P.T.A.B. Dec. 9, 2019) ................................................. 2
`
`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page ii
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`EXHIBIT LIST
`
`LIST OF NEWLY-FILED EXHIBITS
`
`Exhibits concurrently filed with Petitioner’s Reply to Patent Owner’s Response to
`
`Petition:
`
`No.
`
`Description
`
`1028
`
`Second Declaration of Peter B. Rysavy, signed and dated May 19, 2020
`(“Rysavy_Reply”)
`
`1029 Modicon Modbus Protocol Reference Guide, PI-MBUS-300 Rev. J,
`June 1996 (“Modbus Protocol”)
`
`1030 U.S. Pat. No. 6,434,157 to Dube’ et al. (referencing Modbus Protocol)
`
`1031 ASN.1: Communication Between Heterogeneous Systems, Olivier
`Dubuisson, June 5, 2000, available at
`http://www.oss.com/asn1/resources/books-whitepapers-
`pubs/dubuisson-asn1-book.PDF from
`http://www.oss.com/asn1/resources/books-whitepapers-pubs/asn1-
`books.html (“Dubuisson”) (excerpts)
`
`1032 U.S. Pat. No. 6,687,766 to Casper
`
`1033 Uniloc USA, Inc. v. Samsung Elecs. Am. Inc., No. 2:18-cv-00040-JRG-
`RSP, Dkt. No. 69 (E.D. Tex. Feb. 26, 2019) (“Plaintiff’s Reply Claim
`Construction Brief”).
`
`1034 Qiu et al., A multiple access scheme for multimedia traffic in wireless
`ATM, IEEE/ACM Mobile Networks and Applications 1:259-272 (Jan.
`1996)
`
`1035 U.S. Pat. No. 6,205,498 to Habusha et al.
`
`1036 W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols,
`1994 (“Stevens”)
`
`1037 Webster’s New World Dictionary, 4th Edition, 1999 (“inquiry”)
`
`1038 U.S. Pat. No. 3,523,281 to Willcox et al.
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page iii
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`No.
`
`Description
`
`1039 U.S. Pat. No. 5,517,488 to Miyazaki et al.
`
`1040 U.S. Pat. No. 6,119,208 to White et al.
`
`1041 U.S. Pat. No. 6,141,701 to Whitney
`
`1042 U.S. Pat. No. 3,701,971 to Sanner et al.
`
`1043 U.S. Pat. No. 5,812,639 to Bartholomew et al.
`
`1044 David Johnson, David Maltz, Carnegie Mellon University, Dynamic
`Source Routing in Ad Hoc Wireless Networks, 1996,
`https://www.utdallas.edu/~ksarac/Papers/DSR.pdf
`
`1045 Global System for Mobile Communications (GSM) Technical
`Specification: Digital cellular telecommunications system (Phase 2+);
`Mobile radio interface layer 3 specification (GSM 04.08), available at
`https://www.etsi.org/deliver/etsi_gts/04/0408/05.00.00_60/gsmts_0408
`v050000p.pdf (excerpts)
`
`1046
`
`Federal Standard 1037C, Telecommunications: Glossary of
`Telecommunication Terms, U.S. Federal General Services
`Administration (Aug. 7, 1996)
`
`LIST OF PREVIOUSLY FILED EXHIBITS
`
`No. Description
`
`1001 U.S. Patent No. 6,993,049 (“the ’049 patent”)
`
`1002 File History of U.S. Patent No. 6,993,049
`
`1003 Declaration of Peter B. Rysavy, signed and dated May 6, 2019
`(“Rysavy Decl.” or “Rysavy”).
`
`1004 U.S. Pat. No. 6,704,293 to Larsson et al. (“Larsson”)
`
`1005 Specification of the Bluetooth System, Vol. 1, Bluetooth, v1.0B (Dec.
`1, 1999) (“Bluetooth Specification”)
`
`1006 David C. Plummer, An Ethernet Address Resolution Protocol, IETF
`Request For Comments No. 826 (Nov. 1982) (“RFC826”)
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page iv
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`No. Description
`
`1007 ANSI/IEEE Std 802.11, Part 11: Wireless LAN Medium Access Control
`(MAC) and Physical Layer (PHY) Specifications (Aug. 20, 1999)
`(“802.11”)
`
`1008 Uniloc USA Inc., et al. v. LG Electronics USA Inc., et al., Case 18-cv-
`06738-LHK, Dkt. No. 109, Amended Order Granting Motion to
`Dismiss (“Section 101 Order”)
`
`1009 Uniloc USA Inc., et al. v. LG Electronics USA Inc., et al., Case 18-cv-
`06738-LHK, Dkt. No. 110, Amended Judgment
`
`1010 Uniloc USA Inc., et al. v. LG Electronics USA Inc., et al., Case 18-cv-
`06738-LHK, Dkt. No. 111, Notice of Appeal
`
`1011 Case Timelines for U.S. Pat. No. 6,993,049, Docket Navigator
`(www.docketnavigator.com) (generated April 30, 2019)
`
`1012 Case List for U.S. Pat. No. 6,993,049, Docket Navigator
`(www.docketnavigator.com) (generated April 30, 2019)
`
`1013 U.S. Pat. No. 6,255,800 to Bork
`
`1014 U.S. Pat. No. 6,975,205 to French et al.
`
`1015 Form PTO-1449 and Associated Documents from File History For U.S.
`Pat. No. 5,907,540 (date-stamped December 19, 1995).
`
`1016 U.S. Pat. No. 5,907,540 to Hayashi
`
`1017 U.S. Pat. No. 6,058,421 to Fijolek et al.
`
`1018 U.S. Pat. No. 6,982,953 to Swales
`
`1019 S. Cheshire, IPv4 Address Conflict Detection, IETF Request For
`Comments No. 5227 (July 2008) (“RFC5227”)
`
`1020 Peter Rysavy, Wireless Wonders Coming Your Way, Network Magazine
`(May 2000).
`
`1021 Peter Rysavy / Rysavy Research, Wireless Data Networks, Cover
`Material For Course Delivered at WEB2000 (October 2000)
`
`1022 Peter Rysavy / Rysavy Research, Wireless Data Systems: Making Sense
`of Wireless, Cover Material For Course Taught at UCLA (2001)
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page v
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`No. Description
`
`1023 U.S. Pat. No. 6,683,886 to Tuijn
`
`1024 Press Release, The Official Bluetooth SIG Website, New revision of the
`Bluetooth 1.0 Specification released (1999-12-06), Web Archive
`capture dated May 17, 2000, available at
`https://web.archive.org/web/20000517192715/http://
`www.bluetooth.com/text/news/archive/archive.asp?news=2
`
`1025 The Official Bluetooth SIG Website, News Archive, Web Archive
`capture dated May 18, 2000, available at
`https://web.archive.org/web/20000518114920/http://www.
`bluetooth.com/text/news/archive/archive.asp?news=list
`
`1026 IEEE Standards Products Catalog: Wireless (802.11), Web Archive
`capture dated May 18, 2000, available at
`https://web.archive.org/web/20000324233339/http:/standards
`.ieee.org:80/catalog/IEEE802.11.html
`
`1027 Uniloc USA Inc., et al. v. Samsung Elecs. Am. Inc., et al., Case No.
`2:18-cv-00040-JRG-RSP, Dkt. No. 82 (April 5, 2019) (“Markman
`Order”)
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page vi
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`I.
`
`INTRODUCTION
`
`Petitioner submits this Reply to Patent Owner’s Response (Paper 9 (“POR”)).
`
`The POR presents no new evidence to undermine the Board’s Institution Decision
`
`finding a reasonable likelihood that the challenged claims are unpatentable. For the
`
`reasons discussed below and in the Petition (Paper 1), the Board should find the
`
`challenged claims unpatentable.
`
`II. CLAIM CONSTRUCTION
`
`A.
`
`“Additional Data Field”
`
`The POR contends that “additional data field” refers to “an extra data field
`
`appended to the end of an inquiry message.” POR, 7. This “appended to the end”
`
`proposal improperly imports a limitation from an embodiment where the “additional
`
`data field” happens to be added to the end of the inquiry message. Ex. 1001 (‘049
`
`patent), 5:6-8. PO argues that adding a data field “to the end of the inquiry message
`
`is an essential and defining aspect of the claimed invention” because it allows non-
`
`HID receivers to “ignore [the field] without modification.” POR, 7. But no evidence
`
`of record suggests that placing the data field at the end was an “essential” or
`
`“defining” aspect of the ’049 patent.
`
`The Figure 5 example cited by the POR is just that, a non-limiting example of
`
`one way in which the alleged invention might be implemented in a Bluetooth
`
`network. See ’049 patent, 3:22-27 (“In the following description we consider
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 1
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`particularly a system which utilises Bluetooth protocols …. [T]he general invention
`
`concept … is not restricted to Bluetooth devices.”). And that example occurs after
`
`the specification describes four other “aspects” of the alleged invention, each of
`
`which simply involves “adding” an additional data field or checking whether such a
`
`field has been “added,” without any mention of where it is added. ’049 patent, 2:28-
`
`32, 2:42-44, 2:51-54, and 2:64-3:3.
`
`Moreover, the applicant knew how to claim an “additional data field at the
`
`end” of a message, as shown in dependent claim 3, yet chose not to do so. Id. 7:50-
`
`52 (emphasis added). Construing “additional data field” to per se require an extra
`
`data field at the end, as proposed by PO, would render this other claim language
`
`superfluous and violate the doctrine of claim differentiation. SunRace Roots Enter.
`
`Co. v. SRAM Corp., 336 F.3d 1298, 1303 (Fed. Cir. 2003). Specifically, dependent
`
`claim 3 recites “adding the additional data field at the end of a respective inquiry
`
`message.” That claim depends from claim 2, which—similar to challenged claim
`
`11—recites “an additional data field for polling at least one secondary station.”1
`
`
`1 In a parallel proceeding involving similar claim language in a related patent, the
`
`Board at institution applied claim differentiation to reject a similar Uniloc argument.
`
`See Microsoft Corp. v. Uniloc 2017 LLC, IPR2019-01188, Paper 9, p. 13 (P.T.A.B.
`
`Dec. 9, 2019) (finding the claim language “strongly indicates that the additional data
`
`
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 2
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`B.
`
`“Inquiry Message[s]”
`
`PO argues that the claimed “inquiry message” should be limited to “a specific
`
`type of message used, at least in part, to discover other devices in the vicinity which
`
`may request to join a piconet.” POR, 8-9. This construction improperly seeks to
`
`import limitations from the Bluetooth embodiment discussed in the ’049 patent, even
`
`though the ’049 patent unequivocally states that the alleged invention “is not
`
`restricted to Bluetooth.” Ex. 1001, 3:22-28. In a district court case involving the ’049
`
`
`field … need not be added to the end of an inquiry message”) (emphasis original)
`
`(citations omitted). In that proceeding, based on arguments Cisco made in yet
`
`another IPR, the Board also determined that “for purposes of [institution]” “an
`
`additional data field is a data field that is not in the first communications protocol.”
`
`Id. (citing Cisco Sys. Inc. v. Uniloc 2017 LLC, IPR2019-00965, Paper 7 at 8-11
`
`(P.T.A.B. Nov. 8, 2019)). PO does not argue that this construction applies here, and
`
`nothing in the claims, patent, or file history would make that a proper construction
`
`for the ’049 patent. Moreover, Uniloc’s arguments for patentability do not rely on
`
`such a construction and, thus, such a construction is not at issue here. See, e.g.,
`
`Amneal Pharm. LLC v. Allergan, Inc., No. IPR2018-00608, 2019 WL 4047036, at
`
`*3 (P.T.A.B. Aug. 27, 2019) (“Only terms that are in controversy need to be
`
`construed, and then only to the extent necessary to resolve the controversy.”).
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 3
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`patent, PO itself argued—successfully—that a “piconet” limitation would unduly
`
`narrow the claims and that “inquiry message” should have its “ordinary meaning.”
`
`Ex. 1027, 16-17 (noting Uniloc argument that “[t]he proposed ‘piconet’ limitation is
`
`likewise improper as the piconet is a feature of the described Bluetooth embodiment
`
`but is not limiting of the invention” and construing “inquiry message” as a “message
`
`seeking a response to identify devices available for communication”); see also Ex.
`
`1033, 5 (arguing “inquiry message” should have its ordinary meaning and that “other
`
`systems could employ two or more stations that utilize the invention for transmitting
`
`information, but do not form a ‘piconet,’ a term used to describe only Bluetooth ad
`
`hoc networks”) (emphasis original). It is estopped from seeking a narrower
`
`construction here. Organic Seed Growers & Trade Ass’n v. Monsanto Co., 718 F.3d
`
`1350, 1358 (Fed. Cir. 2013).
`
`A POSITA reading the ’049 patent would have understood “inquiry message”
`
`to generally be “a query for information” or “a message seeking information”
`
`(Rysavy_Reply, ¶¶ 9-10) and, to the extent the term requires construction, it should
`
`be construed consistent with that understanding. PO’s contrary and unduly
`
`narrowing construction should be rejected as unsupported by the intrinsic evidence.
`
`First, the claims do not limit “inquiry message,” as proposed by PO. The
`
`applicant knew how to specify aspects of the claimed “inquiry message,” as reflected
`
`in claim 11 reciting that the message be “in the form of a plurality of predetermined
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 4
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`data fields arranged according to a first communications protocol.” Ex. 1001, 8:37-
`
`39. The claims do not, however, recite additional language that would limit the
`
`claimed “inquiry message” to the intended use proposed by PO.
`
`Second, the specification does not support imposing the limitation proposed
`
`by PO. As argued by Uniloc itself in district court litigation on the ’049 patent, there
`
`is neither an express definition of “inquiry message” nor an indication that the
`
`invention was so closely tied to Bluetooth inquiry messages so as to warrant limiting
`
`the claims to such messages. See Ex. 1033, 5-6. Although the ’049 patent describes
`
`using inquiry messages for specific purposes in some embodiments “when a
`
`Bluetooth unit wants to discover other Bluetooth devices” (see, e.g., Ex. 1001, 4:23-
`
`24), the ’049 patent does not limit inquiry messages to be used only for device
`
`discovery. And, because the ’049 patent neither provides a definition for the term
`
`“inquiry message,” nor disavows the use of inquiry messages beyond device
`
`discovery, Uniloc’s attempt to limit inquiry messages to device discovery—as in
`
`Bluetooth—is another attempt to improperly import limitations into the claims.
`
`The specification passages PO cites do not support narrowing the meaning of
`
`“inquiry message.” POR, 9. For example, the first passage (Ex. 1001 at 4:23-26)
`
`describes a specific task that a Bluetooth unit wants to perform, discovering other
`
`Bluetooth devices. But that function is not required by the claims. The second (1:56-
`
`57) and third (4:11-13) passages note that a Bluetooth inquiry procedure “allows a
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 5
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`would-be slave to find a base station ….” Again, they describe a specific
`
`implementation not required by the claims, which are not limited to Bluetooth
`
`implementations. Instead, the use of the word “inquiry” in those passages is
`
`consistent with the plain and ordinary meaning of “seeking information.”
`
`Rysavy_Reply, ¶ 13. No evidence indicates that the applicant acted as its own
`
`lexicographer or otherwise narrowed the scope of this term.
`
`The closest the specification comes to defining “inquiry message” is to recite
`
`that each “inquiry message” is “in the form of a plurality of predetermined data fields
`
`arranged according to a first communications protocol.” See Ex. 1001, 2:26-28,
`
`2:40-42, 2:62-64. This is consistent with claim 11, which itself specifically recites
`
`these same features. This language confirms that the named inventor knew how to
`
`claim optional features described in the specification, yet chose not to do so with
`
`respect to the intended purpose of the inquiry message.
`
`Third, PO’s proposed construction focuses on the intended use of “inquiry
`
`message” and thus even if adopted would lend no patentable weight to the claim. Cf.
`
`In re Anderson, 662 F. App’x 958, 963 (Fed. Cir. 2016) (non-precedential).
`
`Petitioner maintains
`
`that nothing more
`
`than a plain and ordinary
`
`understanding of “inquiry message” is needed to properly compare the prior art to
`
`the claims. Petition, 11. To the extent the Board finds it necessary to construe the
`
`intended use of this term, it should do so consistently with the unrebutted testimony
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 6
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`of Mr. Rysavy that POSITAs understood “inquiry message” as “a query for
`
`information” or “a message seeking information.” Rysavy_Reply ¶¶ 9-14.
`
`III. GROUND 1: THE LARSSON-BASED
`COMBINATION SATISFIES THE CLAIMED “ADDING TO
`AN INQUIRY MESSAGE … AN ADDITIONAL DATA FIELD …”
`
`The POR makes only two Ground 1 arguments. Each relates to the Element
`
`11.4 claim language “adding to an inquiry message prior to transmission an
`
`additional data field” (POR, Section V.B. Header), and the POR does not dispute
`
`that the Petition shows how the Ground 1 challenge satisfies every other claim
`
`element. The POR argues first, that Larsson’s “piggybacking” of an additional
`
`Address Resolution Protocol (“ARP”) message or other message does not satisfy the
`
`claimed “additional data field.” POR, 9-10 and 12-17. Second, it argues that
`
`Larsson’s Request for Route (“RfR”) messages do not satisfy the claimed “inquiry
`
`messages.” Id., 11-12. Each POR argument is wrong, as is now explained.
`
`A. Larsson’s Piggybacking Of RfR And Other
`Messages Satisfies The Claimed “Additional Data Field”
`
`The thrust of PO’s “additional data field” argument appears to be that Larsson
`
`only discloses piggybacking data as opposed to the claimed “data field.” E.g., POR,
`
`13 (“There is no indication that Larsson’s ‘piggyback data’ is anything other than
`
`merely more data, as opposed to the additional data field required by the claim
`
`language.”). This incorrect argument overlooks the Petition’s showing of how
`
`Larsson piggybacks additional messages (such as ARP messages) onto the RfR
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 7
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`messages, thus satisfying the claimed “additional data field.” These ARP messages
`
`occupy a field beyond the standard RfR fields, and contain numerous data fields used
`
`as part of the ARP protocol. Thus, the piggybacking, i.e., addition of these ARP
`
`messages satisfies the claimed “additional data field.” Rysavy_Reply ¶¶ 16-17. As
`
`the Board recognized in the Institution Decision, “Larsson discloses more than just
`
`additional data,” and Larsson’s disclosure of piggybacking broadcast messages
`
`“parallels closely the ’049 patent’s description of adding a data field.” Decision, 8.
`
`The Petition explained how Larsson discloses piggybacking other broadcast
`
`messages, such as ARP messages, onto an RfR message, thus satisfying the
`
`“additional data field” claim language. Petition, 32. It further explained how Larsson
`
`confirmed that the piggybacked data fields of these other messages were
`
`“additional” because they were “longer than the normal fixed length” of the RfR
`
`message. Id., 33.
`
`In mapping Element 11.4, the Petition also explained in more detail the
`
`piggybacked ARP messages. Id., 34. In this vein, it explained how RFC826 was the
`
`“internet standard” on ARP messages, and that “a POSITA would have naturally
`
`turned to RFC826 to ensure proper implementation of ARP messages” in the Larsson
`
`system. Id. Notably, the Petition pointed to an “example of ARP packet creation” on
`
`pages 7-8 of RFC826. Petition, 34-35 (citing Ex. 1006, 7-8). The POR disputes none
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 8
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`of these teachings or that a POSITA would have been motivated to employ them in
`
`implementing the Larsson system.
`
`Like nearly all communications messages, the piggybacked ARP messages
`
`contain numerous data fields. RFC826 describes these data fields, including the
`
`“type field,” “ar$hrd field,” and “Ethernet address field (ar$sha)” discussed in the
`
`portions of RFC826 cited by the Petition in explaining inter alia ARP message
`
`creation (also known as “packet generation”). E.g., RFC826, 3-4, 8 (noting ARP
`
`message with a “type field of ether_type$ADDRESS_RESOLUTION” and “ar$hrd
`
`field”); Rysavy_Reply ¶ 29 (emphasis added). As noted by the Petition, the ARP
`
`messages are the ADDRESS RESOLUTION packets in RFC826, which contain the
`
`Internet address of the destination node. Petition, 34; RFC826, 8 (explaining ARP
`
`message example in which a device “swaps fields, putting EA(Y) in the new sender
`
`Ethernet address field (ar$sha) …”) (emphasis added) (cited by Petition, 34-35).
`
`RFC826 also specifies the “Packet format” for ARP messages, which includes
`
`numerous fields of various lengths, including 48-bit fields for the destination and
`
`sender “Ethernet Address,” and a 16-bit “opcode” field:
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 9
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`
`
`Rysavy_Reply, ¶ 30; RFC826, 3; see also id., 5 (discussing ar$hrd, ar$hln, ar$pro,
`
`and Ethernet type fields); id. (explaining how ARP message packet buffers may be
`
`“reused” for a reply message because “a reply has the same length as a request, and
`
`several of the fields are the same”) (emphasis added); Rysavy_Reply, ¶¶ 31-32;
`
`Stevens, 56-57. To dispel any doubt, the Stevens textbook clearly describes the
`
`various ARP message fields and depicts their format in Figure 4.3:
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 10
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`
`
`Stevens, 56-57; Rysavy_Reply, ¶ 34.
`
`Piggybacking (i.e., adding) ARP messages on the RfR messages constitutes
`
`the addition of data fields, at least because the ARP data fields are not defined by
`
`the underlying protocol and thus not ordinarily included in the RfR messages.
`
`Rysavy_Reply, ¶¶ 35-36. Thus, the piggybacking of ARP messages satisfies the
`
`claimed “adding … additional data fields.” Rysavy_Reply, ¶ 15.
`
`Larsson’s length indicator also confirms that there is an additional data field
`
`being added. See Larsson 7:58-61 (“[I]n a protocol where the request for route
`
`message is of a fixed length, a length indicator which indicates a length longer than
`
`the normal fixed length will implicitly indicate that the request contains piggyback
`
`data.”); Rysavy_Reply, ¶ 16. PO argues that adding data does not necessarily mean
`
`that there is an additional data field. POR, 12-13. That is wrong because Larsson’s
`
`description of a “normal fixed length” RfR message means that the message is of
`
`fixed length, so any added piggybacked message would increase the length and
`
`occupy an additional field. Rysavy_Reply, ¶ 17. Thus, it is impossible for the
`
`existing fields to carry more data, because the message would no longer be of the
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 11
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`fixed length. Hence, the presence of the length indicator in Larsson confirms the
`
`additional data fields in the piggybacked ARP (and other) messages.
`
`Rysavy_Reply, ¶ 18.
`
`The POR also incorrectly argues that the Petition provides no evidence as to
`
`how Larsson’s piggybacking disclosure relates to the ’049 patent’s piggy-back
`
`disclosure. POR, 14. The Petition does rely on evidence, namely the Larsson
`
`disclosure as well as the unrebutted testimony of Mr. Rysavy.
`
`The ’049 patent refers to “piggy-back” in the context of a sending device
`
`adding “an additional data field” to the predetermined data fields of a message.
`
`The Bluetooth inquiry procedure allows a would-be slave
`101 to find a base station and issue a request to join its
`piconet. It has been proposed specifically to overcome
`problems caused by the frequency-hopping nature of
`Bluetooth and similar systems. The applicants have
`recognised that it is possible to piggy-back a broadcast
`channel on the inquiry messages issued by the master 100.
`
`
`
`Ex. 1001, 4:11–18. This passage is consistent with Larsson’s disclosure of
`
`“piggybacking” additional broadcast messages (adding additional data fields
`
`carrying broadcast message data) onto an RfR message: “the source node
`
`piggybacks the broadcast message in a request for route broadcast message.”
`
`Larsson, 6:5-7, Fig. 6a, Fig. 7a, 7:50-53; Rysavy, ¶ 74. Indeed, Larsson cites the
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 12
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`Stevens treatise on TCP/IP, which confirms how a POSITA would understand the
`
`use of “piggybacking” in Larsson. Rysavy_Reply, ¶ 21; see also id. ¶¶ 22-24.
`
`Larsson discloses this feature even under PO’s construction of “additional
`
`data field” that requires such data fields to be at the end of inquiry message[s].” See
`
`POR, 16-17. Larsson describes its additional data fields being “piggybacked” onto
`
`RfR messages. E.g., Larsson, 6:3-11, 6:45-63, Fig. 6. A POSITA would have
`
`understood the end of the RfR message to be the most logical place to add, or
`
`“piggyback,” the additional data. See Rysavy_Reply, ¶ 20; Ex. 1034, 262 (“We
`
`append a piggyback field to the end of each packet.”) (emphasis added); Ex. 1035,
`
`8:46-51 (describing piggybacking onto a message packet as “includ[ing] an optional
`
`Session Acknowledgment section 162” at the end of a user message packet 160); see
`
`also id., Fig. 7.
`
`B.
`
`Larsson’s RFR Satisfies The Claimed Inquiry Message
`
`PO’s second argument hinges on its unduly narrow construction of the
`
`claimed “inquiry message” as “as a specific type of message used, at least in part, to
`
`discover other devices in the vicinity which may request to join a piconet.” POR, 8-
`
`9, 11. Absent its improperly narrowing claim construction, PO does not dispute that
`
`Larsson’s route discovery messages (RfRs) satisfies the claim. Moreover, even
`
`under PO’s more narrow reading, Larsson satisfies the claims.
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 13
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`1.
`
`Larsson’s RfR Messages Are Inquiry
`Messages; They Seek Route Information
`That Allows Unconnected Source And
`Destination Nodes To Establish Communications Paths
`
`As explained in the Petition, Larsson’s “request for route” messages (also
`
`referred to herein and in the Petition as “RfR messages”) satisfy the claimed “inquiry
`
`message.” Petition, 26-28. These RfR messages are broadcast by a source node in
`
`order to establish communication routes to destination nodes. Petition, 27 (citing
`
`Larsson, 2:66-3:2). Using these RfR messages, a node can “establish … routes to the
`
`various nodes in the network” and also “re-establish routes” when a route between
`
`two nodes is “broken.” Petition, 27-28 (citing Larsson, Fig. 3 and 3:12-29). For
`
`example, if a source node cannot communicate with a destination node, e.g., because
`
`the “route to the destination node is not known, … then the source node broadcasts
`
`a request for route message.” Larsson, 2:66-3:2 (quoted by Petition, 28). This allows
`
`the source node to “begin[] sending data over the new route.” Larsson, 8:33-41
`
`(quoted by Petition, 28). Thus, under the ordinary meaning of “inquiry message” as
`
`a query for information or message seeking information, Larsson satisfies the claim.
`
`Petition, 26-28; Rysavy_Reply, ¶ 25. The POR does not dispute this.
`
`2.
`
`Larsson’s RfRs Satisfy
`PO’s More Narrow Construction
`
`The POR argues that “Larsson is directed to discovering a route to a known
`
`recipient device already joined to a piconet, as opposed to discovering recipient
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 14
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`devices that may seek to join.” POR, 11. This argument fails for at least two reasons.
`
`First, as discussed above, it relies on an unduly narrow claim construction that PO
`
`itself has argued against. Supra Section II.B. Second, it is wrong because it ignores
`
`that Larsson’s RfR messages are in fact used to join two unconnected devices
`
`together for communication, thus enabling communications at a higher protocol
`
`layer such as the Internet protocol. Rysavy_Reply, ¶ 26.
`
`The RfR messages in Larsson are used to both “newly establish[]” network
`
`routes between different devices and also re-establish “broken” routes so that the
`
`devices can “begin[] sending data over the new route.” Petition, 27-28 (citing
`
`Larsson, Fig. 5, 2:66-3:2 3:12-29, and 8:33-41; Rysavy, ¶¶ 64-67). Before a source
`
`node sends RfR messages and receives a “route response message” from a
`
`destination node, the two devices cannot communicate because they are not joined
`
`to the same network. E.g., Larsson, 3:64-68 (“[I]n an ad-hoc network the source
`
`node may have to perform [inter alia] route discovery before the source node can
`
`begin to transmit data to the destination node.”); see also id. 1:33-37 (“[A]d-hoc
`
`networking protocols are based upon the assumption that nodes may not always be
`
`located at the same physical location. Bluetooth is an exemplary ad-hoc networking
`
`technology.”); id., 3:41-45 (“In order to transmit data from a source node to a
`
`destination node the source node may first obtain its own network address, resolve
`
`the name of the destination, obtain the hardware address of the destination node and
`
`Petitioner’s Reply to Patent Owner’s Response to Petition
`
`Page 15
`
`
`
`IPR2019-01026
`Patent 6,993,049
`
`determine a route to the destination node.”); 4:27-32 and 4:37-43; Rysavy_Reply,
`
`¶ 27.
`
`Thus, counter to PO’s arguments, the RfR messages in Larsson are indeed
`
`seeking to discover recipient (or destination) devices in order to join the two devices
`
`in network communication. Accordingly, even under the POR’s ambiguous and
`
`overly limiting proposed construction for “inquiry message,” Larsson satisfies the
`
`claim element.
`
`The source node in Larsson is also seeking to identify nodes along the path to
`
`the destination node, so that it can communicate messa
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
