as) United States
`a2) Patent Application Publication co) Pub. No.: US 2005/0073522 Al
`(43) Pub. Date: Apr. 7, 2005
`
`Aholainen et al.
`
`US 20050073522A1
`
`(54) SERVICE/DEVICE INDICATION WITH
`GRAPHICAL INTERFACE
`
`(52) US. C1. enc eeneencseees 345/440; 345/581; 709/225
`
`(76)
`
`Inventors: Markus Aholainen, Pirkkala (FI); Arto
`Palin, Lempaaa (FI)
`
`(57)
`
`ABSTRACT
`
`Correspondence Address:
`MORGAN& FINNEGAN,L.L.P.
`3 World Financial Center
`NewYork, NY 10281-2101 (US)
`
`(21) Appl. No.:
`
`10/977,258
`
`(22)
`
`Filed:
`
`Nov. 1, 2004
`
`Related U.S. Application Data
`
`(63) Continuation of application No. 10/101,688, filed on
`Mar. 21, 2002.
`
`Publication Classification
`
`51)
`
`Int.
`
`Cl.”
`Nt. C1ee
`
`GO06T 11/20; GO9IG 5/00
`/00;
`.
`GO6F 15/173
`
`The method disclosed gives the user rapid notice of those
`Bluetooth devices within communication range, and yet it
`selectively blocks any notice about Bluetooth devices that
`the user wishes to ignore. Bluetooth server devices can
`indicate to the user’s Bluetooth client device the service the
`
`server device has available by sending service/device icon
`information to Bluetooth client device. This information can
`be a value in the class-of-device (CoD) field of a frequency
`hop synchronization (FHS) packet that it sends during the
`process of exchanging inquiry and paging packets with the
`Bluetooth client device. If the server device has begun by
`transmitting an inquiry packet, then the CoD value will be
`sent in its paging packet. If the server device is responding
`to an inquiry, then its CoD value will be in its inquiry
`response packet. Alternately, the service/device icon infor-
`mation can besent after a connection has been made with the
`client device, as part of a Service Discovery Protocol (SDP)
`response packet.
`
`
`
`
`BLUETOOTH
`
`ACCESS
`NETWORK
`
`
`POINT
`141
`
`
`
`140
`
`
`
`FHS PACKET WITH
`
`CoD=X("PRINTER")
`
`
`BLUETOOTH
`ACCESS
`POINT
`142
`
`PRINTER
`143
`
`PRINTER
`network
`‘CON Venoinc
`ICON
`ICON
`
`
`SIGNAL
`160
`STRENGTH.
`
` FHS PACKET WITH
`INDICATORS
`CoD=W("NETWORK")
`
`150
`
`152
`
`
`
`reno io|MOE
`
`BLUETOOTH
`
`FHS PACKET WITH V
`VENDING
`ACCESS
`
`
`MACHINE
`CoD=Y("VENDING")
`POINT
`
`154
`146
`
`
`144
`
`
`BLUETOOTH
`MOBILE
`DEVICE
`100
`
`BLUETOOTH
`ACCESS
`POINT
`
`146
`
`PRINTER
`147
`
`
`
`
`BLUETOOTH
`MOBILE
`DEVICE
`
`
`148
`
`
`
`APPLE 1106
`APPLE1106
`
`1
`
`

`

