`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`APPLE INC.
`Petitioner
`
`v.
`
`UNILOC USA, INC. and UNILOC LUXEMBOURG, S.A.
`Patent Owner
`
`Patent 6,993,049
`
`DECLARATION OF DR. CHARLES D. KNUTSON
`IN SUPPORT OF THE PETITIONER’S REPLY
`
`1
`
`Exhibit 1035
`Apple, et al. v. Uniloc
`IPR2019-00251
`
`
`
`Proceeding No.: IPR2019-00251
`
`
`TABLE OF CONTENTS
`
`
`I.
`II.
`
`INTRODUCTION ........................................................................................... 1
`CLAIM CONSTRUCTION ............................................................................ 2
`A.
`“additional data field” ........................................................................... 2
`B.
`“broadcasting” ....................................................................................... 3
`C.
`“inquiry message” ................................................................................. 7
`III. UNILOC MISCHARACTERIZES OR MISUNDERSTANDS THE
`TEACHINGS OF LARSSON AND IROBEX ............................................. 11
`A.
`Larsson's broadcast message for route discovery is an
`inquiry message ................................................................................... 11
`Larsson discloses adding an additional data field to its
`inquiry message ................................................................................... 13
`IrOBEX discloses "the method comprising the primary
`station broadcasting a series of inquiry messages" ............................. 17
`IrOBEX was publicly available before June 26, 2000 ........................ 20
`D.
`IV. CONCLUSION .............................................................................................. 22
`
`B.
`
`C.
`
`
`
`
`
`
`
`i
`
`2
`
`
`
`Proceeding No.: IPR2019-00251
`
`
`DECLARATION EXHIBITS
`
`APPLE-1001
`
`U.S. Patent No. 6,993,049 to Davies (“’049 Patent”)
`
`APPLE-1002
`
`Prosecution History of the ’049 Patent (“the Prosecution
`History”)
`
`APPLE-1003
`
`Declaration of Dr. Charles Knutson
`
`APPLE-1004
`
`Curriculum Vitae of Dr. Charles Knutson
`
`APPLE-1005 U.S. Patent No. 6,704,293 (“Larsson”)
`
`APPLE-1006 IrDA Object Exchange Protocol (“IrOBEX”)
`
`APPLE-1007 Prosecution History of the 7,587,207 Patent (“207 Prosecution
`History”)
`
`APPLE-1008 Second Declaration of Dr. Charles Knutson
`
`APPLE-1009 U.S. Patent No. 7,587,207 (“Davies” or the “’207 Patent”)
`
`APPLE-1010 U.S. Patent No. 6,570,857 (“Haartsen”)
`
`APPLE-1011 U.S. Patent No. 6,480,505 (“Johansson”)
`
`APPLE-1012
`
`APPLE-1013
`
`APPLE-1014
`
`APPLE-1015
`
`
`
`Specification of the Bluetooth System: Wireless connections
`made easy, Profiles, Vol. 2, Bluetooth, Dec. 1, 1999 (“BT
`Profiles”)
`The New Shorter Oxford English Dictionary on Historical
`Principles, Vol. 1, Clarendon Press, 1993 (“Oxford
`Dictionary”)
`Specification of the Bluetooth System: Wireless connections
`made easy, Core, Vol. 1, Bluetooth, Dec. 1, 1999 (“BT Core”)
`U.S. Patent No. 6,683,886 (“Tuijn”)
`
`ii
`
`3
`
`
`
`Proceeding No.: IPR2019-00251
`
`
`APPLE-1016 Internet Archive Capture of
`http://www.bluetooth.com:80/developer/specification/specificat
`ion.asp from March 1, 2000
`APPLE-1017 Internet Archive Capture of
`http://www.bluetooth.com:80/developer/specification/core.asp
`from March 1, 2000
`APPLE-1018 Internet Archive Capture of
`http://www.bluetooth.com:80/developer/specification/order.asp
`from March 1, 2000
`APPLE-1019 Internet Archive Capture of
`http://www.bluetooth.com:80/news/archive/archive.asp from
`March 4, 2000
`Declaration of Michael Foley
`
`APPLE-1020
`
`APPLE-1021
`
`APPLE-1022
`
`APPLE-1023
`
`APPLE-1024
`
`The Concise Oxford English Dictionary, 5th Ed., Oxford
`University Press, 1964 (“Concise Oxford English Dictionary”)
`Amended Complaint dated May 30, 2018, Uniloc USA v Apple
`Inc., Civil Action No. 1:18-cv-00164-LY, Western District of
`Texas, Austin Division (“Complaint”)
`McGraw-Hill Dictionary of Electrical and Computer
`Engineering, ISBN 0-07-144210-3, 2004
`Internet Archive Capture of
`https://web.archive.org/web/20000618190007/http://www.bluet
`ooth.com/text/news/archive/archive.asp?news=2 from June 18,
`2000
`APPLE-1025 U.S. Patent No. 6,622,018 (“Erekson”)
`
`APPLE-1026 PCT Patent Application Publication No. WO 00/76238
`(“Buttery”)
`U.S. Patent No. 6,922,548 (“Moore”)
`U.S. Patent No. 6,799,318 (“Davison”)
`U.S. Patent No. 6,779,185 (“Roukbi”)
`iii
`
`APPLE-1027
`APPLE-1028
`APPLE-1029
`
`
`
`4
`
`
`
`Proceeding No.: IPR2019-00251
`
`
`APPLE-1030
`APPLE-1031
`APPLE-1032
`APPLE-1033
`APPLE-1034
`APPLE-1035
`APPLE-1036
`
`APPLE-1038
`
`APPLE-1039
`
`U.S. Patent No. 6,982,962 (“Lunsford”)
`U.S. Patent No. 6,255,800 (“Bork”)
`U.S. Patent No. 6,975,205 (“French”)
`Declaration of Mr. Peter Rysavy
`Declaration of Mr. Lawrence Faulkner
`Declaration of Dr. Charles Knutson
`“Wireless Wonders Coming Your Way” by Peter Rysavy,
`https://rysavyresearch.files.wordpress.com/2017/08/2000_05_w
`ireless_wonders.pdf, last accessed on January 8, 2020.
`APPLE-1037 Internet Archive Capture of
`https://web.archive.org/web/20000517192715/http://www.bluet
`ooth.com/text/news/archive/archive.asp?news=2, last accessed
`on January 8, 2020.
`Internet Archive Capture of
`https://web.archive.org/web/20000518114920/http://www.bluet
`ooth.com/text/news/archive/archive.asp?news=list, last
`accessed on January 8, 2020.
`Oregon State University Open Source Lab Webpage,
`http://netwinder.osuosl.org/pub/netwinder/docs/nw/irda/, last
`visited January 8, 2020.
`Stuart Williams, IrDA: Past, Present and Future, IEEE Personal
`Communications, Vol. 7, Issue 1, 11-19, Feb. 2000
`The IrDA Standards for High-Speed Infrared Communications,
`The Hewlett-Packard Journal, February, 1998.
`
`APPLE-1040
`
`APPLE-1041
`
`
`
`
`
`iv
`
`5
`
`
`
`Proceeding No.: IPR2019-00251
`
`
`I, Charles D. Knutson, hereby declare the following:
`
`I.
`
`INTRODUCTION
`1.
`I have been retained by Fish & Richardson P.C., counsel for Apple Inc.
`
`(“Apple” or “Petitioner”), to analyze certain issues relating to the validity of certain
`
`claims of U.S. Patent No. 6,993,049 (“’049 Patent”). I previously provided
`
`declarations in support of the IPR Petition in these proceedings, and am now
`
`executing this additional declaration in support of the Petitioner’s Reply.
`
`2.
`
`In forming the opinions I have expressed in this declaration, I have
`
`reviewed the ’049 patent, its file history, and any documents cited or listed in this
`
`declaration. Furthermore, my opinions are also based on my experience and
`
`knowledge (as detailed further below). My compensation is not contingent upon the
`
`outcome of this matter.
`
`3.
`
`It is my understanding that, in response to the Petition, UNILOC
`
`submitted a preliminary response (POPR) and a subsequent Patent Owner response
`
`(“POR”/Paper 11) arguing that 1) the Petitioners did not properly establish BT Core
`
`or IrOBEX as valid prior art references; and 2) Larsson and IrOBEX, considered
`
`individually, do not disclose or render obvious each element of claims 11 and/or 12.
`
`As I explain in more detail below, Patent Owner is incorrect.
`
`
`
`1
`
`6
`
`
`
`Proceeding No.: IPR2019-00251
`
`
`II. CLAIM CONSTRUCTION
`A. “additional data field”
`In the POR, UNILOC contends that an “additional data field” should
`
`4.
`
`be construed as “an extra data field appended to the end of an inquiry message.”
`
`POR, 13, 8. UNILOC proposed this new construction after its previous construction
`
`(“an extra data field appended to an inquiry message”) failed to provide a
`
`distinguishing feature over Larsson or IrOBEX. POPR, 8.
`
`5.
`
`However, in my opinion, UNILOC’s new construction is incorrect and
`
`significantly more problematic than its originally-proposed construction. In
`
`particular, UNILOC’s new construction adds a requirement that “an extra data field”
`
`be appended only “to the end” of an inquiry message. However, the notion of an
`
`“additional data field” carries no requirement or connotation that such a field must
`
`only be appended to the end of an inquiry message. As I explain in the subsequent
`
`paragraphs, a POSITA would understand that, in the context of the ’049 Patent, an
`
`“additional data field” can be added to any portion of the inqury message.
`
`6.
`
`To support its construction, UNILOC relies on the disclosure in FIG. 5
`
`of the ’049 Patent and its corresponding description in the specification. POR, 13-
`
`15. However, the ’049 Patent very clearly states that FIG. 5 depicts examples of
`
`“embodiments of the present invention.” Ex.1001, 3:5-17. In contrast to UNILOC’s
`
`
`
`2
`
`7
`
`
`
`Proceeding No.: IPR2019-00251
`
`assertions, I find no disclosure in the ’049 Patent that would require an “additional
`
`data field” to be located at the end of an inquiry message.
`
`7.
`
`In my opinion, a POSITA would construe an “additional data field”
`
`consistent with its ordinary meaning. That is, an “additional data field” is simply an
`
`data field that is added, or supplemental. Ex. 1021, 16. Such an understanding of
`
`“additional data field” is consistent with the disclosure in the ’049 Patent as well as
`
`secondary references such as dictionaries. Ex.1001, 2:28-33, 2:42-45, 2:50-55, 2:64-
`
`3:2, 4:59-5:15; 6:16-24. For example, I have also not come across any definition of
`
`“additional” (or “additional data field”) that would limit the location of the additional
`
`data field to the end of a message.
`
`8.
`
`Based on the foregoing, it is my opinion that UNILOC’s construction
`
`should be rejected. Instead, the Board should simply apply the ordinary meaning of
`
`“additional data field” when construing this term.
`
`B. “broadcasting”
`In the POR, UNILOC contends that “broadcasting” should be construed
`
`9.
`
`as “a transmission that is receivable by multiple recipients.” POR, 17. Consistent
`
`with its proposed construction for “additional data field,” UNILOC again appears to
`
`have proposed a new construction with imported limitations after its previous
`
`construction (“one message that is distributed to all stations”) failed to provide
`
`
`
`3
`
`8
`
`
`
`Proceeding No.: IPR2019-00251
`
`UNILOC a distinguishing feature over Larsson or IrOBEX. POPR, 11. For the
`
`reasons I provide below, UNILOC’s modified construction is wrong.
`
`10. First, UNILOC’s construction is inconsistent with the claim language.
`
`In particular, claim 11 recites “a communication system comprising a primary
`
`station and at least one secondary station … the primary station broadcasting a series
`
`of inquiry messages.” I interpret “at least one secondary station” as one or more
`
`secondary stations. As such, claim 11 can be satisfied through a communication
`
`between one primary station and one secondary station. By limiting broadcasting to
`
`being “receivable by multiple recipients,” UNILOC’s construction improperly
`
`removes the possibility of a single secondary station receiving a broadcast inquiry
`
`message from a primary station even though the claim clearly contemplates such a
`
`scenario through the recitation of “at least one.”
`
`11. Second, UNILOC’s construction is inconsistent with the ’049 Patent
`
`specification. The ’049 Patent’s FIG. 1 (reproduced below) shows two master
`
`stations 100. Master Station 100(A) is a master of a first piconet 102a, which is a
`
`point-to-multipoint network, and Master Station 100(B) is a master of a second
`
`piconet 102b, which is a point-to-point network. Ex.1001, 3:30-56.
`
`
`
`
`
`4
`
`9
`
`
`
`Proceeding No.: IPR2019-00251
`
`
`Ex.1001, FIG. 1
`
`
`
`12.
`
`In describing the operations of a master broadcasting inquiry messages
`
`to other stations, the ’049 Patent refers generally to “master 100” when describing
`
`broadcasting operations that could be performed by either Master Station 100(A) or
`
`Master Station 100(B). Ex.1001, 3:57-4:58. In my opinion, a POSITA would have
`
`understood, from the ’049 Patent, that Master Station 100(B) broadcasts an inquiry
`
`message to a single recipient in a point-to-point communication. Indeed, a single
`
`recipient, such as slave device 101 (B1), may sufficiently manifest the behavior
`
`described in claim 11. Thus, per the disclosure in the ’049 Patent, the inquiry
`
`message does not have to be broadcast to or receivable by multiple recipients. In
`
`
`
`5
`
`10
`
`
`
`Proceeding No.: IPR2019-00251
`
`fact, nothing in the ’049 Patent suggests that broadcasting is limited to a point-to-
`
`multipoint communication. Thus, UNILOC’s attempt to limit broadcasting to “a
`
`transmission that is receivable by multiple recipients” lacks support in the ’049
`
`Patent.
`
`13. Third, by modifying its construction to include the phrase “receivable
`
`by multiple recipients,” UNILOC appears to be redefining broadcasting as an
`
`operation related to how a message is received rather than how a message is
`
`transmitted. In my experience, it is incorrect to limit broadcasting to a transmission
`
`that is receivable by multiple recipients. Indeed, even a message that is addressed
`
`to or intended for a single recipient can be intercepted and may therefore be
`
`“receivable by multiple recipients.” In reality, almost any transmission is receivable
`
`by multiple recipients. Indeed, in networked systems that utilize or rely on message
`
`forwarding, messages of every type and configuration are received (and
`
`subsequently retransmitted) by multiple recipients as they travel from a sender to
`
`one or more endpoints. UNILOC’s construction is so broad that literally any
`
`message of any type would meet UNILOC’s definition of “broadcasting.” Such a
`
`construction therefore fails to impart any meaningful scope at all to the term
`
`“broadcasting.”
`
`14.
`
`In contrast, it is well understood in the art that a message can be
`
`broadcast even if it is not received by a device. Further, a broadcast message can be
`
`
`
`6
`
`11
`
`
`
`Proceeding No.: IPR2019-00251
`
`received by one or more devices. For instance, messages that are broadcast into
`
`space do not have to be receivable by multiple recipients – a single recipient is
`
`sufficient – the message is broadcast by the sender, irrespective of whether it is
`
`receivable by multiple recipients. Within the context of Bluetooth, a device may
`
`broadcast inquiry messages even if no other device is close enough to receive the
`
`messages. The broadcast is the same whether or not a device receives the inquiry
`
`message, one device receives the inquiry message, or multiple devices receive the
`
`inquiry message. My understanding of broadcasting is corroborated by the ’049
`
`Patent’s FIG. 1, which, as explained above, depicts a Master Station 100(B)
`
`broadcasting an inquiry message to a single recipient in a point-to-point network
`
`topology.
`
`15.
`
`In view of the foregoing, I believe UNILOC’s proposed construction of
`
`“broadcasting” is incorrect. I do not think any construction of “broadcasting” is
`
`necessary because the term’s ordinary meaning is well-understood and consistent
`
`with how the term is used in the ’049 Patent.
`
`C. “inquiry message”
`In the POR, UNILOC contends that an “inquiry message” must be
`
`16.
`
`construed 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, 18. I disagree
`
`and stand by my opinion, that under the broadest reasonable interpretation standard,
`
`
`
`7
`
`12
`
`
`
`Proceeding No.: IPR2019-00251
`
`a POSITA would have understood an “inquiry message” to be a “message seeking
`
`information or knowledge.”
`
`17. As a preliminary matter, I note that UNILOC failed to address the
`
`evidence I presented in my earlier declaration. For instance, I had noted that the
`
`Honorable Board had previously construed the term “inquiry message” as “a
`
`message seeking information or knowledge” in related U.S. Patent No. 7,587,207
`
`(“’207 Patent”). Ex. 1007, 41, 44; Ex. 1003, ¶¶[43]-[46]. In my opinion and as I
`
`explained in my earlier declaration, the Board’s construction is consistent with
`
`dictionary definitions and the disclosure of an “inquiry message” in the specification
`
`of the ’049 Patent. Ex. 1001, 1:54-61; see also Ex. 1012, pp 29, 31, 37-39, 89, 90,
`
`185. Ex. 1003, ¶[45]; Ex. 1013, 1376. UNILOC did not address or rebut the Board’s
`
`previous construction in its POR.
`
`18. UNILOC’s construction is also incorrect because 1) it lacks clarity,
`
`leaving the scope of an inquiry message unclear to a POSITA; and 2) it incorrectly
`
`limits the scope of inquiry messages to device discovery in Bluetooth networks. In
`
`particular, with respect to the first point, UNILOC contends that an inquiry message
`
`is “a specific type of message,” but does not provide any indication as to what a
`
`“specific type of message” might imply. In my opinion, such language is
`
`superfluous, as it imparts no meaning to a POSITA that would elucidate the nature
`
`of an inquiry message.
`
`
`
`8
`
`13
`
`
`
`Proceeding No.: IPR2019-00251
`
`19. Another superfluous phrase used in UNILOC’s construction is “which
`
`may request to join a piconet.” The use of “may” indicates that the inquiry message
`
`may or may not request to join a piconet. But if the message could be an inquiry
`
`message whether or not it requests to join a piconet, then such limitations are
`
`superfluous as they provide no indication to a POSITA concerning the nature of an
`
`inquiry message.
`
`20. Similarly, UNILOC’s construction utilizes the phrase “to discover
`
`other devices in the vicinity.” Yet again, the lack of clarity in UNILOC’s
`
`construction makes it difficult for a POSITA to determine the scope of what an
`
`“inquiry message” might be. For instance, UNILOC’s construction renders it
`
`unclear just what the limits of “the vicinity” are. Does being in the vicinity mean
`
`being part of, or connected to, a network? Or does it refer to a particular distance of
`
`an object or entity? UNILOC’s construction does not even indicate what object or
`
`entity the “other devices” have to be in the vicinity of.
`
`21. As I noted above, UNILOC’s construction is also incorrect because it
`
`improperly limits the scope of inquiry messages to Bluetooth networks and device
`
`discovery within Bluetooth networks. For instance, in reciting the phrase “request
`
`to join a piconet,” in my opinion UNILOC appears to limit inquiry messages to
`
`Bluetooth networks only. This is because piconets are known in the art to be
`
`associated with Bluetooth networks. For instance, Erekson explains that “a
`
`
`
`9
`
`14
`
`
`
`Proceeding No.: IPR2019-00251
`
`collection of devices connected in a Bluetooth system are referred to as a ‘piconet’
`
`or a ‘subnet.’” Ex.1025, 5:5-15, FIG. 1. Buttery explains that Bluetooth “is a radio
`
`interface using the 2.45GHz frequency band designed to allow suitably equipped
`
`portable electronic devices to connect and communicate wirelessly via short-range
`
`ad hoc networks. Such networks are known … as ‘piconets.’” Ex.1026, 2:5-16.
`
`Networks using other technologies are not referred to as piconets. In my experience,
`
`piconets are unique to Bluetooth networks.
`
`22.
`
`In contrast, the ’049 Patent explicitly states that “the general invention
`
`concept of polling HIDs via a broadcast channel used as part of the inquiry
`
`procedure is not restricted to Bluetooth devices and is applicable to other
`
`communications arrangements.” Ex. 1001, 3:24-29, 1:6-8; see also Ex. 1003,
`
`¶[42]. Thus, UNILOC’s construction, which limits the scope of an “inquiry
`
`messages” to Bluetooth environments, is clearly not supported by the ’049 Patent.
`
`23. Since an inquiry message is not limited to a Bluetooth network, an
`
`inquiry message cannot be limited to performing operations that an inquiry message
`
`performs in Bluetooth networks such as device discovery. Ex. 1014, 108. Indeed,
`
`an inquiry message can be used in any manner consistent with its ordinary meaning,
`
`that is a message seeking information or knowledge. Importantly, the ’049 Patent
`
`does not limit the use of inquiry messages to device discovery. Thus, any attempt
`
`by UNILOC to limit inquiry messages to device discovery is without merit.
`
`
`
`10
`
`15
`
`
`
`Proceeding No.: IPR2019-00251
`
`24. For at least the foregoing reasons, UNILOC’s construction of “inquiry
`
`message” is incorrect and should be rejected by the Board. Furthermore, for the
`
`reasons noted in my earlier declaration, I believe the proper construction of “inquiry
`
`message” in the context of the ’049 Patent is a “message seeking information or
`
`knowledge,” which is consistent with the construction previously adopted by the
`
`Board. Ex.1003, ¶¶[39]-[46].
`
`III. UNILOC MISCHARACTERIZES OR MISUNDERSTANDS THE
`TEACHINGS OF LARSSON AND IROBEX
`A. Larsson's broadcast message for route discovery is an
`inquiry message
`25. As I noted above in Section II.C, an inquiry message is a message
`
`seeking information or knowledge. In contrast to UNILOC’s construction and
`
`incorrect assertions in the POR, an inquiry message in the ’049 Patent is not limited
`
`to a Bluetooth network, device discovery, or to requests to join a piconet. For
`
`instance, UNILOC argues as follows:
`
`
`
`11
`
`16
`
`
`
`Proceeding No.: IPR2019-00251
`
`
`POR, 18
`
`
`
`26. UNILOC’s remarks focus solely on the example of an inquiry message
`
`being used in a Bluetooth network or piconet. However, as I noted above in Section
`
`II.C, the ’049 Patent expressly indicates that inquiry protocols and messages are not
`
`limited to Bluetooth communication systems. Ex. 1001, 3:24-29, 1:6-8. Inquiry
`
`messages can be used in other communication systems. Id. Thus, UNILOC’s
`
`characterization of the ’049 Patent and UNILOC’s arguments in its POR that
`
`Larsson's broadcast message for route discovery is not an inquiry message are
`
`incorrect.
`
`27.
`
`Indeed, a POSITA would have understood that because an inquiry
`
`message is a message seeking information or knowledge and is not limited to
`
`operations generally performed by inquiry messages in Bluetooth networks (e.g.,
`
`device discovery), inquiry messages may seek various types of information
`
`
`
`12
`
`17
`
`
`
`Proceeding No.: IPR2019-00251
`
`depending on the type of network and communication technology being utilized.
`
`For instance, in Larsson, route information is being sought through a broadcast
`
`message for route discovery sent to a destination node, which, in response to the
`
`message, sends route information back to the source node. Ex. 1005, FIG. 6B, 6:45-
`
`62. In my opinion, seeking route information, as in Larsson, is similar to seeking a
`
`device’s address through the use of an inquiry message—which is a well-known use
`
`of inquiry messages in Bluetooth networks. Ex.1014, 108. I am comfortable making
`
`this statement because in several cases, route information may include the address
`
`of a destination node. A POSITA would understand that in order to obtain or
`
`determine a route to a destination node, the address of the destination node may also
`
`be determined or obtained. In some cases, route information may even include
`
`address information of the destination node. For these reasons, in my opinion, a
`
`POSITA would have understood that a message such as Larsson’s broadcast
`
`message for route discovery, which seeks route information, is an inquiry message.
`
`B. Larsson discloses adding an additional data field to its inquiry
`message
`28. UNILOC appears to argue that the Petition failed to sufficiently show
`
`how Larsson discloses or renders obvious “adding to an inquiry message prior to
`
`transmission an additional data field for polling at least one secondary station”
`
`because the Petition allegedly failed to appreciate the difference between “data” and
`
`“data field” and treated the two terms interchangeably. POR, 20-23. However, in
`
`
`
`13
`
`18
`
`
`
`Proceeding No.: IPR2019-00251
`
`my opinion, UNILOC mischaracterizes the Petition’s statements and fails to
`
`recognize that a POSITA would readily appreciate that data fields were being added
`
`to Larsson’s broadcast message.
`
`29. For example, although UNILOC quotes the phrase “the piggybacked
`
`data . . . is a data field for polling” from the Petition in alleging that Petitioner used
`
`data field and data interchangeably, UNILOC intentionally omitted the text “(i.e.,
`
`broadcast message for which the source node expects a reply)” that Petitioner had
`
`included in this statement and replaced it with “…”. The omitted language clearly
`
`indicates that the piggybacked data is a broadcast message, which as I note below,
`
`Petitioner had explained includes a plurality of data fields. In my opinion,
`
`UNILOC’s intentional omission was a significant mischaracterization of Petition’s
`
`statements. I will further illustrate this point in the following paragraphs.
`
`30. Larsson implements a “route discovery technique for use in a Bluetooth
`
`scatternet” in which “broadcast messages [for] which the source node expects a reply
`
`message [are combined] with broadcast messages for route discovery.” Ex. 1005,
`
`5:35-50; Ex. 1003, ¶[48]. On pages 20-22 of the Petition, Petitioner explained that
`
`Larsson’s Bluetooth broadcast messages would have a set of predetermined data
`
`fields in a particular arrangement which would also include the BD_ADDR set of
`
`fields.
`
`
`
`14
`
`19
`
`
`
`Proceeding No.: IPR2019-00251
`
`
`Standard Bluetooth packet format (Ex. 1014, p 47; Pet. 22)
`
`
`
`Bluetooth Format of BD_ADDR (Ex. 1014, p 143; Pet., 21)
`
`
`
`
`
`31. On pages 23-25 of the Petition, Petitioner explained that “[u]nder BRI,
`
`the piggybacked broadcast message is the additional data field added to the request
`
`for route message (inquiry message) prior to transmission,” and “that the
`
`piggybacked broadcast message for which the source node expects a reply is a data
`
`field for polling.” Pet., 23. In my opinion, a POSITA would have readily understood
`
`that when one message is piggybacked onto another message, data fields of the
`
`piggyback message are added to the other message.
`
`32.
`
`In more detail, Larsson discloses that, when “the source node does not
`
`expect a reply message” in response to the broadcast message, “the source node will
`
`broadcast the message to all neighbor nodes.” without transmitting a piggyback
`
`message. Ex.1005, 5:60-6:217. “If the source node does expect a reply to the
`
`broadcast message, … the source node piggybacks the broadcast message in a
`
`request for route broadcast message.” Ex.1005, 6:3-10. Given that that standard
`15
`
`
`
`20
`
`
`
`Proceeding No.: IPR2019-00251
`
`Bluetooth packet does not have any data fields designated for piggyback data, it
`
`would be clear to a POSITA that to add the broadcast message (for which the source
`
`node expects a reply) to the request for route broadcast message, additional data
`
`fields would have to be added to the request for route broadcast message in order to
`
`transmit the piggybacked data with the request for route broadcast message.
`
`33.
`
`In related embodiments, Larsson appears to confirm this understanding.
`
`For example, Larsson discloses that when an ARP, name resolution or DHCP
`
`broadcast message is piggybacked onto a network adaptation layer route request
`
`broadcast message, “a piggyback indicator can be inserted in the network adaptation
`
`layer route request broadcast message. Alternatively, in 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.” Ex.1005, 7:55-61.
`
`34.
`
`In the first alternative, a POSITA would have understood that to insert
`
`a piggyback indicator into a network adaptation layer route request broadcast
`
`message, a data field is created to allow the insertion and placement of the piggyback
`
`indicator. If a designated data field is not used, a receiving device would not know
`
`how to process or where to look for the piggyback indicator in a received message.
`
`Thus, it would be understood by a POSITA an additional data field is added to a
`
`message to include a piggyback indicator in the message. In the second alternative,
`
`
`
`16
`
`21
`
`
`
`Proceeding No.: IPR2019-00251
`
`a POSITA would have understood that the longer length may also indicate the
`
`presence of extra data fields. For instance, additional data fields may be needed to
`
`accommodate data if the request for route message has a length longer than the
`
`normal fixed length of the request for route message.
`
`35. For the reasons I have explained above, in my opinion, “piggybacking,”
`
`as understood in the art and in the context of Larsson (piggybacking one message
`
`onto another message), would have been understood by a POSITA as encompassing
`
`the addition of data field(s) to a message. For these reasons and the reasons
`
`identified in the Petition and my previous declaration, Larsson discloses or renders
`
`obvious “adding to an inquiry message prior to transmission an additional data field
`
`for polling at least one secondary station,” as recited in claim 11.
`
`C. IrOBEX discloses "the method comprising the primary
`station broadcasting a series of inquiry messages"
`36. As a preliminary matter, UNILOC’s argument that IrOBEX does not
`
`disclose the above-noted claim feature relies on its erroneous construction (i.e., “a
`
`transmission that is receivable by multiple recipients”). POR, 25-27. For the reasons
`
`I have explained above in Section II.B, UNILOC’s construction is incorrect and
`
`consequently its arguments relying on the erroneous construction with respect to this
`
`feature also fail. Notwithstanding this logical conclusion, I provide some additional
`
`remarks below to demonstrate that even under UNILOC’s improper construction,
`
`IrOBEX still discloses or renders obvious this feature.
`
`
`
`17
`
`22
`
`
`
`Proceeding No.: IPR2019-00251
`
`37. For example, IrOBEX teaches that multiple logical connections are
`
`allowed “including simultaneous OBEX client/server sessions in both directions.”
`
`Ex.1006, 12. An OBEX server also use “the LM-MUX for multiplexing multiple
`
`simultaneous client requests.” Id., 24. “When it is desirable to provide concurrent
`
`access to multiple OBEX services over the same TinyTP connection, the Connection
`
`Id is used to differentiate between multiple clients. This is often the case when
`
`multiple services are accessed via the default OBEX server.” Id., 18. Accordingly,
`
`IrOBEX explicitly discloses multiple peer-to-peer connections implemented at the
`
`same time by virtue of a server being connected to multiple clients or vice-versa.
`
`See also Ex. 1006, 20, 24, 37; Pet., 47-48.
`
`38. As explained in the Petition, to initiate such connections, a requesting
`
`device (client or primary station) transmits an OBEX CONNECT (request) packet
`
`to a receiving device (server or secondary station) to request capability information,
`
`such as the OBEX packet size and OBEX protocol version supported by the
`
`receiving device. Ex.1006, 11, 23, 74; Ex.1003, [107]. The OBEX CONNECT
`
`(request) packet corresponds to the claimed “inquiry message,” and may be
`
`transmitted optionally with a target header to target devices with a particular ID,
`
`service, or application. Ex.1006, 17, 40. 41; Pet., 48-49. When a requesting device
`
`transmits an OBEX CONNECT (request) packet without the optional target header,
`
`
`
`18
`
`23
`
`
`
`Proceeding No.: IPR2019-00251
`
`a receiving device does not have to respond. Ex. 1006, 17, 23; Ex. 1003, [102]; Pet.,
`
`45-46.
`
`39. As can be appreciated from the foregoing, IrOBEX discloses
`
`broadcasting a series of inquiry messages by transmitting a series of OBEX
`
`CONNECT (request) packets to multiple receiving devices. If the optional target
`
`header is not included, the OBEX CONNECT (request) packet does not target a
`
`particular service and any of the multiple receiving devices may choose to respond.
`
`UNILOC’s erroneous construction of “broadcasting” does not require simultaneous
`
`transmission of the inquiry packets, and only requires that a transmiss