as) United States
`a2) Patent Application Publication co) Pub. No.: US 2005/0250552 Al
`
` Eagle et al. (43) Pub. Date: Nov. 10, 2005
`
`
`US 20050250552A1
`
`(54) COMBINED SHORT RANGE RADIO
`NETWORK AND CELLULAR TELEPHONE
`NETWORK FOR INTERPERSONAL
`COMMUNICATIONS
`
`(75)
`
`Inventors: Nathan Norfleet Eagle, Boston, MA
`(US); Alex Paul Pentland, Lexington,
`MA(US)
`
`Related U.S. Application Data
`
`(60) Provisional application No. 60/568,482,filed on May
`6, 2004.
`
`Publication Classification
`
`Inte C0?eecccccccccceeeeesscccessssnnnseeceesnssnnnnensss G03F 3/08
`(SV)
`(52) US. Che ec ceccesssscsseeseeseessesnseneesseenesnneeneees 455/567
`
`Correspondence Address:
`CHARLES G. CALL
`68 HORSE POND ROAD
`WEST YARMOUTH, MA 02673-2516 (US)
`,
`(73) Assignee: Massachusetts Institute of Technology,
`Cambridge, MA
`
`(57)
`
`(21) Appl. No.:
`
`(22)
`
`Filed:
`
`11/122,630
`
`ABSTRACT
`. .
`Portable communication devices, such as Bluetooth enabled
`cellular phones, communicate with and identify like devices
`that are nearby, and send notification messages to a remote
`server. Whena notification messageis received at the server
`identifying two devices that have come within range of one
`another, the server comparesthe profile data associated with
`each of the two identified devices and facilitates communi-
`cations between the devices when appropriate.
`May5, 2005
`
`
`
`
`Bluetooth ID_|Password |Name_
`[Contact Info Demographics] Interests Preferences
`
`
`
`
`
`
`KIT-KA
`
`
`
`
`Detect
`Arriving Device
`
`'
`
`
`
`
`Receive
`Notification
`
`
`
`
`Alert One or
`Both Devices
`
`Based on
`Preferences
`
`!1II111 i1111I
`
`223
`
`Post to
`Device Log
`
`Devices Log
`Bluetooth ID
`00E09885E388
`IT-KAT]
`|BARON| 0050F2E17654
`|JACKY|107FO0AQORE23
`
`|SUPRV|0678EA987F993 11
`
`Devices
`
`
`
`240
`
`!|1
`d|3
`i|0|K
`\|2
`
`Logtime Log
`
`214
`
`|0|2004/2/29 12:59:54
`|1 [2004/2/29 13:09:21
`|0] 2004/2/29 15:15:44
`|3 [2004/2/29 15:17:07]
`
`Google Exhibit 1005
`Google Exhibit 1005
`Google v. SecCommTech
`
`Google v. SecCommTech
`
`11I11II1I1I|
`
`

`

`Patent Application Publication Nov. 10,2005 Sheet 1 of 2
`
`US 2005/0250552 Al
`
`OS iz
`ou |&
`Eo
`Bei
`
`>
`
`°
`
`
`
`
`2
`oS
`lL:
`
`i
`
`
`=
`2
`~
`
`—
`"
`>
`Li
`
`w
`
`=_
`
`
`
`to [9x|
`5g |Fe=
`—!
`|
`Ww
`mea
`isis
`oo ang x S|
`ES ies|
`=
`joo
`
`[
`
`
`
`

`

`Patent Application Publication Nov. 10,2005 Sheet 2 of 2
`
`plousesupayjuepiy—_Jejsenbox
`
`
`0z00]€664/86V38/90]986398860300
`
`
`
`
`
`y9}8q
`
`
`US 2005/0250552 Al
`
`c“bls
`
`108UQHealy
`
`
`
`SadlAeqjog
`
`saolaeq
`
`S80UBIBJOId
`uopaseg
`
`SAIYOudauedwieg8BASLIOY
`
`anleoay
`
`UONBOYNON
`
`ployseys
`
`
`
`—/------------------- - 9 - -+
`oO
`
`+N
`
`O}SOY
`
`
`
`Bo7]so1aeq
`
`
`
`
` €664286V38290|AYdNS|e|ezauoovo0sz0l|ANOve[2||S9Zb3c40S00|NOUVS||_||88€3S8860300[IVHLIy|O_||iyoojanig|ewen[ON
`£72Bo7ssoineq
`6z/e/vO0c|0||duesowt,[ON|vbz6o7ewunbo7q
`
`ZO-L4:S-_6e/e/v00|€|6e/e/v00~|0_|
`LZ:60:€16z/e/r00c!|||vS:6S:cl
`
`
`a0lAaqBulaluy
`
`
`
`
`
`
`
`
`
`

`

`US 2005/0250552 Al
`
`Nov.10, 2005
`
`COMBINED SHORT RANGE RADIO NETWORK
`AND CELLULAR TELEPHONE NETWORK FOR
`INTERPERSONAL COMMUNICATIONS
`
`CROSS REFERENCE TO RELATED
`APPLICATIONS
`
`[0001] This application is a Non-Provisional of, and
`claims the benefit of the filing date of, U.S. Provisional
`Patent Application Ser. No. 60/568,482 filed May 6, 2004,
`the disclosure of which is incorporated herein by reference.
`
`FIELD OF THE INVENTION
`
`[0002] This invention relates to systems for facilitating
`direct communications between consenting persons having
`similar interests.
`
`SUMMARYOF THE INVENTION
`
`Inits preferred form, the present invention employs
`[0003]
`body-worn personal networking devices, such as Bluetooth
`enabled cellular phones, that are able to communicate with
`and identify other such devices that are nearby. When a
`device is within range of another such device, it identifies
`itself with unique identification value, such as a Bluetooth
`device address value.
`
`[0004] Each cellular phone keeps a log of other devices
`that have been previously detected and, whenever a new
`device comes within range, a notification message is trans-
`mitted to a remote server via the long-range cellular phone
`network. The notification message contains an identification
`of both the requesting device and the nearby device whose
`presence has been detected. It may also include one or more
`values indicating the operating mode of the requesting
`device, e.g., a silent mode, an invisible mode, a meeting
`mode,etc. In addition, the transmitted indication preferably
`includes a value which indicates the user’s willingness to
`receive alert messages from the server when new devices
`come within range.
`
`Profile data that describes each device and its
`[0005]
`owneris stored in a database. When a notification message
`is received identifying two devices that have come within
`range of one another,
`the server fetches the profile data
`associated with each of the two identified devices and
`performs a comparison. The comparison generates a calcu-
`lated value indicating the extent to which the two profiles
`match. This comparison operation may use different weight-
`ing schemes depending on the modeofthe requesting device
`to determine the type of interaction to enable.
`
`to
`If the calculated value indicating the extent
`[0006]
`which the two profiles match exceeds a threshold value
`currently associated a given device, an alert message is
`transmitted to that device. The user of each device mayalter
`the mode and threshold values to change the behavior of the
`device.
`
`[0007] The alert message sent to each device from the
`server may contain information describing the nearby device
`to the extent the owner of that device has consented to its
`being revealed. Each person supplying profile information
`can supply preference values indicating the extent to which
`provided information is shared, and each person can provide
`a threshold value indicating the extent to which the profile
`of a detected nearby device must match the interests of the
`
`requestor before an alert message is to be sent. The alert
`message may include information identifying an encoun-
`tered device or its owner, such as name, address or other
`contact
`information, a photograph or other descriptive
`image, demographic data, data indicating the interests of the
`ownerofthe device, or any other information whichis of use
`in a specific application maybeofuse to identify, or promote
`communications between, nearby devices and their owners.
`
`the growing
`invention can exploit
`[0008] The present
`availability of portable wireless electronic devices that
`incorporate Bluetooth transceivers that can be used as bea-
`cons to identify a device to other nearby devices. Such
`personal beacon system offer better short range spatial
`resolution for proximity detection than do absolute location
`systems, such as GPS and cellular phone location systems.
`The fact that the beacons transmit only device identification
`codes avoids some privacy problems since these codes do
`not contain information about
`the users. Moreover,
`the
`detection and introduction service contemplated by the
`present invention can also be used in poor reception areas,
`where only asynchronous communications such as SMS
`(Short Message Service) function properly.
`
`the performance of
`[0009] The storage of profile data,
`matching functions, message transmission, and other func-
`tions at a shared central server offers several advantages over
`systems which rely on the portable devices themselves for
`storing and sharing information. The performance of func-
`tions using a centralized infrastructure reduces the compu-
`tational burden and consequent power consumption to which
`the battery powered portable devices are subjected. The
`centralized structure can be more easily updated and is
`capable of performing more sophisticated comparison and
`notification functions using more complete data. The robust
`capabilities of web servers, applications servers and data-
`base servers may be used to advantage to provide better
`performance from the individual devices, as well as func-
`tions such as improved privacy protection, profile editing,
`report generation, data analysis and system management
`functions not possible using the limited capabilities of the
`portable devices alone.
`
`[0010] The preferred embodiment of the present invention
`described in more detail below uses personal area wireless
`network devices such as Bluetooth transceivers to identify
`social proximity and a large area wireless network such as
`a cellular phone network and/or the Internet,
`to permit
`interest matching functions to be performed at a remote
`central server and to instigate person-to-person interactions
`between selected devices that are near to each other and/or
`between their users.
`
`{0011] The preferred embodiment of the invention con-
`templates the use of body-worn personal area wireless
`devices interconnected with a server by a long-range net-
`work to map social networks and social network dynamics.
`This enables verification and automatic augmentation of the
`links in existing social network applications such as Tacit-
`.com, friendster.com and Match.com which are already in
`widespread use. These rapidly growing Internet based appli-
`cations currently suffer from a problem that they obtain their
`data from users who enter that data at the keyboards of
`connected PCs, but they lack the ability to (1) add links
`automatically, and (2) verify that the links are based on a
`selection criteria that is useful to service users. The present
`
`

`

`US 2005/0250552 Al
`
`Nov.10, 2005
`
`invention supplies that need by providing an automatic
`mechanism for establishing and verifying links automati-
`cally between people whoare physically near to one another.
`
`In accordance with a feature of the preferred
`[0012]
`embodiment of the invention, service users can also asso-
`ciate weighting values with the information about them-
`selves and others, and use these weighting valuesto specify
`the information’s importanceto be assignedto different data
`when calculating a similarity metric. The similarity score is
`calculated by extracting the commonalities between two
`users’ profiles and summed using the user-defined weighting
`values. If the similarity score is above the threshold set by
`one or both users, the server alerts the users that there is
`someonein their proximity that they would like to meet. The
`thresholds and the weighting schemethat defines the simi-
`larity metric can be specified using a web interface and can
`be reset as needed using a cellular phone. The user can also
`vary the mode of operation of the cellular phoneto control
`the frequency and content of the alert messages that are
`transmitted by the server when different devices come
`within range of one another.
`
`[0013] These and other features, advantages and potential
`applications of the present invention will be better under-
`stood by considering the following detailed description.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`In the detailed description which follows, frequent
`[0014]
`reference will be made to the attached drawings, in which:
`
`[0015] FIGS. 1a, 1b, and 2c illustrate cellular phone
`screen displays produced in the course of operating an
`illustrative preferred embodimentof the invention; and
`
`illustrates the
`[0016] FIG. 2 is a block diagram that
`principal components of a system that
`implements the
`invention.
`
`DETAILED DESCRIPTION
`
`[0017] Portable Device Operation
`
`In the illustrative embodiment of the invention
`[0018]
`described in detail below below, people who use the system
`are provided with cellular telephones which incorporate
`short range radio transceivers that use the Bluetooth protocol
`to detect other nearby Bluetooth enabled devices.
`
`[0019] Each of these Bluetooth enabled cellular phones
`includes a processor that is specially programmed with an
`application program, called “BlueAware,” that enable the
`cellular phone to identify and log the presence of other
`“discaverable” Bluetooth devices that are nearby, and to
`display an identification of those devices on the cell phone’s
`screen as illustrated in FIG.1a.
`
`[0020] Each of these cellular phones is further pro-
`grammed to generate a notification message identifying
`itself, and other Bluetooth devices that come within its
`range, as well as additional status information. The appli-
`cation program that executes on the cellular phone processor
`then transmits that notification message via the long-range
`cellular network to a remote central server. The remote
`server processes these incoming notification messages by
`consulting a database of profile information about each
`participating device and its owner(as used herein, the term
`“owner” is used to refer to the person who uses the device
`and who supplies profile information about themselves to
`
`the central server.) When the remote server receives a
`notification message indicating that two identified devices
`are within Bluetooth range of one another, and further
`determines that the profile data associated with these two
`devices satisfies a specified matching criteria, the remote
`server sends an alert message to one or both of the two
`identified nearby devices.
`
`[0021] As illustrated by FIG. 1b, the alert message may
`advantageously include a picture of the owner of the match-
`ing nearby device that is displayed on the cellular phone’s
`screen after the alert message is received, facilitating a
`personal contact between the two nearby device owners. In
`addition, as illustrated in FIG. 1c, the alert message may
`include displayable data indicating commoninterests of the
`two nearby users.
`
`[0022] FIG. 2 shows the operation of the overall system.
`A first individual 203 carries a first Bluetooth phone which
`detects a second Bluetooth phone carried by a second
`individual 205. The BlueAware application program that
`executes on the Bluetooth phonecarried by the first person
`203 id illustrated in simplified form within the dashed-line
`rectangle 210 in FIG.2. As seen at 211, when the presence
`of a nearby device is detected, its Bluetooth device ID (a
`unique 48 bit Bluetooth device address value assigned to and
`stored on each device) is compared with the Bluetooth ID’s
`previously stored in a Devices Log data structure seen at 214
`maintained by the BlueAware program.
`
`If it is determined at 216 that a detected nearby
`[0023]
`device has newly come within range and not currently
`identified in the Devices Long 214,
`its Bluetooth ID is
`posted at 217 as a new Devices Log entry and a request
`message is sent as indicated at 218 to a remote server, seen
`at 220 in FIG.2, via the cellular phone network 222. The
`time at which the new device was detected is recorded as
`seen at 223 in a Logtime Log 240 which holds a device
`identification number (from the Devices Log) and a time
`stamp value. If the detected device is already recorded in the
`Devices log 214, a timestamp indicating the time of detec-
`tion is recorded in the Logtime Log 240, along with the
`device number assigned to that device in the Device Log
`214.
`
`[0024] Using the mechanism described above, a sequence
`of timestamp values may be recorded for each device
`encountered, and the BlueAware application may process
`this data to determine whether the detection of a given
`device warrants the transmissionofa notification message to
`the server. To conserve memory space,
`the BlueAware
`application may periodically remove identification and
`timestamp data for devices which have been out of range for
`an extended time.
`
`[0025] Thus, the proximity log is split into twofiles, the
`Devices Log 214 listing ID values (device addresses and
`device names) and the Logtime log 240listing timestamps.
`The Devices Log 214 indexes every device encountered by
`the phone. The individual encounters are timestamped and
`linked to the indexed number of the device in the Logtime
`log 240. Simply assigning a single number to each device
`eliminates the need to log the BTID and device nameafter
`each encounter. This method was shown to dramatically
`lowerthe size of the proximity log. Example data of the kind
`that might be recorded in the two proximity logs islisted in
`Table 1, below.
`
`

`

