a9 United States
`
`Eagle et al.
`
`US 20050250552A1
`
`a2 Patent Application Publication (o) Pub. No.: US 2005/0250552 A1l
`(43) Pub. Date:
`
`Nov. 10, 2005
`
`(54) COMBINED SHORT RANGE RADIO
`NETWORK AND CELLULAR TELEPHONE
`
`Related U.S. Application Data
`
`Cellular
`
`Threshold
`?
`
`NETWORK FOR INTERPERSONAL (60) Provisional application No. 60/568,482, filed on May
`COMMUNICATIONS 6, 2004.
`(75) Inventors: Nathan Norfleet Eagle, Boston, MA Publication Classification
`(US); Alex Paul Pentland, Lexington,
`MA (US) (51) Int. CL7 oo GO3F 3/08
`(52) US. Cli et eiseences 455/567
`Correspondence Address:
`CHARLES G. CALL 57 ABSTRACT
`68 HORSE POND ROAD — .
`WEST YARMOUTH, MA 02673-2516 (US) Portable communication devices, such as Bluetooth enabled
`’ cellular phones, communicate with and identify like devices
`(73) Assignee: Massachusetts Institute of Technology, that are nearby, and send notification messages to a remote
`Cambridge, MA server. When a notification message is received at the server
`’ identifying two devices that have come within range of one
`(21) Appl. No.: 11/122,630 another, the server compares the profile data associated with
`each of the two identified devices and facilitates communi-
`22) Filed: May 5, 2005 cations between the devices when appropriate.
`(22) y 5, ions b he devices when appropri
`Bluetooth ID | Password [Name Contact Info | Demographics | Interests | Preferences
`0678EA987F993| zztop SUPRV
`107F00AO0RE23 | AR345HH |JACKY
`0050F2E17654| 76t WER [BARON
`00EQ9885E388| deliaxrs | KIT-KAT|
`________________________ 1 \ Fo————— - - - - - - - —————— o,
`Detect |, ' 290 1 [ Requester Identified Threshold]| !
`Arriving Device | 295 260 | [00E09885E388 [0678EAIB7F993 | 0020 :
`1 - |
`: @ <« ? 27??ecleive :
`1 [}
`L : Notification l i
`Post to h Alert One or
`20 ¥ 1 i l 275 | Both Devices |
`) Retrieve & Based on '
`290 ! Compare Profiles Preferences 1
`= Devices !
`f——— | '
`Y ' :I
`' I
`! 1
`1
`
`Devices Log
`
`223
`
`No.
`
`Name
`
`Bluetooth ID
`
`0
`
`KIT-KAT]
`
`00EQ9885E388
`
`BARON
`
`0050F2E17654
`
`JACKY
`
`107FO0AQORE?23
`
`1
`2
`3
`
`SUPRV
`
`0678EAQ87F993
`
`Logtime Log
`
`214
`
`.| Time Stamp
`
`2004/2/29
`
`12:59:54
`
`2004/2/29
`
`13:09:21
`
`2004/2/29
`
`15:15:44
`
`2004/2/29
`
`15:17:07
`
`Network
`
`Google Exhibit 1005
`Google v. SecCommTech
`
`
`
`
`
`
`
`
`
`US 2005/0250552 Al
`
`Patent Application Publication Nov. 10, 2005 Sheet 1 of 2
`
`o} ‘b
`
`@) fi @ Y
`thg) (M) ()
`mvz_z & @% @ hxo &
`
`99 )
`A>AY)
`
`{— TIRRIAN NvQ
`
`O10J$3 |08y
`Bulios
`
`000
`00000
`00000
`00000
`
`000
`
`ql bi-
`
`slals
`) (7g) ()
`o) (79 (53
`&9 9 (1
`BC0N
`
`( TIRIEN NVQ
`
`© O O
`o 0 O o o
`© O 0O o o
`[o 2o B o I = I o
`
`o 0O o
`
`e} b
`
`# fi e Y
`m?s @ h>2& mzo& b
`@%& ?:uw @o&
`
`g g (L
`P>V
`
`| 501057vEp000 |
`o2 T
`ov083€20¥V00
`AVINTIEO SV
`
`000
`00000
`00000
`00000
`
`000
`
`
`
`
`
`
`
`
`
`US 2005/0250552 A1
`
`Patent Application Publication Nov. 10, 2005 Sheet 2 of 2
`
`ovz [ZOZV'SL_6e/2/v00Z €
`\[FEEEEL_Bererh00z [0
`12:60°€L_62/2/b00Z] |
`
`AR
`
`¥G:65:¢l 62/2/¥002| 0
`dwels swi [oN
`
`iz 6o swnbo
`
`~
`
`1
`|
`1
`I
`|
`I
`1
`]
`1
`1
`1
`|
`1
`o | £663286v38490 | A¥dNS [ €
`1 [ €23900v003Z0L | AMOVr |2
`“ $S9413C40S00 |NOWVE | |
`1 88€358860300 [LVAH-LIM |0
`“ al yioojenig | sweN |'ON
`P e e, —————— | PITIINETN / “ gcc 6o7 seoineq
`fi ! 1en|e) (224 ! ~~
`ploysaiyt [ I dweg swi| «
`SOA oA0qQY " “ BAES M~
`sa01Aa( 082 ! — | ._m\fiww eve
`saouUBIeleld $9|0id 2Iedwo) | 062 I AINON ~
`uo paseg 3 8ASLIeY “ | 3 8le
`$adlAaQ ylog 7 1 ~—A 1 B0 @21n8Q
`oeuQpayy | 94O “ oLz, ! 0} 3504 /tmmem
`_ uogeoynoN |, | N
`CTVERENY | ) " “ Sor oN
`y _ 7 AI_'.
`o\.N/ ,v\ m m :.N/
`|
`0200| £664/86Y38/90] 88£358860300 | ~~ o9z 96C | _[a01n8g Buialy|
`PIOUSaIUL RETHUEL] 158nbay |! 0ce ! > 10918Q
`|
`
`LVM-LIM | SiXel3p |88€3S58860300
`NOMva| ¥3IMN9Z [#59/13240500
`ANV HHSGYEHY | £¢3400V004.01
`
`AddNS doyzz [£664/86V38/90
`saoualalald | sisaleu) |soiydeiboweq | ojul1oeuo] sweN| piomssed| Ql yooenig
`
`
`
`
`
`
`
`
`
`US 2005/0250552 A1
`
`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.
`
`SUMMARY OF THE INVENTION
`
`[0003] Inits preferred form, the present invention employs
`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.
`
`[0005] Profile data that describes each device and its
`owner is 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 mode of the requesting device
`to determine the type of interaction to enable.
`
`[0006] If the calculated value indicating the extent to
`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 may alter
`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
`
`Nov. 10, 2005
`
`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
`owner of the device, or any other information which is of use
`in a specific application may be of use to identify, or promote
`communications between, nearby devices and their owners.
`
`[0008] The present invention can exploit the growing
`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.
`
`[0009] The storage of profile data, the performance of
`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 A1
`
`invention supplies that need by providing an automatic
`mechanism for establishing and verifying links automati-
`cally between people who are physically near to one another.
`
`[0012] In accordance with a feature of the preferred
`embodiment of the invention, service users can also asso-
`ciate weighting values with the information about them-
`selves and others, and use these weighting values to specify
`the information’s importance to be assigned to 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
`someone in their proximity that they would like to meet. The
`thresholds and the weighting scheme that 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 phone to 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
`
`[0014] In the detailed description which follows, frequent
`reference will be made to the attached drawings, in which:
`
`[0015] FIGS. 1la, 1b, and 2c illustrate cellular phone
`screen displays produced in the course of operating an
`illustrative preferred embodiment of the invention; and
`
`[0016] FIG. 2 is a block diagram that illustrates the
`principal components of a system that implements the
`invention.
`
`DETAILED DESCRIPTION
`[0017] Portable Device Operation
`
`[0018] In the illustrative embodiment of the invention
`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
`“discoverable” 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
`
`Nov. 10, 2005
`
`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 common interests 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 phone carried 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.
`
`[0023] If it is determined at 216 that a detected nearby
`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 transmission of a 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 two files, the
`Devices Log 214 listing ID values (device addresses and
`device names) and the Logtime log 240 listing 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 name after
`each encounter. This method was shown to dramatically
`lower the size of the proximity log. Example data of the kind
`that might be recorded in the two proximity logs is listed in
`Table 1, below.
`
`
`
`
`
`
`
`
`US 2005/0250552 A1
`
`TABLE 1
`
`Logging information format
`
`BTdevices.log
`0 [name] KIT-KAT [addr] 00e09885e388
`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, most individuals
`are used to having phones with standby times exceeding 48
`hours. Therefore, the BlueAware application program that
`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
`phones are 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 phone sales.
`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 OS are currently available
`from many cellular phone manufacturers, including Nokia,
`Motorola, Sony Erickson, Panasonic and Lenovo, and are in
`widespread use.
`
`[0029] The application program (here called
`“BlueAware”) that runs on each cellular phone can be
`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 name to 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 home or office. Software controls and
`identity coding built into each microchip ensure that only
`
`Nov. 10, 2005
`
`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 power transmission 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),
`which is typically displayed as 12 hexadecimal digits as seen
`in Table 1 above. Each Bluetooth device further stores and
`can reveal a “user friendly” displayable Bluetooth Device
`Name which 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) which is 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 mode or in general discoverable
`mode. Even when a Bluetooth device is made discoverable
`it may be unable to respond to inquiry due to other baseband
`activity. A Bluetooth device that does not respond to inquiry
`for any of these two reasons is 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 purpose of the general inquiry procedure is
`to provide the initiator with the Bluetooth device address,
`clock, Class of Device and used page scan mode of general
`discoverable devices (i.e. 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 procedure is 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 be set to scan
`for inquiry messages with the Limited Inquiry Access Code,
`in addition to scanning for inquiry messages with the
`
`
`
`
`
`
`
`
`US 2005/0250552 A1
`
`General Inquiry Access Code. The limited inquiry is
`intended for use by devices that need to discover devices that
`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.
`
`[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 can display a listing of the recently identified
`nearby devices as seen in FIG. 1la. The content of the
`devices log is further illustrated above in Table 1.
`
`[0039] The preferred Bluetooth enabled cellular phone is
`also capable of exchanging data with a remotely located
`server via the cellular network using GPRS (General Packet
`Radio Service), a standard for wireless communications
`which runs at speeds up to 115 kilobits per second, com-
`pared with current GSM (Global System for Mobile Com-
`munications) systems’ 9.6 kilobits. GPRS supports a wide
`range of bandwidths, makes efficient use of limited band-
`width, and is particularly suited for sending and receiving
`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 phone or other wire-
`less device connects to the server using GPRS by 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 one or both users’ thresholds, the script
`returns the commonalities as well as additional contact
`information (at each user’s discretion) back to the phones.
`
`[0042] For many applications, the phones will need to
`connect via the GPRS network. Unfortunately, in locations
`
`Nov. 10, 2005
`
`such as within many large 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 networks to allowing text
`messages of up to 160 characters to be sent and received. If
`the phone is powered off or out of range, SMS messages are
`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.
`
`[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 web site
`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
`about the user (e.g., name, address, gender, schools attended,
`and occupation). In addition, the user specifies a set of
`interests. Preferably, the interests are selected from a hier-
`archically organized collection of predetermined interest
`categories so that the interests of different people may be
`more easily matched. When a user wishes to specify an
`unlisted category, he or she may do so, and an editor may
`periodically review these new categories and, when appro-
`priate, add them to the organized collection.
`
`[0046] As shown in 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 by a 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] Asillustrated in FIG. 3, the user may also 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
`alow weight value to the data indicating his birthday, but has
`assigned a high weight to the name of his college, thereby
`indicating that he wishes to know when people who also
`attended Stanford are nearby, regardless of their age.
`
`[0048] As also indicated in FIG. 3, the user may enter a
`threshold value that indicates how high the calculated simi-
`
`
`
`
`
`
`
`
`US 2005/0250552 A1
`
`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 common interests.
`The threshold value may be, and commonly is, dynamically
`reset by the individual user, depending on the 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 messages are to be sent to that user until
`a lower threshold value is 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 whether or 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.;
`(e) 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-