`Patent Application Publication
`
`Apr. 7, 2005 Sheet 1 of 7
`
`US 2005/0073522 Al
`
`
`
`431NladSSIDOV
`
`
`
`LeeINIOd
`
`SPL
`
`H1OO13N1¢a
`
`H10013N1a
`
`TNGOW
`
`JDIAIG
`
`ShL
`
`
`
`UaINRidssq0ov
`
`eee
`
`GagLNldd,)X=deD
`
`OSL
`
`ONIGN3IA
`
`ANIHDVW
`
`SPL
`
`HLOO13INIG
`
`SSdDDV
`
`INIOd
`
`bre
`
`/\HLIM1349vdSHI
`
`(,NIGN3A,)A=d°D
`
`vse
`
`HLOOLAN1g
`
`JON
`
`JDIAIa
`
`ooL
`
`ELINIOdHIM134OWdSHJ
`
`
`HLOOIANIaONIGN3ANoo!*~SOMI3N
`
`
`ss3d0vNOD!zoLNOOI
`Hioolanta|/\/\
`
`OrLTWNOIS
`(HYOMLIN.JM=00DSYOLVOIONI
`
`
`HIM13xDWdSHI~HLONYIS
` 2SL
`
`YaiNitd
`
`VL‘S14
`
`2
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Apr. 7, 2005 Sheet 2 of 7
`
`US 2005/0073522 Al
`
`aNIHOVIHIM1a4¥DWdSH4
`SteInto4(,DNIGN3A.)A=0°D
`©NIGNIASS399¥
`
`
`
`vSL-
`
`
`
`HIIAA1349VdSHI
`
`HLOOL3N1a
`
`HIOOLANIS
`
`SssaD9DV
`
`INIOd
`
`Ort
`
`
`
`43aLNiddSsaDOV
`
`
`
`eelINIOd
`
`oe
`
`HLOO13N1g
`
`
`
`HIIAA1349'VdSH4
`
`GUaLNId.)X=d99
`
`2S
`
`TWNOIS
`
`HIODNIYLS
`
`SYOLVDIQNI
`
`OLL
`
`ONIGN3IAe9L4O
`
`SYALNIdd
`
`MaLNldd
`
`
`
`NOOI43I9WNN
`
`
`HLOO13N1a(.U2INIdd.)X=ao9
`
`
`
`UaLNIad$$3909VGYNOISuanvaM)
`
`
`
`HLO013N18
`
`aJ1gOwW
`
`3D1A3G
`
`BbL
`
`
`
`LeeINIOdSSL
`
`OPL
`
`HLOOLAN1a
`
`JNaOW
`
`3ZO1A30
`
`OOL
`
`
`
`TIVIN¢YAVONIIVS
`
`POLGWdAIN
`
`ab“Sid
`
`3
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Apr. 7, 2005 Sheet 3 of 7
`
`US 2005/0073522 Al
`
`
`
`waINRdSSsaDOV
`
`
`
`eeliINIOd
`
`HLOOLANTa
`
`cPL
`
`HLOOLAINTS
`
`S$SJDOV
`
`INIOd
`
`OVL
`
`QINIGNIA
`
`ANIHOVIN
`
`StL
`
`HLOO1aMS
`
`SSIDIDV
`
`INIOd
`
`vel
`
`
`
`HUML3xOVdSHIHLONIYLS
`
`TWNOIS
`
`OLOH
`
`YaLNidd
`JNGOW
`
`wINILVOu
`
`NOOI
`
`
`vSLOLL
`
`(GONIGNIA.)A=d°9SYOLVDIGNI
`
`
`
`ZA
`
`HLOOLINTE
`
`JGOW
`
`JADIAId
`
`Sek
`
`
`
`GONLVG.)Z=0°9DJUSOW
`
`HLIM13NDVdSH4‘HLOOI3NT
`
`SSLJOIAIG
`
`ool
`
`HLOOLaNIg
`
`4a1NlddSszD9V
`
`felINIOd
`
`GuaiNnhd.)xX=a09
`HLIML3xDVdSH4
`
`StL
`
`OSL
`
`[\
`
`+868
`
`WAYVONITVD
`
`vOLGWdA3y
`
`4
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication Apr. 7, 2005 Sheet 4 of 7
`
`US 2005/0073522 Al
`
`F|G ?
`
`MOBILE eee 100
`
`APPLICATION GROUP 235
`
`NETWORK
`ICON
`160
`
`PRINTER
`ICON
`162
`
`VENDING
`ICON
`
`CoD=W
`
`CoD=X {CoD=Y }
`
`RESPONSE TABLE BUFFER
`246
`
`BLOCKINGFILTER TABLE
`BUFFER
`248
`
`SCREEN BUFFER 240
`
`MEMORY202 ICON CACHE244
`
`LINK
`MANAGER [ I
`218
`GSM PROTOCOL GROUP 215
`
`CURSOR COORDINATE
`BUFFER 242
`(Xc,Yc)
`
`SEARCH TABLE BUFFER
`250
`
`DETECTED ICON BUFFER
`252
`(TABLE A)
`
`MIDDLEWARE PROTOCOL GROUP 224
`
`TRANSPORT PROTOCOL GROUP214
`
`LOGICAL LINK CONTROL &
`ADAPTATION PROTOCOL 220
`
`Lo eee
`|
`- cme ae el
`
`BLUETOOTH
`RADIO
`206
`
`“ap
`
`CENTRAL
`PROCESSOR
`210
`
`DISPLAY
`SCREEN
`102
`
`CELLULAR
`TELEPHONE
`RADIO
`208
`
`5
`
`

`

`Patent Application Publication
`
`Apr. 7, 2005 Sheet 5 of 7
`
`US 2005/0073522 Al
`
`
`
`031931350NINOIWLYVdYdANaSMINNIdO
`
`‘9D‘YgdvGd24O!SGNV444iNdNOD!
`
`ISSY‘dINWISFIAIL
`
`
`
`S3ApleON
`
`SLE80€
`
`MINYSIHSI
`
`
`
`
`
`éuaayvaaNtNOIILEYd43AMaSHOV}JOADVNOIHO
`
`
`
`
`
`4345NINOD!G3L03190
`
`"JINILASW471<dINVLSAINLL-GOLdi
`
`
`
`
`
`
`
`ONVN3I4dDSWOdsNOOO!JAOW3aN3HL
`
`W309WO1s
`
`
`
`2zeoze43a44NgNOD!
`3AON03194130NISS3NGGY§.3113FNOISGNV
`
`
`
`
`AYOINSWNIJYO1SN3HL'O3AI393aN338
`
`zaano018SWH(HSNd‘93)31dG2LVIOOSSYNVdi(wv)
`G°9SIHLSIPZL
`
`
`
`
`
`
`
`
`
`
`
`G9dallsiHOud(dO)AVd-4O-3INIL
`
`
`
`
`¥OdJ1GVAYIdONIIDOWAOIHDFHLO1SdVLS3WILONINIVINGYTvalvadn
`
`
`
`BLEOLE
`
`
`
`
`
`NOILUYVdYAAYISYVITIO
`
`AVG-JO-JWILONYISSYJUNSVIN(S3AoS.ON
`
`$3
`
`vor
`
`22We‘Old
`
`zoe
`
`LeNJaa@LANDVdSHINVSVH
`
`
`434iN3AIZDIaADIHD
`é03A19934
`90€
`
`6
`
`
`
`
`
`

`

`Patent Application Publication Apr. 7, 2005 Sheet 6 of 7
`
`US 2005/0073522 Al
`
`S22
`
`déSid
`
`
`
`
`
`NOD!3193130NIdINVISAINIL3LWddn
`
`4344ng
`
`
`
`
`
`4344N@NODIG3L93130NIISsyJlvdadn
`
`
`
`OLLYOLVDIGNIISSYGalvddNAvidsid
`
`
`
`
`
`
`
`JHLHLIMSYaAM3SYOdAANVYYAAMASFSIAZY
`
`
`
`
`
`
`
`ISS4G31VGdNNOa3sva
`
`
`
`‘d°93WVS
`
`7
`
`
`

`

`Patent Application Publication
`
`Apr. 7, 2005 Sheet 7 of 7
`
`US 2005/0073522 Al
`
` €
`AV1dSI0 OVEBEE
`
`BPEove
`
` seeOaéNTAUISYSHLONV:
`
`
`
`SHDVDWOUNODISSADDV
`
`9DO1SNIQNOdSawdOD
`
`9£‘OH
`
`9€E
`
`
`
`S3AC22aveON
`
`éUgAUaS
`
`
`
`4AHLOYOINVHISSITISSHSI
`
`¢
`s
`£
`
`LNVHL431V3ed9ANVYY3AN3SNOISSV
`
`
`
`
`
`
`L=ANVYYFANNSNOISSY
`
`lVN3Ix¥DSNONOOI
`
`BIVNIGUOODA'X
`
`9
`S
`
`
`
`4344N@NOD!03193130
`
`NINOS!Y3HLOJOJIVNIGUOODA’X3YOIS
`
`SYJAM3aSYAHLO40ANVYHAASISIAI
`
`
`
`NOD!03193130NI3LYNIGUOODSA’XHOLS
`
`
`
`‘GODJINVSHLM
`
`43iina
`
`
`
`OLLYOLVDIGNIISSYAVIdSId
`
`434idNd
`
`2se
`
`NOS!03193130NIILVNIGUYOODA'XFUOLS
`
`
`
`
`OLLYOLVSDIONIISSYAVIdSId
`
`issdNOdisva
`
`
`
`OSEZPe
`
`Sd
`
`-fUre
`
`YO4SVIWVS0°DSI
`
`
`
`
`
`INNODNOOI-ILINWAv1dSIa
`
`NOD!ONUSIX]YVIN(S3A
`
`
`
`
`
`8
`
`
`
`
`
`
`
`
`

`

`US 2005/0073522 Al
`
`Apr. 7, 2005
`
`SERVICE/DEVICE INDICATION WITH
`GRAPHICAL INTERFACE
`
`FIELD OF THE INVENTION
`
`[0001] The invention disclosed broadlyrelates to ubiqui-
`tous computing and more particularly relates to improve-
`ments in short range RF technology.
`
`BACKGROUND OF THE INVENTION
`
`[0002] Bluetooth is a short-range radio network,originally
`intended as a cable replacement. It. can be used to create ad
`hoc networks of up to eight devices operating together. The
`Bluetooth Special Interest Group, Specification Of The Blue-
`tooth System, Volumes 1 and 2, Core and Profiles: Version
`1.1, Feb. 22, 2001, describes the principles of Bluetooth
`device operation and communicationprotocols. The devices
`operate in the 2.4 GHz radio band reserved for general use
`by Industrial, Scientific, and Medical (ISM) applications.
`Bluetooth devices are designed to find other Bluetooth
`
`devices within their ten-meter radio communications range
`
`
`and to discover what services they offer.
`
`[0003] A connection between two Bluetooth devices is
`initiated by an inquiring device sending out an inquiry
`message searching for other devicesin its vicinity. Any other
`Bluetooth device thatis listening by means of conducting an
`inquiry scan, will
`recognize the inquiry message and
`respond. The inquiry response is a frequency hop synchro-
`nization (FHS) packet containing all of the information
`required by the inquiring device to address the responding
`device. This information includes clock value of the sender
`(ie.,
`the responding device),
`the sender’s correct device
`access code, and the class-of-device (CoD) field. The FHS
`packet contains more information than is mentioned here.
`The access code includes the lower address part (LAP) and
`the upper address part (UAP) of the sender’s Bluetooth
`Device Address
`(BD_ADDR),
`a unique, 48-bit
`IEEE
`address that is electronically engraved into each Bluetooth
`device.
`
`
`
`[0004] The class-of-device (CoD) field of the FHS packet
`indicates which device class the sender belongs to, such as
`printer access point, network access point, PDA, cellular
`telephone, and the like. The class-of-device (CoD)field is a
`24 bit field divided into three subfields and a two-bit format
`
`field. The high order eleven bit subfield is reserved for
`indicating general service classes such as information,tele-
`phony, audio, object transfer, capturing, rendering, network-
`ing, and positioning. The middle five bit subfield comprises
`the majordevice class, which can indicate up to 32 different
`device types. The low order six bit subfield consists 1s the
`minor device class, which can indicate up to 64 different
`variations of each device type. The lowest order two bits are
`the format field for identifying the format type of the CoD
`field.
`
`it sends a paging
`[0005] The inquiring device (after
`packet) will become the master and the responding device
`will becomethe slave in the eventual piconet, if a connection
`is established. To establish a connection,
`the inquiring
`device must enter the page state. The paging device uses the
`information provided in the inquiry response packet,
`to
`prepare and send a paging message to the responding device.
`The paging device uses the estimated clock CLKE and
`access code of the responding device(i.e., the eventualslave
`
`device) to temporarily synchronize with it. Since the paging
`device intendsto be the master, it includes an assignmentof
`an active member address (AM_ADDR)in the paging
`message. The paging message sent by the paging deviceis
`also a frequency hop synchronization (FHS) packet contain-
`ing all of the information required by the responding device
`to directly reply to the paging device. This information
`includes clock value of the sender (i.e., the paging device)
`and the paging device’s correct device access code. The
`responding device mustbe in the page scanstate to allow the
`paging device to connect with it. Once in the page scanstate,
`the responding device will receive the paging packet that
`provides the clock timing and access code of the paging
`device. The responding device responds with a page
`acknowledgment packet. This enables the two devices to
`form a connection and both devices transition into the
`
`connection state. The paging device that has initiated the
`connection assumes the role of a master device and the
`
`responding device assumesthe role of a slave device in a
`new ad hoc network piconet, using the CLK clock timing
`and access code of the master device.
`
`[0006] Each piconethas one master device andup to seven
`active slave devices. All communicationis 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 eachother, 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 moveinto and out ofthe range of the
`master device. Piconets support distributed activities, such
`as multi-user gateways to the Internetor to a contentserver,
`wherein one device serves as the access point and is con-
`nected to an infrastructure network or content server. A
`
`user’s device that joins a multi-user gateway piconet, does
`so to enable its user to access the infrastructure network or
`content server.
`
`To form ad hoc connections, a Bluetooth device has
`[0007]
`to have the ability to rapidly discover target Bluetooth
`devices to which the user wishes to connect. In many cases
`the target device is known, e.g. a headset, and thus the
`procedure for connection establishment is straightforward.
`However, in certain cases it is not possible to have infor-
`mation about the target device. Additional problems are
`created by a crowded environment where many Bluetooth
`devices are present, which respond to the user device’s
`inquiries.
`
`[0008] What is needed a way to rapidly give the user
`notice of those Bluetooth devices within communication
`range, and yet not inundate the user with information about
`those Bluetooth devices that he/she wishes to ignore.
`
`SUMMARYOF THE INVENTION
`
`[0009] The invention disclosed gives the user notice of
`those Bluetooth devices within communication range, and
`yetit selectively blocks any notice about Bluetooth devices
`that
`the user wishes to ignore. In accordance with the
`invention, Bluetooth server devices can indicate to the user’s
`Bluetoothclient device the service that the server device has
`available by sending service/device icon information to
`Bluetooth client device. This information can be a value in
`
`9
`
`

`