`US 2005/0250552 Al
`
`Nov.10, 2005
`
`‘TABLE 1
`
`Logging information format
`
`BTdevices.log
`[addr] 00c09885e388
`0 [name] KIT-KAT
`1 [name] BARAHONA-IBM [addr] 0050£2¢17654
`2 [name] Nokia3650
`[addr] 0060573c1c4e
`3 [name] NORTHOLT
`[addr] 000d888ea558
`BTlogtime.log
`0 <2004/2/29 12:59:54>
`1 <2004/2/29 12:59:54>
`2 <2004/2/29 12:59:54>
`3 <2004/2/29 12:59:54>
`
`[0026] Continually scanning and logging the environment
`for BTIDs can expend an older mobile phone battery in
`about 18 hours. While continuous scans provide a rich
`depiction of a user’s dynamic environment, mostindividuals
`are used to having phones with standby times exceeding 48
`hours. Therefore, the BlueAware application programthat
`executes on each cellular phone scans the environment once
`each minute to reduce battery consumption.
`
`[0027] Bluetooth Identification of Nearby Devices
`
`[0028] Bluetooth transceivers that are typically built into a
`single microchip and operate within a globally available
`frequency band. Detailed information on the structure and
`function of devices conforming to the Bluetooth protocol
`can be found at www.bluetooth.org. Programmable cellular
`phonesare also widely available that incorporate program-
`mable processors which execute the Symbian Operating
`System. The Symbian OS is the global industry standard
`operating system for smartphones, and is licensed to the
`world’s leading handset manufacturers, which account for
`over 80 percent of annual worldwide mobile phonesales.
`The Symbian OS is available from Symbian Software,
`Bridge Park Center, 390 Bridge Parkway, Redwood Shores,
`Calif. 94065. Cellular phones incorporating Bluetooth trans-
`ceivers and using the Symbian OSare currently available
`from many cellular phone manufacturers, including Nokia,
`Motorola, Sony Erickson, Panasonic and Lenovo, andare in
`widespread use.
`
`called
`(here
`program
`application
`[0029] The
`thal runs on each cellular phone can be
`“BlueAware”)
`downloaded from a server operated by the service provider
`via the cellular network, or may be transferred via the
`Bluetooth link or an infrared link from a friend’s device, or
`from a device provided at an entryway to an event, such as
`the registration desk of a tradeshow. After the BlueAware
`software has been newly installed on a give device, it can
`automatically register itself with the remote server, trans-
`ferring its Bluetooth device address and device nameto the
`server, and creating a profile data template which can then
`be populated with data by the device owner using the
`cellular phone or using a PC as illustrated by the PC 290
`seen in FIG. 2 which is connected to the server via the
`Internet 295.
`
`[0030] The Bluetooth specification defines two power
`levels: a lower power mode with a range of about 10 meters
`for covering a personal area within a room, and a higher
`power level with a range of about 100 meters covering a
`larger area, such as a homeoroffice. Software controls and
`identity coding built into each microchip ensure that only
`
`those units preset by their owners can communicate, and
`provide a mechanism for identifying other devices that are
`within range. In a crowded room, the effective range of
`Bluetooth low powertransmission may decrease substan-
`tially from the nominal 10 meter range—but reduced range
`in a crowded room can frequently be beneficial.
`
`[0031] Bluetooth devices are identified by a unique iden-
`tification code values. Each Bluetooth device is specified by
`a unique 48-bit Bluetooth Device Address (BD_ADDR),
`whichis typically displayed as 12 hexadecimaldigits as seen
`in Table 1 above. Each Bluetooth device further stores and
`
`can reveal a “user friendly” displayable Bluetooth Device
`Namewhich can be up to 248 bytes long, although external
`devices are not expected to be able to handle or display more
`than 40 characters. Still further, each device is assigned a
`Bluetooth passkey (Bluetooth PIN) whichis used to authen-
`ticate two Bluetooth devices (that have not previously
`exchanged link keys) to each other and create a trusted
`relationship between them.
`
`[0032] Bluetooth devices are further specified by a Class
`of device parameter received during the device discovery
`procedure and indicating the type of device and the types of
`service that are supported. The information within the Class
`of Device parameter is referred to as ‘Bluetooth Device
`Class’ (i.e.
`the major and minor device class fields) and
`‘Bluetooth Service Type’ (i.e. the service class field).
`
`[0033] Bluetooth devices are capable of performing an
`inquiry function to determine the identity and Device Class
`of other “discoverable” Bluetooth devices which are in
`
`range. With respect to inquiry, a Bluetooth device shall be
`either in non-discoverable mode or in a discoverable mode;
`that is, the device shall be in one, and only one, discover-
`ability mode at a time. The two discoverable modes are
`called limited discoverable mode and general discoverable
`mode. When a Bluetooth device is in non-discoverable mode
`
`it does not respond to inquiry. A Bluetooth device is said to
`be made discoverable, or set into a discoverable mode, when
`it is in limited discoverable modeor in general discoverable
`mode. Even when a Bluetooth device is made discoverable
`it may be unable to respondto inquiry due to other baseband
`activity. A Bluetooth device that does not respond to inquiry
`for any of these two reasonsis called a silent device.
`
`[0034] Bluetooth devices are capable of performing dif-
`ferent types of inquiries called (1) a general inquiry, (2) a
`limited inquiry, (3) a name inquiry,(4) device discovery, and
`(5) bonding. The purposeof the general inquiry procedureis
`to provide the initiator with the Bluetooth device address,
`clock, Class of Device and used page scan mode of general
`discoverable deviccs (ic. devices that are in range with
`regard to the initiator and are set
`to scan for inquiry
`messages with the General Inquiry Access Code) Also
`device in limited discoverable mode will be discovered
`
`using general inquiry. The general inquiry is intended to be
`used by devices that need to discover devices that are made
`discoverable continuously or for no specific condition.
`
`[0035] The purpose of the limited inquiry procedureis to
`provide the initiator with the Bluetooth device address,
`clock, Class of Device and used page scan mode of limited
`discoverable devices. The latter devices are devices that are
`
`in range with regard to the initiator, and may beset to scan
`for inquiry messages with the Limited Inquiry Access Code,
`in addition to scanning for
`inquiry messages with the
`
`

`

