UNITED STATES PATENT AND TRADEMARK OFFICE
`
`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
`
`
`
`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
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
