US 20020174364A1
`
`a9 United States
`
`a2 Patent Application Publication (o Pub. No.: US 2002/0174364 Al
`
`Nordman et al. (43) Pub. Date: Nov. 21, 2002
`(549) METHOD FOR PROTECTING PRIVACY (52) U.S. Cli .ot 713/201
`WHEN USING A BLUETOOTH DEVICE
`(76) Inventors: Ian Nordman, Soderkulla (FI); Tero
`Alamaki, Helsinki (FI); Marko (57) ABSTRACT
`Vanska, Espoo (FI); Mikko
`Tarkiainen, Espoo (FI); Norbert
`Gyorbiro, Helsinki (FI); Casper The user’s Bluetooth device substitutes a pseudonym
`Gripenberg, Helsinki (FI) address for the Bluetooth Device Address (BD_ADDR). The
`Correspondence Address: pseudonym address is a randomlzeq version of the
`MORGAN & FINNEGAN. L.L.P. BD_ADDR. The pseudonym address is used in all the
`345 Park Avenue ’ functions of the Bluetooth device that normally use the
`New York, NY 10154 (US) BD_ADDR, including the frequency hopping sequence, the
`device access code, the initialization key in link encryption,
`(21) Appl. No.: 09/860,553 the authentication code, and the various packet addresses. In
`. this manner, the user’s privacy is protected by preventing the
`9] .
`(22) Filed: May 21, 2001 user’s identity, routes, and activities from being correlated
`Publication Classification with his/her device’s address. In addition to the Bluetooth
`standard, the technique also applies to other wireless stan-
`(51) Int. CL7 oo HO04L. 9/00 dards.
`
`USER'’S BLUETOOTH DEVICE 100 \
`
`BROWSER 102
`
`PRIVACY OPTIONS MENU
`
`SELECT OPTION:
`(A) NORMAL BLUETOOTH DEVICE ADDRESS
`(B) PSEUDONYM BLUETOOTH DEVICE ADDRESS
`
`PSEUDONYM ADDRESS OPTIONS SUB-MENU
`(1) RANDOMIZE ENTIRE DEVICE ADDRESS /
`
`(2) KEEP MANUFACTURER CODE AND /
`RANDOMIZE REST OF DEVICE ADDRESS
`
`(3) SELECT PARTS OF ADDRESS TO RANDOMIZE \
`
`(4) ADDRESS RETENTION OPTIONS:
`(a) CHANGE ADDRESSES AFTER A TIME "T*
`(b) CHANGE AFTER INQUIRIES/CONNECTIONS
`{c) CHANGE WHEN LOCATION CHANGES
`{d) OTHER OPTIONS TO CHANGE ADDRESSES
`
`(5) RESET RANDOM NUMBER GENERATOR
`
`KEYPAD 104 |
`
`POSITIONING SENSOR 132 I
`
`APPLICATION PROGRAM 106
`
`USER’S DEVICE REAL ADDRESS BD_ADDR(0)
`
`— - =
`P ~ BLUETOOTH
`PICONET(2) _ -~ SLAVE 116
`- LINK
`N BD_ADDR(B)
`s
`/
`
`/" USER'S DEVICE BLUETOOTH
`PSEUDONYM ADDRESS LINK SLAVE 118
`
`BD_ADDR(2) 19
`BD_ADDR(C)
`
`PARKED
`BLUETOOTH
`/| stavei2o
`- BD_ADDR(D)
`~
`-~
`~
`-
`— USER’S DEVICE 100
`
`USER'S DEVICE 100 IS MASTER IN PICONET(2) AND
`MASTER'S BD_ADDR(2) IS USED IN PICONET(2) ACCESS CODE
`
`IS PARKED SLAVE TO MASTER 122
`S
`
`USER'S DEVICE
`PSEUDONYM BLUETOOTH
`ADDRESS MASTER 122
`BD_ADDR(1)
`BD_ADDR(E)
`PICONET(1)
`s
`BLUETOOTH
`USER'S DEVICE 100 IS ACTIVE SLAVE MASTER 114
`TO MASTER 114 IN PICONET(1) AND
`MASTER'S BD_ADDR(A) IS USED IN BD_ADDR(A)
`
`PICONET(1) ACCESS CODE
`
`Google Exhibit 1011
`
`Google v. SecCommTech
`
`
`
`
`
`
`
`
`
`US 2002/0174364 A1
`
`Patent Application Publication Nov. 21,2002 Sheet 1 of 6
`
`o
`
`[ Ol
`
`(0)4aav a9 SSIAAY 1VIY 30IAIA SAISN
`
`901 WVIOO0¥d NOILYOI1ddV
`
`¢€1 JOSN3S ONINOILISOd
`
`Y01 AvdAIA
`
`30092 §§300V (1)IANODId
`(v)¥aav ag NI @3sn §1 (V)¥aav-ag SAIISYIN
`ANV (1)I3NODId NI 711 ¥31SYIN OL
`vl 33ISVIA JAVIS JAILDYV S1 001 3D1AIQA SJISN
`HLO01N1e
`s1l
`(DIANODMI
`()¥aav-asg ~
`()yaav-as
`ZZ1 YAISYIN ssuaav
`HlOO13N1g WANOAN3Sd
`3D1A3Q SA3ISN
`ZZ1 33ISVIN OL IAVIS A3NAVd SI B
`001 3DIA3A S.338N -
`- -
`- AN
`< \
`(@daav-ag s .
`\
`0Z1IAVIS |/
`HLOO1aN1E |
`adiAvd |
`L /
`(Oxaav-ag /
`6L ()yaav-ag /
`811 IAVIS AN $534aaY WANOAN3Sd ,
`HLO013N1d 30IAZA SN,
`/
`_ /
`(9)¥yaav-asg P
`P
`oL IAVIS - (1INODId
`Hlo0LENE | Ay - \4/
`
`3002 $$302V (2)IINODId NI @3S Si (2)3aav™ad S.331SVIN
`ANV (2)1INODId NI J3ISVIN S1 001 3DIA3a S.3sn
`
`YOLVIINIO JITNNN WOANWY 1353 (S)
`$35S3IAAY IDONVHO OL SNOILJO ¥IHLO (P)
`SFONVHOI NOWUYIOT NIHM FONVHD (9)
`SNOILOINNOD/SIRINONI 3LV IONVHD (A)
`oL WIL V 3314V $3SSIIAAY FONVHDO (P)
`
`SNOIIdO NOLNIIII SsIaav (v)
`
`JZINOANVY Ol SS34AAV 40 SIAVd 10313S ()
`
`$S3¥AaQv 30IA3Q 40 153d IZINOANVY
`ANV 300D JFRIMNDVINNVIN 433 (2)
`
`$SIAAV IDIA3Q FYIINT FZINOANVY (1)
`
`NNIN-ENS SNOILLJO SSIIAAY WANOANIS
`
`$SIIAAY IDIAIQ HLOOL13NTE WANOANISd (8)
`$534AAY 3DIAIQ HLOOLANTE TYIWION (V)
`‘NOILdO 107138
`
`NNIN SNOILJO ADVARd
`
`20l d3ISMmodg
`
`J 001 3DIA3Q HLOO13N14 S.33sn
`
`
`
`
`
`
`
`
`
`Patent Application Publication Nov. 21,2002 Sheet 2 of 6 US 2002/0174364 Al
`]:|G 2A BLUETOOTH DEVICE 100
`. MEMORY}202
`APPLICATION GROUP 234
`USER’S DEVICE 100 RANDOM NUMBER
`REAL ADDRESS BD_ADDR(0)—~ ™ GENERATOR 230
`PSEUDONYM ADDRESSES
`ADDRESS MANAGER TABLE 232 v
`PAIRED DEVICE’S USER DEVICE 100 PSEUDONYM
`PAIRED DEVICE STATUS STATUS ADDRESSES
`DEVICE 114 MASTER PICONET(1) ACTIVE SLAVE BD_ADDR(1)
`DEVICE 116 ACTIVE SLAVE MASTER PICONET(2) BD_ADDR(2)
`DEVICE 118 ACTIVE SLAVE MASTER PICONET(2) BD_ADDR(2)
`DEVICE 120 PARKED SLAVE MASTER PICONET(2) BD_ADDR(2)
`DEVICE 122 MASTER PICONET(3) PARKED SLAVE BD_ADDR(3)
`INQUIRING DEVICE | POTENTIAL MASTER POTENTIAL SLAVE BD_ADDR(4)
`PAGED DEVICE POTENTIAL SLAVE POTENTIAL MASTER BD_ADDR(S)
`PSEUDONYM ADDRESSES < y
`FREQUENCY ENCRYPTION
`HOPPING ACCESS CODES AUTHENTICATIO/N PACKZLSUFFER
`SEQUENCE 235 236 238
`APPLICATION PROGRAM 106
`MIDDLEWARE PROTOCOL GROUP 224
`226 | SERVICE DISCOVERY PROTOCOL | 228| OBJECT EXCHANGE
`TRANSPORT PROTOCOL GROUP 214
`220" |LOGICAL LINK CONTROL AND ADAPTATION PROTOCOL (L2CAP)
`216 7| LINK CONTROLLER & BASEBAND 218”1 LINK MANAGER
`| | BUS 204 | |
`BLUETOOTH CENTRAL POSITION
`<> RADIO KE}’: fD PROCESSOR SENSOR D'g':LzAY
`206 210 132
`
`
`
`
`
`
`
`
`
`Patent Application Publication Nov. 21,2002 Sheet 3 of 6
`
`FIG. 2B
`
`US 2002/0174364 A1
`
`USER’S DEVICE 100
`REAL ADDRESS BD_ADDR(0)
`
`LOW ADDRESS HIGH ADDRESS NON-SIGNIFICANT | _ 250
`PART (LAP) PART (HAP) ADDRESS PART (NAP)
`ENTIRE 4 1ap HAP I Nap
`ADDRESS ‘
`Y ] CHAP+NAP
`CONTROL MANUFACTURER'S
`W» MULTIPLEXOR — 252 CODE
`OTHER
`PARAMETERS
`256
`Y RANDOM NUMBER 4}
`GENERATOR 230
`UNCHANGED RANDOMIZED F
`PORTION — PORTION — CONTROL
`258
`| AN j
`ADDRESS MANAGER TABLE 232 Yy v
`
`PAIRED DEVICE'S | USER DEVICE 100 PSEUDONYM
`
`PAIRED DEVICE STATUS STATUS ADDRESSES
`DEVICE 114 | MASTER PICONET(1) ACTIVE SLAVE BD_ADDR(1)
`DEVICE 116 ACTIVE SLAVE MASTER PICONET(2) BD_ADDR(2)
`DEVICE 118 ACTIVE SLAVE MASTER PICONET(2) BD_ADDR(2)
`DEVICE 120 PARKED SLAVE MASTER PICONET(2) BD_ADDR(2)
`DEVICE 122 | MASTER PICONET(3) PARKED SLAVE BD_ADDR(3)
`INQUIRING DEVICE | POTENTIAL MASTER | POTENTIAL SLAVE BD_ADDR(4)
`PAGED DEVICE POTENTIALSLAVE | POTENTIAL MASTER BD_ADDR(5)
`
`PSEUDONYM ADDRESSES ~ *
`FREQUENCY ENCRYPTION / PACKET
`HOPPING ACCE52$3§tODES AUTHENTICATION ADDRESSES
`SEQUENCE 235 238 240
`
`
`
`
`
`
`
`
`
`Patent Application Publication Nov. 21,2002 Sheet 4 of 6
`
`FIG. 3
`
`PSEUDONYM ADDRESS GENERATION APPLICATION PROGRAM 106_
`
`¥
`
`302
`
`USER SELECTS OPTION
`N TO CHANGE PSEUDONYM ADDRESSES AFTER COUNTER/TIMER = 'T"
`OR OTHER OPTIONS TO CHANGE PSEUDONYM ADDRESSES
`
`CHANGE AFTER COUNTER/TIMER =A OTHEF OPTIONS TO CHANGE ADDRESSES
`
`l‘ \ 304 x?/
`
`1
`
`ST COUNTER TO ZERO AND BEGIN IF INQUIRY RECEIVED, OR
`coueT COUNTER T ZERO AND WHEN INQUIRY IS TO BE SENT, OR
`| (E.G.T=5) WHEN A NEW ADDRESS IS NEEDED
`322, v 308 ~ Y
`
`IF COUNTER = COUNTER_MAX
`CONTINUE, ELSE GOTO STEP 328
`
`GET POSITIONING SENSOR READING AND
`SELECT PORTION OF REAL ADDRESS
`BD_ADDR(0) TO RANDOMIZE
`
`324~ ¥
`
`310~ v
`
`SELECT PORTION OF REAL ADDRESS
`BD_ADDR(0) TO RANDOMIZE
`
`RANDOMIZE SELECTED PORTION TO
`OBTAIN PSEUDONYM ADDRESS
`
`326 ¥
`
`312+ Y
`
`RANDOMIZE SELECTED PORTION TO
`OBTAIN PSEUDONYM ADDRESS
`
`IF PSEUDONYM ADDRESS IS A DUPLICATE
`OF ANY OTHER KNOWN ADDRESS,
`
`THEN GOTO STEP 308
`328~ v 314~ y
`STORE PSEUDONYM ADDRESS IN STORE PSEUDONYM ADDRESS IN
`ADDRESS MANAGER TABLE ADDRESS MANAGER TABLE
`330, v 316+ !
`
`USE PSEUDONYM ADDRESS INSTEAD
`OF REAL ADDRESS BD_ADDR(0)
`
`USE PSEUDONYM ADDRESS INSTEAD OF
`REAL ADDRESS BD_ADDR(0)
`
`3324 Y 318+ ‘
`IF NO CONNECTION IS MADE AFTER INQUIRY, OR
`INCREMENT COUNTER IF PICONET CONTEXT CHANGES, OR
`AND GOTO 322 IF POSITION CHANGE EXCEEDS LIMITS, OR
`
`y
`
`IF COUNTER/TIMER EXCEEDS LIMITS, OR
`
`IF CONNECTION IS TORN DOWN,
`
`THEN STOP USING PSEUDONYM ADDRESS AND
`REMOVE IT FROM ADDRESS MANAGER TABLE
`
`US 2002/0174364 A1
`
`
`
`
`
`
`
`
`
`US 2002/0174364 A1
`
`Patent Application Publication Nov. 21,2002 Sheet 5 of 6
`
`| 0vZ ¥344nd 13NOVd
`T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T e T T T T T e T T T T e S e e T e - ||“
`— |
`maaav ag |
`$$33aAV WNANOAN3sd |- o0zs |
`00L 3DIA3d S33SN i
`\ s i
`925 ves \ , 81s 918 yls 21s _
`e e [ ¢ ‘ ‘ |
`ooL'Aza | o=uzs [ O N30 | Al A3 BdAL| o am |
`X010 | daav inv d ad | ALldvd 4dav WY | 3900585300V [gic |
`4O §sV10 | ssauaav 43avIH oLs !
`
`/4 {
`zzs 02s \ m
`
`00} FOIA3A S.”ISN A9 IN3S
`LINOVd ISNOdSTY AHUINONI NV ¥O4 .
`FANLON™ULS LIMOVd SH4 HLOOLINTE m.v @-E
`
`(OV19) 300D
`$$3D0V AINONI |
`I\LENER) 00s
`
`00} 3JIA3a s.3ASN
`Ol JJIAIA ONIMINONI A9 LN3S
`
`13IMOVd AMINONI NV dO0d "
`FANLONULS 13XOVd HLOOLIANTE <.v w—m\
`
`
`
`
`
`
`
`
`
`US 2002/0174364 A1
`
`Patent Application Publication Nov. 21,2002 Sheet 6 of 6
`
`001 JDIAZA S.AASN A9 LN3S
`13MOVd ONIDVd V ¥0d RRNLONYLS 1INOVd HLOOLINTE
`
`(9yaav—ad
`$S3AAY WANOQAN3ISd 40 dV1 |- 2G9S
`001 3DIA3Q SAISN SFANTONI
`\ /
`966 vss \ /
`b /
`. Tnn| =38 001 30IA3
`™~ h
`00} IDIAIA SHISN OL IJIAIA IOV Ad LNIS mw.,.n__@u_‘._ Wy m_m_wwmmm_%%w< 0ss
`134OVd LNIWOAITMONMOV J9Vd V ¥O4 % av-
`JUNLONYLS LINOVd HLOOLANTE 2SS 9l4
`\ 0vZ ¥344Ng 13XMOVd
`25 J_
`i (©3aav ag i
`: $s3¥AAY WANOQN3sd |-ovs _
`i 001 3DIA3Q S33sN |
`| \ / |
`| 9¥g Wws s \ , 8es 9gs ES zes :
`“ /s L I A4 L V4 |
`_ . — 001 'A3d | 00l ‘A3 L=13S 3DIA3d 43OVd _
`| o | yaepey | 3030 | 3dav-as | anvd [*M| saav'wy | dossmaay |- |
`| 40 SSV1D | ssayaav J33avaH 300D $5300V | O€S |
`/4
`" ors \ |
`s O |
`39IA3a 39Vd OL
`
`JF 9l
`
`
`
`
`
`
`
`
`US 2002/0174364 Al
`
`METHOD FOR PROTECTING PRIVACY WHEN
`USING A BLUETOOTH DEVICE
`
`FIELD OF THE INVENTION
`
`[0001] The invention disclosed broadly relates to ubiqui-
`tous computing and more particularly relates to improve-
`ments in short range RF technology.
`
`BACKGROUND OF THE INVENTION
`
`[0002] Bluetooth is a global de facto standard for wireless
`connectivity, which is based on a low-cost, short-range radio
`link. When two Bluetooth equipped devices come within ten
`meters range of each other, they can establish a connection
`together using a radio-based link. A Bluetooth-enabled lap-
`top computer can send information to a printer in the next
`room, or a microwave oven can send a message to one’s
`mobile phone announcing that that the meal is ready. Blue-
`tooth will become the standard in mobile phones, PCs,
`laptops and other electronic devices, enabling users to share
`information, synchronize data, access the Internet, integrate
`with LANs or actuate electromechanical devices, such as
`unlocking a car. A passenger can write e-mails on his/her
`laptop on an airplane and then, after landing, the messages
`can be automatically forwarded to the Internet by Bluetooth
`devices that are ubiquitously located around the airport
`terminal. In another example, while waiting in an airport
`lounge, a the passenger can receive interesting duty-free
`offers directly on his/her mobile phone or play multiplayer
`games with friends.
`
`[0003] Bluetooth devices are designed to find other Blue-
`tooth devices within their ten meter communications range
`and to discover what services they offer, using a service
`discovery protocol (SDP). To accomplish this, a Bluetooth
`device sends out an inquiry message searching for other
`devices in its vicinity. Any other Bluetooth device that is
`listening by means of conducting an inquiry scan, will
`recognize the inquiry message and respond. The inquiry
`response is a message packet containing the responding
`device’s Bluetooth Device Address (BD_ADDR). The Blue-
`tooth device address is a unique, 48-bit IEEE address which
`is electronically engraved into each Bluetooth device. The
`address is virtually guaranteed to be completely unique, so
`much so that it can be reliably associated with the device’s
`user, much as can the user’s passport number or social
`security number.
`
`[0004] As the user carries his/her Bluetooth device about,
`traveling among other Bluetooth devices, a trail is left in the
`form of the user’s Bluetooth Device Address (BD_ADDR),
`which the device has given out at each transmission of an
`inquiry response packet. The user’s routes and activities can
`be tracked by logging the times and locations of the obser-
`vance of his/her device’s Bluetooth Device Address. To the
`extent that the user is identified with his/her device’s Blue-
`tooth Device Address, it is almost as if the user were giving
`out his/her personal identity number to each inquiring Blue-
`tooth device. This realization will certainly be exploited in
`the future by market researchers, and possibly by more
`sinister observers, thereby seriously compromising the
`user’s privacy and possibly the user’s safety.
`
`[0005] What is needed is a way to provide a pseudonym
`for a Bluetooth device so that the user’s identity, routes, and
`activities cannot be correlated with his/her device’s address.
`
`Nov. 21, 2002
`
`SUMMARY OF THE INVENTION
`
`[0006] In accordance with the invention, the user’s Blue-
`tooth device substitutes a pseudonym address for the Blue-
`tooth Device Address (BD_ADDR). The pseudonym
`address is a randomized version of the BD_ADDR. The
`pseudonym address is used in all the functions of the
`Bluetooth device that normally use the BD_ADDR, includ-
`ing the frequency hopping sequence, the device access code,
`the initialization key in link encryption, the authentication
`code, and the various packet addresses.
`
`[0007] The user is provided with a menu of privacy
`options, to select the various features of the invention. Since
`the BD_ADDR includes a manufacturer’s code part, the user
`is given the option of preserving that part and randomizing
`the rest of the BD_ADDR. The user can select other parts or
`all of the BD_ADDR to randomize.
`
`[0008] The user can select introducing various parameters
`into the random number generator as initialization vectors to
`combine with the BD_ADDR, such as time-of-day clock
`values or biometric values such as keyboard latency, to
`change the random number sequence and thus thwart an
`eavesdropper’s discovery of that sequence. The resulting
`randomized pseudonym address is then stored in an address
`manager table, associating it with the paired Bluetooth
`devices with which the pseudonym address is exchanged.
`
`[0009] For example, when the user’s device receives an
`inquiry message from another Bluetooth device, it sends
`back an inquiry response message that contains the user’s
`pseudonym address instead of his/her device’s BD_ADDR.
`As another example, when the user’s device has the role of
`a master device connected to a slave device in a piconet, then
`the user’s pseudonym address is used as the piconet access
`code, instead of his/her device’s BD_ADDR.
`
`[0010] The user is also given a number of options for the
`retention of the pseudonym address in the address manager
`table. The anonymity of the user would otherwise be under-
`mined if the same pseudonym address were to be used
`indefinitely. In accordance with the invention, the address
`can be retained for a predetermined time or count selected by
`the user. Alternately, the address can be retained for a
`duration that at least begins with an inquiry received from
`another device and ends if no connection is made after the
`inquiry. Similarly, if the user’s device initiated sending an
`inquiry message, the address can be retained for a duration
`that at least begins with the inquiry and ends if no connec-
`tion is made after the inquiry. Pseudonym addresses can be
`computed prior to when they are needed, and then stockpiled
`by storage in a table in the user’s device.
`
`[0011] In an alternate option, the pseudonym address can
`be retained for a duration that ends when a piconet context
`changes for the user’s device. When the user’s device is the
`master device in a piconet, the pseudonym address will be
`used in the piconet access code. Thus, the user’s device will
`retain the pseudonym address until the piconet is broken up
`or until the user’s device relinquishes its role as the master
`device. Alternately, the address can be retained for a duration
`that at least begins with the sensing of the current physical
`location of the user’s device, and ends if that physical
`location changes beyond a predefined distance, such as the
`nominal radio broadcast range of a Bluetooth device. Alter-
`nately, the address can be retained for a duration that at least
`
`
`
`
`
`
`
`
`US 2002/0174364 Al
`
`begins with an inquiry that establishes a connection with
`another device, and ends when that connection is torn down
`or otherwise terminated. In this way it is not possible to track
`the usage of the user’s device nor discover the real, unique
`BD_ADDR of the device.
`
`[0012] Still further in accordance with the invention, even
`though the user device’s BD_ADDR has been randomized
`in the form of the pseudonym address, there is still a small
`chance that the resulting pseudonym address is coinciden-
`tally the same as another device’s BD_ADDR in the vicinity.
`The invention minimizes this possibility by comparing the
`newly generated pseudonym address with known addresses
`of all other devices that have been encountered in the
`vicinity. If the rare chance happens that the pseudonym
`address is the same as another device’s address, the newly
`generated pseudonym address is not used and another pseud-
`onym address is generated instead. If there are many
`repeated attempts to generate a pseudonym address that fail
`because of other duplicate addresses in the vicinity, then the
`user is notified and he/she can elect to use his/her device’s
`BD_ADDR for the proposed connection. This unlikely
`occurrence may be a symptom revealing that an eavesdrop-
`per is trying to discover the sequence of random numbers
`being generated by the user’s device. The user’s device in
`this case notifies the user and gives him/her the option to
`introduce various parameters into the random number gen-
`erator to change the random number sequence and thus
`thwart the eavesdropper’s discovery of that sequence.
`
`[0013] In addition to the Bluetooth standard, the invention
`also applies to other wireless standards. The invention’s
`principle of substituting randomized pseudonym addresses
`for the device’s real unique address, to confer anonymity
`upon the user, is equally useful in many other wireless
`standards. The invention applies, for example, to the IEEE
`802.11 Wireless LAN standards, the Japanese 3rd Genera-
`tion (3G) wireless standard, the various 2G, 2.5G, and 3G
`cellular telephone system standards, the Infrared Data Asso-
`ciation (IrDA) standard, the Digital Enhanced Cordless
`Telecommunications (DECT) standard, the Shared Wireless
`Access Protocol (SWAP) standard, the IEEE 802.15 Wire-
`less Personal Area Network (WPAN) standard, the High
`Performance Radio Local Area Network (HIPERLAN) stan-
`dard, and the Multimedia Mobile Access Communication
`(MMAC) Systems standard of the Japanese Association of
`Radio Industries and Businesses. The invention enables each
`of these wireless standards to protect the privacy of the
`user’s identity, routes, and activities so that they cannot be
`correlated with his/her device’s address.
`
`DESCRIPTION OF THE FIGURES
`
`[0014] FIG. 1 is a network diagram showing several ad
`hoc network piconets and the user’s Bluetooth device 100
`which is displaying the privacy options menu.
`
`[0015] FIG. 2A is a functional block diagram of the user’s
`Bluetooth device 100 of FIG. 1, showing the various
`program modules stored in its memory for the transport
`protocol group, middleware protocol group, and application
`
`group.
`
`[0016] FIG. 2B shows an example of the random number
`generator operating on various selected parts of the
`BD_ADDR of the user’s Bluetooth device 100.
`
`Nov. 21, 2002
`
`[0017] FIG. 3 is a flow diagram of the pseudonym address
`generation application program 106.
`
`[0018] FIG. 4A shows the Bluetooth packet structure for
`an inquiry packet sent to the user’s device 100 by an
`inquiring device.
`
`[0019] FIG. 4B shows the Bluetooth packet structure for
`an inquiry response packet sent by the user’s device 100 to
`the inquiring device.
`
`[0020] FIG. 4C shows the Bluetooth packet structure for
`a paging packet sent by the user’s device 100 to a paged
`device.
`
`[0021] FIG. 4D shows the Bluetooth packet structure for
`a page acknowledgment packet sent by the paged device to
`the user’s device 100.
`
`DISCUSSION OF THE PREFERRED
`EMBODIMENT
`
`[0022] The Bluetooth Special Interest Group, Specifica-
`tion Of The Bluetooth System, Version 1.0B, Volumes 1 and
`2, December 1999, describes the principles of Bluetooth
`device operation and communication protocols. Up to eight
`Bluetooth devices can join together in an ad hoc commu-
`nications network called a piconet. A piconet is an arbitrary
`collection of Bluetooth-enabled devices which are physi-
`cally close enough to be able to communicate and which are
`exchanging information on a regular basis. Each piconet has
`one master device and up to seven slave devices. All
`communication is directed between the master device and
`each respective slave device. The master initiates an
`exchange of data and the slave responds to the master. When
`two slave devices are to communicate with each other, they
`must do so through the master device. The master device
`maintains the piconet’s network clock and controls when
`each slave device can communicate with the master device.
`Members of the ad hoc network piconet join and leave as
`they move into and out of the range of the master device.
`Piconets support distributed activities, such as collaborative
`work projects, collaborative games, multi-user gateways to
`the Internet, and the like. A user’s device that joins a
`particular piconet, does so to enable its user to participate in
`the currently running collaborative activity.
`
`[0023] FIG. 1 is a network diagram showing several ad
`hoc network piconets and the user’s Bluetooth device 100
`which is displaying the privacy options menu in the browser
`102. The user’s Bluetooth device 100 includes the keypad
`104 and the positioning sensor 132. The positioning sensor
`132 can be, for example, a GPS receiver integrated in the
`device. The positioning sensor 132 can also be, for example,
`a radio beacon triangulation sensor that determines the
`location of the wireless device by means of a network of
`radio beacons, base stations, or access points, as is described
`for example, in Nokia European patent EP 0 767 594 A2,
`entitled “Mobile Station Positioning System”. The sensor
`132 provides inputs which are sampled by the wireless
`device 100 to infer a current geographical position. The
`positioning sensor 132 can also detect changes in position
`with respect to known, fixed station Bluetooth devices.
`
`[0024] Several other Bluetooth devices are within the
`operating range of the user’s device 100 of FIG. 1. In
`accordance with the invention, the user’s Bluetooth device
`has substituted a different pseudonym address for its real
`
`
`
`
`
`
`
`
`US 2002/0174364 Al
`
`Bluetooth Device Address BD_ADDR(0) in its relationship
`with each of the respective devices of FIG. 1. The user’s
`device 100 forms an ad hoc network piconet(1) with Blue-
`tooth device 114 on link 115. The user’s Bluetooth device is
`using a pseudonym address BD_ADDR(1) instead of its real
`BD_ADDR(0) in its relationship with Bluetooth device 114.
`Bluetooth device 114 uses its real Bluetooth Device Address
`BD_ADDR(A). Since in the piconet(l), the user’s device
`100 has the role of the active slave device connected to a
`master device 114 in the piconet(1), then the master’s real
`Bluetooth Device Address BD_ADDR(A) is used as the
`piconet access code. The address manager table 232 shown
`in FIG. 2 stores the user’s pseudonym address BD_AD-
`DR(L1) instead of its real BD_ADDR(0) for its relationship
`with Bluetooth device 114.
`
`[0025] Contrast this with ad hoc network piconet(2) in
`FIG. 1. The user’s device 100 forms ad hoc network
`piconet(2) with Bluetooth device 116 on link 117. The user’s
`Bluetooth device is using a different pseudonym address
`BD_ADDR(2) instead of its real BD_ADDR(0) in its rela-
`tionship with Bluetooth device 116. Bluetooth device 116
`uses its real Bluetooth Device Address BD_ADDR(13).
`Since in the piconet(2), the user’s device 100 has the role of
`the master device connected to a slave device 116, then the
`user’s pseudonym address BD_ADDR(2) used as the pico-
`net access code, instead of the user’s real Bluetooth Device
`Address BD_ADDR(0). The address manager table 232
`shown in FIG. 2 stores the user’s pseudonym address
`BD_ADDR(2) instead of its real BD_ADDR(0) for its
`relationship with Bluetooth device 116.
`
`[0026] There is another active slave device in ad hoc
`network piconet(2) of FIG. 1, the Bluetooth device 118
`connected on link 119. Bluetooth device 118 uses its real
`Bluetooth Device Address BD_ADDR(C). Since in the
`piconet(2) of FIG. 1, the user’s device 100 is the master
`device connected to slave device 118, then the user’s pseud-
`onym address BD_ADDR(2) is used as the piconet access
`code for slave device 118, as well as slave device 116. The
`address manager table 232 shown in FIG. 2 stores the user’s
`pseudonym address BD_ADDR(2) instead of its real
`BD_ADDR(0) for its relationship with Bluetooth device
`118.
`
`[0027] There is also a parked slave device in ad hoc
`network piconet(2) of FIG. 1, the Bluetooth device 120.
`Although Bluetooth device 120 does not have an active
`connection with the user’s master device 100, it does moni-
`tor the signals from the user’s master device 100 to stay in
`synchronism with the master’s clock. Bluetooth device 120
`uses its real Bluetooth Device Address BD_ADDR(D). If
`the parked slave Bluetooth device 120 were to rejoin pico-
`net(2) as an active slave device, it would employ the user
`master device’s pseudonym address BD_ADDR(2) as the
`piconet access code, the same as for slave device 118 and
`slave device 116. The address manager table 232 shown in
`FIG. 2 stores the user’s pseudonym address BD_ADDR(2)
`instead of its real BD_ADDR(0) for its relationship with
`Bluetooth device 120.
`
`[0028] The user’s device 100 in FIG. 1 is, itself, a parked
`slave device in a third ad hoc network piconet(3), with the
`master Bluetooth device 122. Although the user’s device
`100 does not have an active connection with the master
`device 122 in piconet(3), it does monitor the signals from the
`
`Nov. 21, 2002
`
`master device 122 to stay in synchronism with the master’s
`clock. The master device 122 uses its real Bluetooth Device
`Address BD_ADDR(E). If the user’s parked slave device
`120 were to rejoin piconet(3) as an active slave device, it
`would employ the master device’s real Bluetooth Device
`Address BD_ADDR(E) as the piconet access code. The
`address manager table 232 shown in FIG. 2 stores the user’s
`pseudonym address BD_ADDR(3) instead of its real
`BD_ADDR(0) for its relationship with Bluetooth device
`122.
`
`[0029] FIG. 1 shows the user’s Bluetooth device 100
`displaying the privacy options menu in the browser 102. The
`privacy options menu is rendered on the device’s display by
`the application program 106 of FIG. 3. The user can select
`one of two primary options:
`
`[0030] PRIVACY OPTIONS MENU
`[0031] SELECT OPTION:
`
`[0032] [A] NORMAL BLUETOOTH DEVICE
`ADDRESS
`
`[0033] [B] PSEUDONYM BLUETOOTH DEVICE
`ADDRESS
`
`[0034] If the user selects the PSEUDONYM BLUE-
`TOOTH DEVICE ADDRESS option in the privacy options
`menu in the browser 102, then the user can select one of five
`options in the PSEUDONYM ADDRESS OPTIONS SUB-
`MENU:
`
`[0035] [1]
`ADDRESS
`
`[0036] [2] KEEP MANUFACTURER CODE AND
`RANDOMIZE REST OF DEVICE ADDRESS
`
`[0037] [3] SELECT PARTS OF ADDRESS TO RAN-
`DOMIZE
`
`[0038] [4] ADDRESS RETENTION OPTIONS
`[0039] [5] RESET RANDOM NUMBER GENERA-
`TOR
`
`RANDOMIZE ENTIRE DEVICE
`
`[0040] The option [1] RANDOMIZE ENTIRE DEVICE
`ADDRESS from the privacy options menu in the browser
`102, randomizes the entire 48-bits of the user’s real
`BD_ADDR(0) to produce the pseudonym address.
`
`[0041] The 48-bits of the user’s real BD_ADDR(0) is
`partitioned into three parts: the 24-bit lower address part
`(LAP), the 8-bit upper address part (UAP), and the 16-bit
`nonsignificant address part (NAP). The 24 bits of the UAP
`and the NAP constitute the organization unique identifier
`(OUI), which is the manufacturer’s code. The remaining 24
`bits of the LAP are assigned internally by the manufacturer.
`If the user selects from the privacy options menu in the
`browser 102, the option [2] KEEP MANUFACTURER
`CODE AND RANDOMIZE REST OF DEVICE
`ADDRESS, then only the 24-bit LAP of the user’s real
`BD_ADDR(0) is randomized to produce the pseudonym
`address. If the user selects from the privacy options menu in
`the browser 102, the option [3] SELECT PARTS OF
`ADDRESS TO RANDOMIZE, then the user can select
`combinations of the LAP, UAP, and/or NAP of the user’s
`real BD_ADDR(0) to randomize to produce the pseudonym
`address.
`
`
`
`
`
`
`
`
`US 2002/0174364 Al
`
`[0042] Reference to FIG. 2B shows an example of the
`random number generator 230 operating on various selected
`parts of the user device’s BD_ADDR(0) stored in the buffer
`250. When the user makes a selection from the privacy
`options menu in the browser 102 in FIG. 1, the multiplexer
`252 connects to the selected part of the user device’s
`BD_ADDR(0) stored in the buffer 250 and applies the
`selected part to the input of the random number generator
`230.
`
`[0043] If the user seclects the option [4] ADDRESS
`RETENTION OPTIONS in the privacy options menu in the
`browser 102 of FIG. 1, then the user can select one of four
`options in the sub-menu:
`
`[0044] [a] CHANGE ADDRESSES AFTER A TIME
`“T”
`
`[0045] [b] CHANGE AFTER INQUIRIES/CONNEC-
`TIONS
`
`[0046] [c] CHANGE WHEN LOCATION CHANGES
`
`[0047] [d] OTHER OPTIONS TO CHANGE
`ADDRESSES
`[0048] If the user selects the option [a] CHANGE
`
`ADDRESSES AFTER A TIME “T” in the privacy options
`menu in the browser 102 of FIG. 1, then the pseudonym
`address can be retained for a predetermined time or count
`selected by the user. The method for carrying out this option
`is shown in steps 320 to 332 of the flow diagram of FIG. 3.
`
`[0049] If the user selects the option [b] CHANGE AFTER
`INQUIRIES/CONNECTIONS in the privacy options menu
`in the browser 102 of FIG. 1, then the pseudonym address
`can be retained for a duration that at least begins with an
`inquiry received from another device and ends if no con-
`nection is made after the inquiry. Similarly, if the user’s
`device initiated sending an inquiry message, the address can
`be retained for a duration that at least begins with the inquiry
`and ends if no connection is made after the inquiry. Pseud-
`onym addresses can be computed prior to when they are
`needed and then stockpiled by storage in the address man-
`agement table 234 in the user’s device 100. The user can also
`select that the address be retained for a duration that ends
`when a piconet context changes for the user’s device. When
`the user’s device 100 is the master device in a piconet, such
`as piconet(2) of FIG. 1, its pseudonym address will be used
`in the piconet access code. Thus, the user’s device 100 will
`retain the pseudonym address until the piconet is broken up
`or until the user’s device 100 relinquishes its role as the
`master device of that piconet. The user can also select that
`the pseudonym address be retained for a duration that at least
`begins with an inquiry that establishes a connection with
`another device, and ends when that connection is torn down
`or otherwise terminated. The method for carrying out this
`option is shown in steps 306 to 318 of the flow diagram of
`FIG. 3.
`
`[0050] If the user selects the option [c] CHANGE WHEN
`LOCATION CHANGES in the privacy options menu in the
`browser 102 of FIG. 1, then the pseudonym address can be
`retained for a duration that at least begins with the sensing
`of the current physical location of the user’s device by the
`sensor 132, and ends if that physical location changes
`beyond a predefined distance, such as the nominal radio
`broadcast range of ten meters for a Bluetooth device. The
`
`Nov. 21, 2002
`
`method for carrying out this option is shown in steps 306 to
`318 of the flow diagram of FIG. 3.
`
`[0051] The user can also select the option [d] OTHER
`OPTIONS TO CHANGE ADDRESSES in the privacy
`options menu in the browser 102 of FIG. 1. With any of
`these options [a], [b], [c], or [d], it is more difficult for an
`eavesdropper to track the usage of the user’s device or
`discover the real, unique BD_ADDR of the device.
`
`[0052] Ifthe user selects the option [S]RESET RANDOM
`NUMBER GENERATOR in the privacy options menu in the
`browser 102 of FIG. 1, then the user can introduce various
`parameters into the random number generator to change the
`random number sequence and thus thwart the eavesdrop-
`per’s discovery of that sequence.
`
`[0053] FIG. 2A is a functional block diagram of the user’s
`Bluetooth device 100 of FIG. 1, showing the various
`program modules stored in its memory 202 for the transport
`protocol group 214, middleware protocol group 224, and
`application group 234. The memory 202 is connected by the
`bus 204 to the Bluetooth radio 206, the keypad 104, the
`position