`US 2005/0250552 Al
`
`Nov.10, 2005
`
`Inquiry Access Code. The limited inquiry is
`General
`intendedfor use by devices that need to discover devicesthat
`are made discoverable only for a limited period of time,
`during temporary conditions or for a specific event.
`
`[0036] The purpose of name discovery is to provide the
`initiator with the Bluetooth Device Name of connectable
`devices(i.e. devices in range that will respond to paging). A
`Name request is the procedure for retrieving the Bluetooth
`Device Name from a connectable Bluetooth device. It is not
`
`necessary to perform the full link establishment procedure in
`order to just to get the name of another device. In the name
`request procedure, the initiator will use the Device Access
`Code of the remote device as retrieved immediately before-
`hand, normally through an inquiry procedure.
`
`such as within manylarge building, GPRS signals cannot be
`relied on. To ensure connectivity, the service may provide
`Bluetooth access points which connect the devices to the
`GPRS network. In other situations, notification and alert
`messages may be sent using the SMS (Short Message
`Service) available on digital GSM networksto allowing text
`messages of up to 160 characters to be sent and received. If
`the phone is powered off or out of range, SMS messagesare
`stored in the network and are delivered at the next oppor-
`tunity.
`
`[0043] Server Operations
`
`[0044] The functions performed at the remote server 220
`are illustrated within the dashed-line rectangle 250 in FIG.
`2.
`
`[0037] The purpose of device discovery is to provide the
`initiator with the Bluetooth Address, Address, clock, Class
`of Device, used page scan mode and Bluetooth device name
`of discoverable devices. During the device discovery pro-
`cedure, first an inquiry (either general or limited) is per-
`formed, and then name discovery is done towards some or
`all of the devices that responded to the inquiry.
`
`[0038] A Bluetooth enabled cellular phone programmed
`with the BlueAware application identifies and stores the
`device addresses and the device names in the devices log
`seen at 214 and candisplay a listing of the recently identified
`nearby devices as seen in FIG. 1a. The content of the
`devices log is further illustrated above in Table 1.
`
`[0045] Participating Bluetooth device users provide pro-
`file information along with the Bluetooth identification
`values (BTIDs) to populate a profile database illustrated at
`260 in FIG. 2. The data in the profile database may be
`entered using an HTML forms-based procedure of the type
`illustrated by the form display of FIG. 3. Using an assigned
`user name and password, a user accesses a secure website
`which provides a forms based interface for entering and
`editing profile information the describes a Bluetooth enabled
`cellular phone(typically including its cellular phone number
`and its 48 bit Bluetooth device address). The form also
`enables the user to enter descriptive information about the
`device user, including a photograph (typically a jpg image
`file uploaded to the server), as will as bibliographic data
`[0039] The preferred Bluetooth enabled cellular phone is
`about the user (e.g., name, address, gender, schools attended,
`also capable of exchanging data with a remotely located
`and occupation). In addition,
`the user specifies a set of
`server via the cellular network using GPRS (General Packet
`interests. Preferably, the interests are selected fromahier-
`Radio Service), a standard for wireless communications
`archically organized collection of predetermined interest
`which runs at speeds up to 115 kilobits per second, com-
`categories so that the interests of different people may be
`pared with current GSM (Global System for Mobile Com-
`more easily matched. When a user wishes to specify an
`munications) systems’ 9.6 kilobits. GPRS supports a wide
`unlisted category, he or she may do so, and an editor may
`range of bandwidths, makes efficient use of limited band-
`periodically review these new categories and, when appro-
`width, and is particularly suited for sending and receiving
`priate, add them to the organized collection.
`small bursts of data, such as e-mail and Web browsing, and
`for
`transmitting the notification and alert messages
`employed by the present invention.
`
`[0040] A Bluetooth enabled cellular phoneor other wire-
`less device connects to the server using GPRSby transmit-
`ting a notification message containing that devices Bluetooth
`device address, the Bluetooth device address of a nearby
`discovered device,
`and a mode/threshold value. For
`example,
`the device might submit
`the request: http://
`18.85.44.254/serendipity/php/px.php?myBTID=
`BTID&myThres=Thres&rBTID=rBTID where BTID and
`rBTID are expressed as the 12 hexadecimal digits repre-
`senting the 48 bit Bluetooth device address values of the
`requesting device and the recognized device respectively.
`
`[0041] The server may, by way of example, execute a
`specified perl script that executes on an application server
`and takes the BTID and threshold variables received from
`
`the phones and connects to a MySQL database to fetch and
`compare the profile data associated with the two devices,
`yielding a calculated similarity score between the two users.
`If this score is above oneor both users’ thresholds, the script
`returns the commonalities as well as additional contact
`information (at each user’s discretion) back to the phones.
`
`[0046] As shownin FIG.2, the user may use an available
`personal computer 290 connected to a web server via the
`Internet 295 to populate the profile database. As will be
`understood, the functions performed by the remote server
`may be performed bya plurality of different server processes
`which execute on one or several different computes and
`would typically include a web server, an application server
`and a database server. The remote server may also advan-
`tageously provide a WAP (Wireless Application Protocol)
`interface that allows the users of cellular phones and other
`wireless devices to easily and instantly access and interact
`with information and services provided by the server.
`
`[0047] As illustrated in FIG.3, the user mayalso associate
`a “level of interest” weighting value that can be used in a
`matchmaking process performed by the server to better
`identify other participants with whom direct communica-
`tions are likely to be rewarding. Thus, in the example seen
`in FIG.1, the user named “Martin Semoury” has associated
`a low weightvalueto the data indicating his birthday, but has
`assigned a high weight to the nameofhis college, thereby
`indicating that he wishes to know when people who also
`attended Stanford are nearby, regardless of their age.
`
`the phones will need to
`[0042] For many applications,
`connect via the GPRS network. Unfortunately, in locations
`
`[0048] As also indicated in FIG. 3, the user may enter a
`threshold value that indicates how high the calculated simi-
`
`

