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