`US 2005/0073522 Al
`
`Apr. 7, 2005
`
`the class-of-device (CoD) field of a frequency hop synchro-
`nization (FHS) packet that it sends during the process of
`exchanging inquiry and paging packets with the Bluetooth
`chent device. If the server device has begun by transmitting
`an inquiry packet, then the CoD value will be sent in its
`paging packet. If the server device is responding to an
`inquiry, then its CoD value will be in its inquiry response
`packet.
`
`[0010] The service/device icon is a small, graphic bitmap
`that is displayed onthe screen of the client device, having an
`appearancethat serves to describe the service that the server
`device has to offer. Altemately, the icon can also serve to
`identify characteristics of the user of the server device, such
`as business-related or personal characteristics. In either case,
`the icon bitmap must reside in the client device in orderto
`be displayed on its screen. For conventional services, such
`as an accesspoint for an Internet gateway or an access point
`for a printer, standard icon bitmaps can bestored in an icon
`cache in all Bluetooth client devices. Optionally, new icon
`bitmaps and their corresponding CoD values can be down-
`loaded from an Internet service provider, such as Nokia
`Club, to be stored in the icon cache of the client device in
`association with their CoD values. This can be, for example,
`a new graphical design of an icon for an existing, assigned
`CoD value, such as that for a printer. The service/device icon
`is typically a 16 by 16 pel bitmap. A black and white icon
`can be stored in a 32-byte memorypartition of the receiver’s
`icon cache. An eightbit per pel color icon can be stored in
`a 256-byte memory partition of the receiver’s icon cache.
`Audible tones can be played when the icon is iitially
`displayed. The tone string can be downloaded from the
`Internet service provider at the same time as is the icon
`bitmap and stored in the icon cache of the client device in
`association with the CoD value.
`
`[0011] Whenthe iconisinitially displayed onthe screen of
`the client device, a partition is opened in a detected icon
`buffer to store the status of the icon. A time stamp value is
`recorded at the start of the display, in association with the
`received CoD value. Periodically, the time stamp value is
`compared with the time of day clock of the client device.
`Whenthe time stamp is older than a threshold value called
`the lease-time (30 seconds,
`for example),
`the icon is
`removed from the screen andits partition is closed in the
`detected icon buffer. During the periodthat the icon remains
`actively displayed on the screen, if additional FHS packets
`are received from the same server device containing the
`same CoD value, the time stamp value is updated to the
`current time of day value. This enables retaining the display
`of an icon for a server device that remains in the vicinity of
`the client device. As soon asthe client device movesout of
`
`communications range of the server device and no more
`FHSpackets are received, then after the expiration of the
`lease-time, the icon is removed from the screen.
`
`If the client device has initiated a connection with
`[0012]
`the server device to carry out SDP searching or other
`operations, the client device assumes a temporary master
`role in its newpiconet. Mostserver devices are programmed
`to request a master/slave role switch if the client device has
`initiated the connection. Once the client changes to a slave
`role, it can only remain in its piconet, either as an active
`slave or a parked slave. (It is possible for the slave to switch
`between several piconets, when timing information is
`known.) Thus,the client device is programmed to terminate
`
`such connections after completing any necessary SDP
`searching or other operations. In order to continue display-
`ing icons of server devices within communications range,
`the client device continues to operate in the inquiry and page
`scanning modes, detecting the FHS paging packets and FHS
`inquiry response packets from server devicesin its vicinity.
`When the FHS packets from a given server device are no
`longer received, then the lease-time intervalis started in
`preparation to remove the corresponding icon from the
`display.
`
`[0013] The detected icon buffer also stores the Bluetooth
`device address BD_ADDRof the server device, in associa-
`tion with the received CoD value. The ith icon in the
`detected icon buffer has a device address BD_ADDRiand a
`CoD value CoDi. The detected icon buffer also stores
`coordinates, such as the (x,y) coordinates, of the displayed
`position of the icon with respect to the origin of coordinates
`on the screen, in association with the received CoD value.
`
`The ith icon on the screen hasa position (xi,yi) associated
`
`
`
`in the detected icon buffer with the its CoD value CoDi.
`
`
`
`Otherorigins for coordinates can be used, such as the center
`of the screen. Also, other coordinate systems can be used,
`such as polar coordinates. A cursoris also displayed on the
`screen, whose position is represented by coordinates, such as
`the (X,Y) coordinates with respect to the origin of coordi-
`nates on the screen. A pointing device, such as a mouse or
`a track ball controls the displayed position (X,Y) of the
`cursor on the screen. When the user presses the mouse
`button, the (X,Y) coordinates of the cursor are compared
`with the (x,y) coordinates of each icon in the detected icon
`buffer.If the cursor coordinates (X,Y) are within range of the
`ith icon coordinates (xi,yi), then the ith icon is selected. The
`client device can be programmed to access the device
`address BD_ADDRito complete the connection with the
`corresponding server device and exchange further messages
`with it. The further messages can include the client device
`sending an SDP request to the server device to find out
`information about other
`files or services,
`followed by
`accessing a file from the server device.
`
`[0014] Where the server device has initiated the connec-
`tion by sending inquiry and paging packets to the client
`device, the server device may use the Bluetooth object push
`profile (OPP) to push an unsolicited file, such as a business
`card, to the client device. The client device is programmed
`to store the unsolicited file in a unsolicited file buffer,
`associated with the CoD and the BD_ADDRofthe sending
`server device. The detected icon buffer opens a partition for
`the server device and stores an indication that there is an
`associated file in the unsolicited file buffer. When the user
`presses the mouse button,
`the (X,Y) coordinates of the
`
`cursor are compared with the (x,y) coordinates of each icon
`
`
`
`in the detected icon buffer. If the cursor coordinates (X,Y)
`are within range of the ith icon coordinates (xi,yi), then the
`ith icon is selected. The client device can be programmedto
`check if there is an associated file in the unsolicited file
`
`
`
`
`buffer. If there is, that file is accessed and displayed on the
`screen. This feature enables the server device to send more
`
`informative messages to the client device, along with the
`CoD of the icon bitmap.
`
`[0015] The detected icon buffer also stores a server rank
`value, in association with the received CoD value. Thefirst
`server device of a given CoD type to be entered into the
`detected icon buffer will be assigned the a server rank value
`
`10
`
`10
`
`

`

`US 2005/0073522 Al
`
`Apr. 7, 2005
`
`of “1”. Two different server devices having different device
`addresses BD_ADDR,can offer the same service and will
`transmit the same CoD value. The client device is pro-
`grammed to identify this circumstance. The second server
`device of the same CoD type to be entered into the detected
`icon buffer will be assigned the a server rank value of “2”,
`and so on. Instead of placing two identical icon bitmaps on
`the screen,the first displayed icon will have appended to it
`a numeral indicating how manyofthat type of server device
`are in the vicinity. The displayed icon is referred to as a
`multi-icon.
`
`[0016] The detected icon buffer also stores a received
`signal strength indication (RSSI) for each respective server
`devicelisted in the detected icon buffer. Where there are two
`or more server devices in the detected icon buffer having a
`given CoD type, the client device is programmed to rank
`them by their RSSI values. The server rank values of those
`servers having the same type CoD value are reassigned,in
`accordance with the RSSIfor each server device. The server
`device with the strongest RSSI will be reassigned a server
`rank value of “1”, and weaker server devices will be
`assigned consecutively greater values. When the cursor
`coordinates (X,Y) are within range of the multi-icon’s
`coordinates(xi,yi), then the multi-icon is selected. The client
`device can be programmed to access the device address
`BD_ADDRiofthe server device with the strongest RSS] to
`complete the connection with the corresponding server
`device and exchange further messages with it. As individual
`server devices move out of communication range of the
`chent device, the respective partition in the detected icon
`buffer is cleared, and the server rank values are reassigned,
`as needed.
`
`[0017] The RSSI value can be displayed beneath each icon
`shown on the screen, thereby allowing the user to select
`server devices having better link quality. Alternately, “color
`bars” can be presented to represent RSSI values, such as
`green=good RSSI, yellowsstill acceptable, and red=data
`ransmissionis not possible. Any kind of indication of RSSI
`eading is possible (e.g. actual value, numberof bars, color
`etc)
`
`
`
`[0018] The user can enter CoD values for types of server
`devices or services to be ignored, such as advertisement
`broadcasting server devices and certain types of vending
`machine server devices. These prohibited CoD values are
`stored in a blockingfilter buffer in the client device. When
`a CoD value is received in an FHS packet, it is compared
`with the prohibited CoD values and if there is a match, no
`entry is made in the detected icon buffer, thereby ignoring
`the prohibited server devices.
`
`
`
`[0019] There are up to eleven bits available in the CoD
`
`field for assignmentas service descriptions, yielding up to
`
`2048 different possible services that can be represented.
`Some subset, for example the six bits of the CoD minor
`device class sub-field, can be usedto assign up to 64 service
`description values.
`
`
`
`[0020] Whenthe icon servesto identify characteristics of
`the user of the server device, such as business-related or
`personal characteristics, the device can be optionally pro-
`grammed to accept manual changes to the CoD field. The
`ser of the sending device has the ability to select the icon
`to be sent. Optionally, the server device can be manually
`reset by its user to indicate in its class-of-device (CoD)field
`
`of its FHS packet, that particular types of service/device icon
`information are available, such as dating/match-making
`information.
`
`[0021] The client device can also be programmed to
`search for specified class-of-device (CoD) values received
`from a server device. The client device can match the CoD
`
`values received in FHS packets, with an entry in a searchlist
`in the client device. For example, the client device can be
`programmed byits user to search for that particular class-
`of-device (CoD) value among those CoDs received. When a
`match is found, the client device is programmed to display
`the icon bitmap and sound an alarm tone.
`
`In the current Bluetooth specification, an inquiry
`[0022]
`result is reported over the Host Computer Interface (HCI)
`only after the inquiry period is over, whichis 10.24 seconds.
`During that period, it maybe possible that the client device
`will move out of the range of the server device. In another
`aspect of the invention, the receipt of FHS packetsis a result
`event that is reported over the HCI as soon as each new FHS
`packetarrives. The HCI is programmedto write the received
`CoD value of the FHS packet in a memory register at the
`time that the packet arrives. The Host can then read the
`register and process the CoD value to display the corre-
`sponding icon, as described above.
`
`[0023] The client device can be programmedbyits user to
`recognize selected class-of-device. (CoD) values andeither
`ignore them or display the corresponding icon bitmap.
`
`In an alternate embodiment of the invention, the
`[0024]
`service/device icon information can be sentafter a connec-
`tion has been made with the client device, as part of a
`Service Discovery Protocol (SDP) response packet. The
`client device can search for interesting services using the
`Service Discovery Protocol (SDP). When interesting ser-
`vices are found, their service records are accessed by the
`client device. Icons are included in the service records as an
`
`IconURL parameter. Icons can be loaded using hypertext
`transfer protocol (http). If there is no icon included in the
`service record of an interesting service, a default icon forits
`type maybe displayed,as identified by the CoD value ofthe
`sending device.
`
`[0025] The process of retrieving the icon bitmap in the
`Service Discovery Protocol (SDP) ofthe alternate embodi-
`ment, starts by examining the public browserootof the SDP
`service registry in the server device. It then follows the
`hierarchy outto service classes whichare the branchesof the
`tree, and from there to the leaf nodes, where individual
`services are described in service records. To get specific
`information about the icon bitmap, the client device and the
`server device exchange messages carried in SDP packets.
`There are two types of SDPpackets, the SDP Service Search
`Attribute Request packet and the SDP Service Search
`Attribute Response packet. The SDP Request packetcarries
`the SDP Service Search Attribute Request, which includes a
`service search pattern and an attribute ID list. The service
`search pattern is the description of the desired service
`records containing the icon bitmap informationin the server
`device. The server device specifically searchesits registry of
`for
`the attribute containing information about
`the icon
`bitmap. The server device responds with the service handle
`of the icon bitmap or a pointer to the icon bitmap. The
`service handle identifies the service record containing the
`icon bitmap. Optionally,
`the service record contains a
`
`11
`
`11
`
`

`

`US 2005/0073522 Al
`
`Apr. 7, 2005
`
`pointer to the icon bitmap. When the client device receives
`the icon bitmap, it is displayed on the screen. Optionally,it
`can also be stored in the client’s icon cache.
`
`DESCRIPTION OF THE FIGURES
`
`[0026] FIG. 1A showsa wireless network diagram ofthe
`Bluetooth mobile client device and five server devices, with
`he mobile device being within Bluetooth communication
`ange of a network accesspoint, a first printer access point,
`and a vending machine access point, according to an
`embodiment of the present invention.
`
`[0027] FIG. 1B showsthe same wireless network as FIG.
`1A, but with the mobile client device having moved out of
`he range of the network access point and into range with a
`second printer access point.
`
`[0028] FIG. 1C shows the same wireless network as
`FIGS. 1A and 1B,but with the mobile client device having
`further moved out of the range of both the network access
`point and the first printer access point, and into range with
`a second mobile device.
`
`[0029] FIG. 2 shows the memorylayout of the mobile
`chent device, according to an embodiment of the present
`invention.
`
`
`
`
`[0030] FIGS. 3A, 3B, and 3C showthe flow diagram of
`he operation of the mobile chent device, according to an
`embodiment of the present invention.
`
`DISCUSSION OF THE PREFERRED
`EMBODIMENT
`
`In the following description of the preferred
`[0031]
`embodiment, reference is madeto the accompanying draw-
`ings, which form a part hereof, and in which is shown by
`wayofillustration various embodiments in which the inven-
`ion may be practiced. It is to be understood that other
`embodiments maybe utilized and structural and functional
`modifications may be made without departing from the
`scope of the present invention.
`
`[0032] The invention disclosed gives the user notice of
`hose Bluetooth devices within communication range, and
`yet it selectively blocks any notice about Bluetooth devices
`hat the user wishes to ignore. FIG. 1A showsa wireless
`network diagram of six Bluetooth devices:
`the user’s
`mobile, client device 100, four access point devices con-
`nected to their
`respective servers, and another mobile
`device. Access point 140 is connected to the network 141.
`Access point 142 is connected to the printer 143. Access
`point 144 is connected to the vending machine 145. Access
`point 146 is connectedto the second printer 147. The second
`mobile device 148 can be a Bluetooth equipped cellular
`elephone. In the first location of the mobile device 100
`shown in FIG.1A,the user’s mobile device 100 is within
`he Bluetooth communication range of the network access
`point 140, the first printer access point 142, and the vending
`machine access point 144.
`
`
`
`[0033] The four Bluetooth access point devices 140, 142,
`144 and 146 and the Bluetooth mobile device 148 of FIG.
`1A are collectively referred to here as “server devices”, for
`convenience. In accordance with the invention, the server
`devices can indicate to the user’s Bluetooth client device
`the-type of service that the server device has available by
`sending service/device icon information to Bluetooth client
`device. This information can be a value in the class-of-
`device (CoD) field of a frequency hop synchronization
`
`(FHS)packet that it sends during the process of exchanging
`inquiry and paging packets with the Bluetooth client device.
`If the server device has begun bytransmitting an inquiry
`packet, then the CoD valuewill be sentin its paging packet.
`If the server device is responding to an inquiry, then its CoD
`value will be in its inquiry response packet. The network
`access point 140 sends the FHS packet 150 to the user’s
`mobile device 100, with a CoD value of “W”indicating by
`convention that
`the access point 140 is connected to a
`network 141. The first printer access point 142 sends the
`FHSpacket 152 to the user’s mobile device 100, with a CoD
`value of “X” indicating by convention that the access point
`142 is connected to a printer 143. The vending machine
`access point 144 sends the FHS packet 154 to the user’s
`mobile device 100, with a CoD value of “Y”indicating by
`convention that
`the access point 144 is connected to a
`vending machine 145.
`
`[0034] The user’s Bluetooth mobile device 100 of FIG.
`1A includes an antenna 103, keypad 104, mouse or pointer
`device 106, and a displayscreen 102. The display screen 102
`presents calendar functions, mail functions, and other user
`applications to the user. In accordance with the invention,
`when the user’s device 100 receives the FHS packet 150
`with a CoD value=“W”, a corresponding network icon 160
`is displayed on the screen 102. When the user’s device 100
`receives the FHS packet 152 with a CoD value=“X”, a
`corresponding printer icon 162 is displayed on the screen
`102. When the user’s device 100 receives the FHS packet
`154 with a CoD value=“Y”, a corresponding vending icon
`164 is displayed on the screen 102. Signal strength indica-
`tors 170 canalso be displayed on the screen 102 nextto the
`icons 160, 162, and 164,
`indicating the relative signal
`strength of the respective FHS packets 150, 152, and 154.
`
`[0035] The service/device icons 160, 162, and 164 in FIG.
`1A are each a small, graphic bitmapthat is displayed on the
`screen 102 of the client device 100, having an appearance
`that serves to describe the service that the respective server
`device 141, 143, and 145 hasto offer. Altern