`

`US 2005/0250552 Al
`
`Nov.10, 2005
`
`larity score should be before the server is to send an alert
`message to that user. In the example seen in FIG. 3, Martin
`Semoury has entered a low threshold value of 1, indicating
`that he desires to receive alert messages even when the
`profile analysis performed by the server suggests that the
`user of a detected nearby device has few commoninterests.
`The threshold value may be, and commonly is, dynamically
`reset by the individual user, depending onthe users changing
`circumstances. As illustrated at 270 in FIG. 2, each notifi-
`cation message sent from a device to the server includes not
`only its own ID value (the Requester ID) and the ID value
`of the newly arrived other device (the Identified ID), but also
`a Threshold value indicating the current willingness of the
`requestor to receive notification messages. By transmitting a
`threshold value of zero, a user indicates that the user desires
`to receive an alert for all newly arriving devices. By trans-
`mitting a maximum threshold value, a user may inform the
`server that no alert messagesare to be sentto that user until
`a lower threshold valueis sent.
`
`[0049] Each time a requesting device sends a notification
`message to the server, its current threshold value is reset.
`This last entered value may be used to determine whether or
`not to send an alert message when another device sends a
`notification message indicating the proximity of
`two
`devices. When the server calculates a server score,
`it is
`compared with the currently stored threshold level of each
`identified device to determine whetheror not to send an alert
`
`message to that identified device.
`
`[0050] As shown in FIG. 2 at 260, the profile database
`contains, for each Bluetooth device: (a) the Bluetooth iden-
`tification value BTID for that device; (b) a password which
`is used to authorize subsequent changes to the profile
`database; (c) a short name for the device or its user (which
`need not be same name as the “device name”stored in the
`Bluetooth device); (d) contact information such as mailing
`address, email address, web site URL, fax numbers, and
`importantly, the cellular phone number of the device, etc.;
`(ec) demographic information describing the device or user,
`such as age, sex, religion, ethnicity, height, weight, or any
`other values which are of use in performing desired match-
`ing functions; data describing the “interests” of the device
`user, which can be used both to describe the user and/or to
`describe the attributes of interest in another participating
`user; (f) weighting values associated with individual items
`of demographic or interest data indicating the level of
`importance that user attached to each category of data; and
`(f) other preference data indicating, for example, the extent
`to which other information is the profile is sharable, and
`under what circumstances. In a given application, only a
`limited subsct of these possible profile data catcgorics is
`used, and the kinds of information that will be useful can be
`expected to vary significantly from application to applica-
`tion. In addition, as noted below, the user can control the
`kinds of information that are consulted in calculating a
`similarity score by changing the mode value associated with
`the threshold value.
`
`[0051] An incoming notification/request message from a
`participating Bluetooth device re