IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`Robert J. Davies
`In re Patent of:
`7,587,207 Attorney Docket No.: 39521-0058IP1
`U.S. Patent No.:
`September 8, 2009
`
`Issue Date:
`Appl. Serial No.: 09/876,515
`
`Filing Date:
`June 7, 2001
`
`Title:
`DATA DELIVERY THROUGH BEACONS
`
`
`Mail Stop Patent Board
`Patent Trial and Appeal Board
`U.S. Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`PETITION FOR INTER PARTES REVIEW OF UNITED STATES PATENT
`NO. 7,587,207 PURSUANT TO 35 U.S.C. §§ 311–319, 37 C.F.R. § 42
`
`
`
`
`
`
`
`
`Robert J. Davies
`In re Patent of:
`7,587,207 Attorney Docket No.: 39521-0058IP1
`U.S. Patent No.:
`September 8, 2009
`
`Issue Date:
`Appl. Serial No.: 09/876,515
`
`Filing Date:
`June 7, 2001
`
`Title:
`DATA DELIVERY THROUGH BEACONS
`
`
`Mail Stop Patent Board
`Patent Trial and Appeal Board
`U.S. Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`PETITION FOR INTER PARTES REVIEW OF UNITED STATES PATENT
`NO. 7,587,207 PURSUANT TO 35 U.S.C. §§ 311–319, 37 C.F.R. § 42
`
`
`
`
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`TABLE OF CONTENTS
`
`I.
`
`REQUIREMENTS FOR IPR UNDER 37 C.F.R. § 42.104 ............................ 1
`
`A. Grounds for Standing Under 37 C.F.R. § 42.104(a)................................. 1
`
`B. Challenge Under 37 C.F.R. § 42.104(b) and Relief Requested ............... 1
`
`II.
`
`SUMMARY OF THE ’207 PATENT ............................................................. 3
`
`A. Brief Description ....................................................................................... 3
`
`B. Level of Ordinary Skill in the Art as of the Critical Date ........................ 6
`
`III. Claim Construction under 37 C.F.R. §§ 42.104(b)(3) ..................................... 7
`
`IV. APPLICATION OF PRIOR ART TO THE CHALLENGED CLAIMS ........ 8
`
`A. [GROUND 1] – Claims 1-3, 5, 6, and 9-11 are obvious in view of
`
`McCall, BT Core, Larsson, and Hancock ................................................. 8
`
`V.
`
`PAYMENT OF FEES – 37 C.F.R. § 42.103 ................................................. 46
`
`VI. CONCLUSION .............................................................................................. 46
`
`VII. MANDATORY NOTICES UNDER 37 C.F.R § 42.8(a)(1) ......................... 46
`
`A. Real Party-In-Interest Under 37 C.F.R. § 42.8(b)(1) .............................. 46
`
`B. Related Matters Under 37 C.F.R. § 42.8(b)(2) ....................................... 46
`
`C. Lead And Back-Up Counsel Under 37 C.F.R. § 42.8(b)(3) ................... 46
`
`D. Service Information ................................................................................ 47
`
`
`
`
`
`
`
`i
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`
`
`EXHIBITS
`
`APPLE-1001
`
`U.S. Patent No. 7,587,207 to Davies (“’207 Patent”)
`
`APPLE-1002
`
`Prosecution History of the ’207 Patent (“the Prosecution His-
`tory”)
`
`APPLE-1003
`
`Declaration of Dr. Charles Knutson
`
`APPLE-1004
`
`Curriculum Vitae of Dr. Charles Knutson
`
`APPLE-1005 U.S. Patent No. 6,738,628 (“McCall”)
`
`APPLE-1006 U.S. Patent No. 5,806,017 (“Hancock”)
`
`APPLE-1007 Specification of the Bluetooth System: Wireless connections
`made easy, Core, Vol. 1, Bluetooth, Dec. 1, 1999 (“BT Core”)
`
`APPLE-1008 U.S. Patent No. 6,255,800 (“Bork”)
`
`APPLE-1009
`
`[Reserved]
`
`APPLE-1010 Internet Archive Capture of http://www.bluetooth.com:80/de-
`veloper/specification/specification.asp from March 1, 2000
`
`APPLE-1011 Internet Archive Capture of http://www.bluetooth.com:80/de-
`veloper/specification/core.asp from March 1, 2000
`
`APPLE-1012 Internet Archive Capture of http://www.bluetooth.com:80/de-
`veloper/specification/order.asp from March 1, 2000
`
`APPLE-1013 Internet Archive Capture of
`http://www.bluetooth.com:80/news/archive/archive.asp from
`March 4, 2000
`
`APPLE-1014 U.S. Patent No. 6,704,293 (“Larsson”)
`
`ii
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`APPLE-1015 PCT Patent Application Publication No. WO 01/41371
`(“Rune”)
`
`APPLE-1016 PROOF OF SERVICE, Civil Action No. 1:18-CV-159 R P,
`March 5, 2018
`
`iii
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`Apple Inc. (“Petitioner”) petitions for Inter Partes Review (“IPR”) of
`
`claims 1-3, 5, 6, and 9-11 (“the Challenged Claims”) of U.S. Patent No. 7,587,207
`
`(“’207 Patent”). As explained in this petition, there exists a reasonable likelihood
`
`that Petitioner will prevail with respect to at least one of the Challenged Claims.
`
`The Challenged Claims are unpatentable based on teachings set forth in at
`
`least the references presented in this petition. Apple respectfully submits that an
`
`IPR should be instituted, and that the Challenged Claims should be canceled as
`
`unpatentable.
`
`I.
`
`REQUIREMENTS FOR IPR UNDER 37 C.F.R. § 42.104
`
`A. Grounds for Standing Under 37 C.F.R. § 42.104(a)
`
`Petitioner certifies that the ’207 Patent is available for IPR, and that
`
`Petitioner is not barred or estopped from requesting IPR of the Challenged Claims
`
`on the grounds identified in this petition. Petitioner was first served with a
`
`complaint of infringement of the ’207 patent less than one year prior to the filing of
`
`this Petition. Ex. 1016 (“PROOF OF SERVICE” on “03/01/2018”).
`
`B. Challenge Under 37 C.F.R. § 42.104(b) and Relief Re-
`quested
`
`Petitioner requests IPR of the Challenged Claims based on the following
`
`grounds:
`
`
`
`1
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`Grounds
`
`’207 Patent Claims
`
`Grounds for Unpatentability
`
`Ground 1
`
`1-3, 5, 6, and 9-11
`
`§ 103 over McCall, BT Core, Larsson,
`and Hancock
`
`
`
`The ’207 Patent issued from U.S. Application No. 09/876,515, filed June 7,
`
`2001, which claims priority from British Application No. 0015454.2, filed June 26,
`
`2000, and British Application No. 0020073.3, filed August 15, 2000. See
`
`generally Ex. 1002. Petitioner takes no position on whether the ’207 Patent is
`
`entitled to an earlier priority date, but only applies prior art earlier than June 26,
`
`2000 (the “Critical Date”).
`
`McCall (Ex. 1005) qualifies as prior art under at least 35 U.S.C § 102(e).
`
`Specifically, McCall is a published patent application filed on February 16, 2000,
`
`before the Critical Date.
`
`Hancock (Ex. 1006) qualifies as prior art under at least 35 U.S.C § 102(b).
`
`Specifically, Hancock is a patent issued on September 8, 1998, more than one year
`
`before the Critical Date.
`
`Larsson (Ex. 1014) qualifies as prior art under at least 35 U.S.C § 102(e).
`
`Specifically, Larsson is a patent that was filed on December 6, 1999, before the
`
`Critical Date.
`
`BT (Bluetooth) Core (Ex. 1007) qualifies as prior art under at least 35 U.S.C
`
`§ 102(a). BT Core is a technical publication that was published by the Bluetooth
`
`2
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`SIG on December 1, 1999, before the Critical Date. Ex. 1007, p 1. Specifically,
`
`the BT Core specification was released and available for download or order from
`
`Bluetooth’s website in December 1999 (at least by March 1, 2000). Ex. 1010, p 1
`
`(“Download specification”); Ex. 1011, p 1 (“Specification of the Bluetooth System
`
`- Core”); Ex. 1012, p 1 (“On this page you can order the printed version of the
`
`Bluetooth Specification 1.0. You can also download an Adobe Acrobat file of the
`
`complete specification free of charge (choose ‘Specification Intro’ in the menu to
`
`the right)”); Ex. 1013, p 1 (“New revision of the Bluetooth 1.0 Specification
`
`released”).
`
`
`
`Additional explanation and support for the positions explained herein are set
`
`forth in the Declaration of Dr. Charles Knutson (Ex. 1003), referenced throughout
`
`this petition.
`
`II.
`
`SUMMARY OF THE ’207 PATENT
`
`A. Brief Description
`
`The ’207 Patent generally relates to a wireless communication system in
`
`which a beacon device transmits Bluetooth Inquiry messages with location
`
`information to other devices in the wireless communication system. Ex. 1001,
`
`Abstract, 2:14-27. In particular, the ’207 Patent describes portable user devices
`
`that use “low power, short range base stations” in the form of beacons “to provide
`
`location-specific information” to a user. Ex. 1001, 1:3-20. The portable user
`
`3
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`devices are also referred to in the ’207 Patent as “Context-Aware” (CA) devices,
`
`such as mobile phones and personal digital assistants. Ex. 1001, 1:3-20; Ex. 1003,
`
`¶[33].
`
`In describing problems associated with connecting user devices to a
`
`Bluetooth piconet network, the ’207 Patent explains that, when the user device
`
`wants to join the piconet, the device does “not know its current location and the
`
`operation of any location aware applications on the terminal” would be impaired.
`
`Ex. 1001, 10:1-11. Furthermore, a user device would have to wait as long as 10.24
`
`seconds to conduct an inquiry broadcast and “may not spend enough time near a
`
`given beacon to establish a Bluetooth link.” Ex. 1001, 7:18-31; Ex. 1003, ¶[34].
`
`To address the problems noted above, the ’207 Patent “provide[s] a system
`
`for the delivery of data [to CA devices] via beacons whereby the amount of
`
`dedicated circuitry and operating procedure are kept to low levels.” Ex. 1001,
`
`2:10-13. In this system, CA devices “quickly and efficiently gather data from
`
`beacons such that the user is not required to undertake actions such as staying close
`
`to a beacon whilst contact is established between portable device and beacon.” Ex.
`
`1001, 1:65-2:5. In addition, a user is not required to initiate interaction. Ex. 1001,
`
`1:65-2:5; Ex. 1003, ¶[35].
`
`To achieve these goals, the ’207 Patent discloses a communications system
`
`in which a plurality of beacons 102, 104, 106, 108 are distributed throughout a
`
`4
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`locale, such as a department store, shopping, mall, theme park, or other
`
`infrastructure. Ex. 1001, FIG. 2, 5:52-65. “A portable device that wants to be
`
`discovered by a beacon [utilizing the Bluetooth protocol] enters the inquiry scan
`
`sub state. Here, it listens for a[n inquiry] message” that contains a General Inquiry
`
`Access Code (GIAC) or Dedicated Inquiry Access Code (DIAC) of interest and an
`
`additional data field. Ex. 1001, 6:65-67, 7:32-35, 6:49-55, 6:62-65. For instance,
`
`as shown in the ’207 Patent’s FIG. 5 (below), inquiry messages have an extra field
`
`appended to them, capable of carrying a user-defined payload (CA DATA).” Ex.
`
`1001, 7:45-55; Ex. 1003, ¶[36].
`
`’207 Patent, FIG. 5 (with annotations in red)
`
`
`
`The appended field includes location information. Ex. 1001, 10:12-16.
`
`“[T]he location information may take a number of forms in both the format
`
`location information is represented and in the format it is broadcast. For example,
`
`the information may be represented in terms of mapping coordinates, Global
`
`Positioning System data, or any other suitable way. Location information may be
`
`absolute or relative. In the latter case location information may be expressed, for
`
`5
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`example, with reference to building room designations, vehicle identity (say, when
`
`a person is on a bus) or in other ways as will be apparent to the person skilled in
`
`the art.” Ex. 1001, 11:27-36. Effectively, by combining the location information
`
`with the inquiry message, a beacon can transmit pertinent location information to
`
`devices in its vicinity in a shorter time span and with less (exchanged) messages.
`
`Ex. 1003, ¶[37].
`
`Upon receiving an inquiry message, “the portable device enters a so-called
`
`inquiry response substate and issues a number of inquiry response messages to the
`
`beacon. The beacon will then page the portable device, inviting it to join the
`
`piconet.” Ex. 1001, 8:40-45; Ex. 1003, ¶¶[38]-[40].
`
`B.
`
`Level of Ordinary Skill in the Art as of the Critical Date
`
`A person of ordinary skill in the art as of the Critical Date of the ’207 Patent
`
`(“POSITA”) would have had a Master’s of Science Degree (or a similar technical
`
`Master’s Degree, or higher degree) in an academic area emphasizing electrical
`
`engineering or computer engineering with a concentration in wireless
`
`communication systems or, alternatively, a Bachelors Degree (or higher degree) in
`
`an academic area emphasizing electrical or computer engineering and having two
`
`or more years of experience in wireless communication systems. Additional
`
`education in a relevant field, or industry experience may compensate for a deficit
`
`in one of the other aspects of the requirements stated above. Ex. 1003, ¶¶[30]-[32].
`
`6
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`Unless noted otherwise in this Petition, references to what would have been known
`
`or understood by a POSITA refer to the knowledge of a POSITA as of the Critical
`
`Date, or before.
`
`III. Claim Construction under 37 C.F.R. §§ 42.104(b)(3)
`
`On November 13, 2018, the United States Patent and Trademark Office
`
`revised the claim construction standard for interpreting claims in IPR proceedings
`
`from the “broadest reasonable interpretation” standard to the Federal Court claim
`
`construction standard used to construe a claim under 35 U.S.C. § 282(b), also
`
`known as the Phillips standard. Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir.
`
`2005). According to the Phillips claim construction standard, a claim term must be
`
`given an ordinary and customary meaning that a POSITA would apply to the term.
`
`Phillips, 1312-13.
`
`For the purposes of this proceeding, Petitioner is not currently proposing any
`
`particular construction. However, Petitioner reserves the right to respond to any
`
`constructions that Patent Owner may offer later or that the Board may adopt.
`
`Petitioner is not waiving any arguments concerning indefiniteness or claim scope
`
`that may be raised in litigation.
`
`
`
`
`
`7
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`IV. APPLICATION OF PRIOR ART TO THE CHALLENGED
`CLAIMS
`
`McCall, BT Core, Larsson, and Hancock render obvious all limitations of
`
`the Challenged Claims, thereby invalidating the Challenged Claims of the ’207
`
`Patent. As detailed below, this request shows a reasonable likelihood that the
`
`Petitioner will prevail with respect to the Challenged Claims of the ’207 Patent.
`
`A.
`
`[GROUND 1] – Claims 1-3, 5, 6, and 9-11 are obvious in
`view of McCall, BT Core, Larsson, and Hancock
`
`Ground 1 presents a combination of McCall, BT Core, Larsson, and
`
`Hancock. Although four references are advanced in the combination, the majority
`
`of claim features are rendered obvious by McCall, which discloses a Bluetooth
`
`beacon system that is similar to the ’207 Patent. With McCall providing the base
`
`Bluetooth beacon system, BT Core, Larsson, and Hancock provide relatively minor
`
`additions to what is already disclosed in McCall. Specifically, BT Core provides
`
`details on the Bluetooth standard used by McCall, Larsson confirms that it is well-
`
`known to use an indicator (e.g., a length or piggyback indicator) to inform a
`
`recipient of a message that additional data has been added to the message, and
`
`Hancock confirms that beacons were known to send actual beacon location in a
`
`beacon message as an alternative to McCall’s technique of sending a beacon
`
`identifier that the recipient uses to lookup the beacon’s location. With this
`
`8
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`background, and as discussed in more detail below, McCall combines with each of
`
`BT Core, Larsson, and Hancock to render obvious the Challenged Claims.
`
`Overview of McCall
`
`McCall discloses a method to track the location of objects using beacons of a
`
`wireless communication network that are physically dispersed in a building, as
`
`shown in FIG. 1 below. Ex. 1005, 1:1-5, Abstract. In particular, McCall’s FIG. 1
`
`depicts beacons 102-112 that are located “throughout a floor of a building 100 in
`
`which assets 120, 122 are to be tracked.” Ex. 1005, 3:30-35; Ex. 1003, ¶[41].
`
`Communications in McCall’s wireless communication network are implemented
`
`using the Bluetooth protocol. Ex. 1005, Abstract, 2:47-52, 5:5-15.
`
`Beacons
`shown
`in red
`boxes
`
`Assets
`
`
`Ex. 1005, FIG. 1 (with annotations in color)
`
`9
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`McCall discloses a particular embodiment in which a beacon does not have a
`
`
`
`receiver. Ex. 1005, 4:10-16. In this embodiment, “the beacon 102-112 transmits
`
`its identifying signal continuously, or at intervals” and the “asset 120, 122 pas-
`
`sively listens for beacons 102-112 that are transmit[ed] either continuously or in-
`
`termittently.” Ex. 1005, 4:10-16, 4:26-32. For instance, the uni-directional arrow
`
`in McCall’s FIG. 4 (reproduced below) illustrates a beacon 110 transmitting the
`
`identifying signal to asset 122 (see also step 304 in McCall’s FIG. 3 reproduced
`
`below). The identifying signal includes a unique global ID that identifies the bea-
`
`con. Ex. 1005, 3:58-65, 4:25-35. McCall discloses using a Bluetooth “‘inquire’
`
`protocol whereby a device transmits a specified sequence of data packets, and any
`
`‘listening’ device responds with its identifier, which is a globally unique number
`
`burned into the device firmware.” Ex. 1005, 5:5-27; Ex. 1003, ¶[42].
`
`
` Ex. 1005, FIG. 4 Ex. 1005, FIG. 3
`
`
`
`10
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`An asset 120, 122 receives the identifying signal and decodes the signal to
`
`determine the beacon ID, as shown above in steps 306 and 308 of FIG. 3. The lo-
`
`cation of the asset 120, 122 may then be determined using the unique beacon ID
`
`received from the beacon. Ex. 1005, 3:63-4:7, 4:32-67. For example, the asset
`
`120, 122 may send the beacon ID to server 402 which determines a location corre-
`
`sponding to the beacon ID and transmits the location back to the asset 120, 122.
`
`Ex. 1005, 4:35-64, FIG. 3. The asset 120, 122 then determines its location based
`
`on the location information provided by server 402. Ex. 1005, 4:35-64. In some
`
`cases, the asset 120, 122 may have the resources to compute its own location based
`
`on the received beacon ID. Ex. 1005, 4:64-67; Ex. 1003, ¶[43].
`
`Overview of BT Core
`
`BT (Bluetooth) Core is a document published by Bluetooth that describes
`
`standard features of the Bluetooth communications protocol. Ex. 1007, pp 5-13.
`
`For example, BT Core describes the standard Bluetooth packet format (shown
`
`below) as including three fields, namely an access code, header, and payload. Ex.
`
`1007, p 47; Ex. 1003, ¶[44].
`
`Standard Bluetooth packet format (Ex. 1007, p 47)
`
`
`
`11
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`Bluetooth packets can be adapted for different types of messages, one of
`
`which is an inquiry message that is transmitted during a Bluetooth Inquiry
`
`protocol. Ex. 1007, p 108; Ex. 1003, ¶[45]. The Bluetooth Inquiry protocol is
`
`used when a source or master device wants to discover other devices but does not
`
`know the addresses of the other devices. Ex. 1007, pp 108-10. The source device
`
`broadcasts an inquiry message at different hop frequencies to discover and connect
`
`to the other devices by obtaining their addresses. Ex. 1007, p 108. A device
`
`receiving the inquiry message may opt to respond with an inquiry response
`
`message. Ex. 1007, pp 108-10. In the inquiry response message, the receiving
`
`device includes its address, so that the source device can use the address to
`
`establish a connection with the receiving device. Ex. 1007, p 111.
`
`The inquiry message used in the Bluetooth Inquiry protocol does not include
`
`a header or payload field, and generally only includes the access code field. Ex.
`
`1007, p 48. The access code field includes data fields; namely, the preamble field,
`
`sync word field, and optionally a trailer field. Ex. 1003, ¶[46]. The standard
`
`Bluetooth packet format and the Access Code field format are shown below for
`
`comparison purposes.
`
`
`
`
`
`12
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`
` Standard Bluetooth packet format (Ex. 1007, p 47)
`
`
`
`Standard Access code field format (Ex. 1007, p 48)
`
`
`
`Access codes may include a general inquiry access code (GIAC) or a
`
`dedicated inquiry access code (DIAC). Ex. 1007, p 48. A GIAC “can be used to
`
`discover which other Bluetooth units are in range.” Ex. 1007, p 48. A DIAC can
`
`be used to discover only particular types of Bluetooth units in range. Ex. 1007, p
`
`48; Ex. 1003, ¶[47].
`
`Combination of McCall and BT Core
`
`As noted above, McCall teaches that its communication network is imple-
`
`mented using the Bluetooth protocol, and that the Bluetooth Inquiry protocol is
`
`used for communications between devices. Ex. 1005, 5:5-27, 2:47-52, Abstract.
`
`Although McCall discloses the use of an Inquiry protocol for communications be-
`
`tween devices, McCall does not explicitly disclose all details of how Bluetooth
`
`communications would be implemented. Ex. 1003, ¶[48].
`
`13
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`For a better understanding of the data packets transmitted to obtain a beacon
`
`ID and other Bluetooth features used in McCall, a POSITA would have combined
`
`the teachings of McCall and BT Core to fully realize the implementation of Blue-
`
`tooth in McCall’s device tracking method. Ex. 1003, ¶[49]. Doing so would have
`
`amounted to nothing more than the use of a known technique to improve similar
`
`devices in the same way or the combination of prior art elements according to
`
`known methods to yield predictable results. See KSR v. Teleflex, 550 U.S. 398,
`
`417 (2007).
`
`For instance, the combination of McCall and BT Core reveals that data pack-
`
`ets transmitted during an Inquiry protocol would include an inquiry message and
`
`an inquiry response message. Ex. 1003, ¶[50]. The inquiry message includes an
`
`access code field (e.g., preamble, sync word, and trailer fields), and the inquiry re-
`
`sponse message includes an address of the device responding to the inquiry mes-
`
`sage. Ex. 1003, ¶¶[48]-[50].
`
`When the teachings of BT Core are applied to McCall’s embodiment in
`
`which a beacon only includes a transmitter (indicating that the beacon cannot re-
`
`ceive any message), it would have been obvious to a POSITA that an inquiry mes-
`
`sage is transmitted by a beacon 102-112 to an asset 120, 122 to communicate with
`
`the asset 120, 122 and convey the beacon’s ID to the asset 120, 122. Ex. 1003,
`
`¶[51]. This would have been obvious and predictable at least because the inquiry
`
`14
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`message is an initial message used in the Bluetooth protocol to establish a connec-
`
`tion between two devices (as noted above in the discussion of BT Core.) Ex. 1007,
`
`pp 108-10; Ex. 1003, ¶[51]. In fact, in McCall’s transmitter-only embodiment, the
`
`beacon cannot receive Bluetooth messages and, thus, cannot receive an inquiry re-
`
`sponse with the Bluetooth address needed to establish a Bluetooth connection with
`
`another device. Ex. 1003, ¶[52]. Accordingly, in the transmitter-only embodi-
`
`ment, a POSITA would have understood that McCall’s beacon cannot establish a
`
`Bluetooth connection with another device and the only way the beacon can provide
`
`information to another device using Bluetooth is through the pre-connection in-
`
`quiry message. Id. For these reasons, a POSITA would have understood that
`
`McCall’s transmitter-only embodiment uses Bluetooth’s inquiry message to trans-
`
`mit information (e.g., beacon ID) to assets 120, 122. Ex. 1003, ¶[52]. Thus, a
`
`POSITA would have found it obvious to implement McCall’s transmitter-only em-
`
`bodiment by using a Bluetooth inquiry message to transmit location tracking infor-
`
`mation (e.g., beacon ID) to assets 120, 122. Ex. 1003, ¶[52].
`
`To convey a beacon’s ID to asset 120, 122 in an inquiry message, a POSITA
`
`would readily appreciate the need to modify the structure of the standard inquiry
`
`message such that the beacon ID is included in the inquiry message in addition to
`
`the preamble, sync word, and (optional) trailer fields of the access code of the in-
`
`quiry message. Ex. 1003, ¶¶[53]-[56]. As Dr. Knutson explains, the standard
`
`15
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`fields of a Bluetooth inquiry message do not include a payload field needed to con-
`
`vey data, such as the beacon ID. Id. To address this issue, a POSITA would have
`
`appreciated the need to add an additional field to the standard inquiry message and,
`
`as shown below, would have found it obvious to add the standard Bluetooth pay-
`
`load field to the inquiry message and use the added payload field to convey the
`
`beacon ID. Id. The payload header also includes a payload length indicator, which
`
`indicates a length of the payload. Ex. 1007, pp 62-64.
`
`
`
`
`
`
`
`Based on the packet structure of a standard Bluetooth packet (reproduced be-
`
`low), it would have been obvious and predictable to a POSITA that the payload
`
`field (with its header) would have been added to the access code fields of a typical
`
`inquiry message to accommodate the beacon ID as the access code fields are not
`
`designed to carry such data. Ex. 1007, pp. 48, 49; Ex. 1003, ¶[56].
`
`Furthermore, because the payload field in a standard Bluetooth packet is also
`
`placed at the end of a data packet, the placement of the payload at the end of a
`
`Bluetooth inquiry message would have been an obvious and predictable design
`
`choice that is similar to the standard Bluetooth protocol packet format. Ex. 1003,
`
`16
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`¶[57]. Indeed, such a packet structure would also mimic or resemble an inquiry re-
`
`sponse message in which a payload field is appended to the access code and header
`
`fields, as shown in the standard Bluetooth packet format. Ex. 1007, pp. 56, 110,
`
`112. Thus, the combination of McCall and BT Core amounts to nothing more than
`
`the use of a known technique to improve the combination of prior art elements ac-
`
`cording to known methods to yield predictable results. See KSR v. Teleflex.
`
`
`
`Standard Bluetooth packet format (Ex. 1007, p 47)
`
`
`
`Additionally, it would have been obvious to a POSITA that the payload
`
`length indicator could be used to indicate the presence of the location information
`
`(additional data field) when the payload field is added to the inquiry message fields
`
`and that the payload length indicator identifies a length of the payload field added
`
`to McCall’s inquiry message for transmission of location information. Ex. 1003,
`
`¶[58]. For example, by virtue of its existence, a length indicator field indicates the
`
`presence of the payload field in addition to the fields of the inquiry message.
`
`Additionally, a length that is longer than zero further indicates that a payload field
`
`has been added to the fields of the inquiry message. Ex. 1003, ¶[58].
`
`
`
`17
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`Overview of Larsson
`
`Larsson is related to updating and maintaining route information in wireless
`
`ad-hoc networks, such as Bluetooth networks. Ex. 1014, 1:14-40. In particular,
`
`Larsson discloses a method to: 1) speed up the signaling required to set up a route
`
`between a source node and a destination node, and 2) minimize the “number of
`
`broadcast messages required for setting up a route from [the] source node to [the]
`
`destination node.” Ex. 1014, 2:25-50, 3:64-4:10, 4:32-36; Ex. 1003, ¶[59].
`
`According to Larsson’s route discovery technique, a source node in the
`
`Bluetooth scatternet generates a broadcast message and determines whether a reply
`
`is expected to the broadcast message. Ex. 1014, FIG. 6A (reproduced below),
`
`5:60-6:2. After determining that the source node expects a reply, “the source node
`
`piggybacks the broadcast message in a request for route broadcast message.” Ex.
`
`1014, FIG. 6A, 6:2-8. Next, the source node broadcasts the request for route
`
`message with the piggybacked broadcast message to its neighbor nodes. Ex. 1014,
`
`FIG. 6A, 6:10-15; Ex. 1003, ¶[60].
`
`18
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`Ex. 1014, FIG. 6A
`
`
`
`To alert the destination node that a message has been piggybacked onto the
`
`request for route message, Larsson uses a piggyback indicator to indicate that
`
`additional data has been sent with the Bluetooth message. Ex. 1003, ¶[61]. In
`
`particular, when another broadcast message is added to a route request broadcast
`
`message, “a piggyback indicator can be inserted in the … 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.
`
`1014, 7:37-62. Combining the additional broadcast message with the route request
`
`broadcast message is advantageous because the combination “results in less
`
`19
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`messages traversing the network.” Ex. 1014, 7:42-46; Ex. 1003, ¶[61]. Larsson
`
`also discloses that “the messages described in FIG. 7 are merely exemplary and the
`
`method is equally applicable to other types of broadcast messages.” Ex. 1014,
`
`7:42-46.
`
`
`
`Combination of McCall, BT Core, and Larsson
`
`As described in the Overviews of McCall and BT Core above, McCall
`
`renders obvious a beacon transmitting location information to an asset using an
`
`inquiry message. Ex. 1005, 3:58-65, 4:10-32, 5:5-27. Specifically, based on the
`
`disclosures of McCall and BT Core, a POSITA would have found it obvious to
`
`implement McCall’s transmitter-only embodiment by adding a payload field (with
`
`its header) to the access code fields of a typical inquiry message (at the end of a
`
`Bluetooth inquiry message) to accommodate the location information sent by the
`
`beacon. Ex. 1003, ¶¶[62]-[63]. Further, BT Core teaches that a payload length
`
`indicator is included in the payload header and is used to indicate a length of the
`
`payload. Ex. 1007, pp 62-64. When added to an inquiry message, the mere
`
`presence of the length indicator indicates that an additional data field in the form of
`
`a payload field has been added to the inquiry message. Ex. 1003, ¶[63].
`
`Larsson corroborates the use of a length indicator as an indication of an
`
`additional data field being added to a message. In particular, Larsson indicates that
`
`20
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`a length indicator was known and used in prior Bluetooth environments, e.g., like
`
`McCall’s preferred Bluetooth environment, to indicate that a message contains
`
`additional or piggybacked data. Ex. 1014, 7:37-62; Ex. 1003, ¶[64]. Thus, it
`
`would have been obvious to a POSITA to use a length indicator, as disclosed in BT
`
`Core’s payload header and/or Larsson, to indicate the presence of an additional
`
`data field, such as the payload field that includes location information. Ex. 1003,
`
`¶[64]. Doing so amounts to nothing more than the use of a known technique to
`
`improve the combination of prior art elements according to known methods to
`
`yield predictable results. Ex. 1003, ¶[64]; see KSR v. Teleflex.
`
`Alternatively, Larsson also discloses the use of a piggyback indicator in a
`
`broadcast message, e.g., a broadcast inquiry message, to indicate that additional
`
`data was being piggybacked onto the message. Ex. 1014, 7:37-62. It would have
`
`been obvious to a POSITA to combine the teachings of Larsson with the
`
`combination of McCall and BT Core to include Larsson’s piggyback indicator in a
`
`modified inquiry message, such as that disclosed by McCall and BT Core. Ex.
`
`1003, ¶[65]. In particular, a POSITA would have found it obvious to modify the
`
`portion of the transmitted message without the added payload field, i.e., an access
`
`code field of an inquiry message, to include the piggyback indicator. Ex. 1003,
`
`¶[65]. Specifically, a POSITA would have found it obvious to include the
`
`piggyback indicator in the original message to which the piggybacked message has
`
`21
`
`
`
`Attorney Docket No. 39521-0058IP1
`IPR of U.S. Patent No. 7,587,207
`
`
`
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
