Source: http://www.google.com/patents/US20050281237?dq=5,646,839
Timestamp: 2015-07-04 05:15:38
Document Index: 83477125

Matched Legal Cases: ['art 304', 'art 304', 'art 312', 'art 2', 'art 301', 'art 304', 'art 312', 'art 301', 'art 301', 'art 301', 'art 304', 'art 312', 'art 301', 'art 304', 'art 312', 'art 301', 'art 304']

Patent US20050281237 - Personal profile sharing and management for short-range wireless terminals - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA mobile, wireless terminal contains apparatus for creating, editing and storing user personalized profiles for access by inquiring terminals in a short-range communication system. The mobile, wireless terminal contains databases for storing standardized format profiles containing user contact information,...http://www.google.com/patents/US20050281237?utm_source=gb-gplus-sharePatent US20050281237 - Personal profile sharing and management for short-range wireless terminalsAdvanced Patent SearchPublication numberUS20050281237 A1Publication typeApplicationApplication numberUS 11/214,872Publication dateDec 22, 2005Filing dateAug 31, 2005Priority dateFeb 27, 2002Also published asDE60311237D1, DE60311237T2, EP1483679A1, EP1483679A4, EP1483679B1, US7249182, WO2003073304A1Publication number11214872, 214872, US 2005/0281237 A1, US 2005/281237 A1, US 20050281237 A1, US 20050281237A1, US 2005281237 A1, US 2005281237A1, US-A1-20050281237, US-A1-2005281237, US2005/0281237A1, US2005/281237A1, US20050281237 A1, US20050281237A1, US2005281237 A1, US2005281237A1InventorsTomi Heinonen, Timo Laitinen, Stephan Bouet, Sany ZakhariaOriginal AssigneeTomi Heinonen, Timo Laitinen, Stephan Bouet, Sany ZakhariaExport CitationBiBTeX, EndNote, RefManReferenced by (34), Classifications (22) External Links: USPTO, USPTO Assignment, EspacenetPersonal profile sharing and management for short-range wireless terminals
DESCRIPTION OF PREFERRED EMBODIMENT In the following description of the various embodiments, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope of the present invention. FIG. 1 discloses a system 100, which provides personal profile sharing for wireless, mobile terminals in ad hoc networks. A user's terminal 101, typically a Bluetooth device, includes a memory 103 storing a browser 105, an operating system (not shown), a profile editor and manager 108, and a personal profile 107 indicating the user's interests or receiving queries from other terminals in an ad hoc network 109. The user's terminal 101 includes a display, a keypad 113 and an antenna 115 for sending and receiving signals 117 to other Bluetooth devices 119, 121 and 123 in a short-range communication system. Antenna 115 also sends and receives signals 117′ with an access point 125 linked to by a network 127, e.g. the Internet, to a personal data server 129 operated by a service provider. The following description is provided for the terminals or wireless devices in the system 100 implemented as Bluetooth devices. However, the terminals or wireless devices in the system 100 can also be implemented in other wireless standards such as the IEEE 802.11 Wireless LAN standard and the HIPERLAN standard. A connection between two Bluetooth devices is initiated by an inquiring device sending out an inquiry message containing an inquiry access code (IAC), searching for other devices in its vicinity. Any other Bluetooth device that is listening for an inquiry message containing the same inquiry access code (IAC), by means of conducting an inquiry scan, will recognize the inquiry message and respond. The inquiry response is a message packet containing the responding device's Bluetooth Device Address (BD_ADDR). A Bluetooth device address is a unique, 48-bit IEEE address, which is electronically engraved into each Bluetooth device. The inquiring device uses the information provided in the inquiry response packet, to prepare and send a paging message to the responding device. To establish a connection, the inquiring device must enter the page state. In the page state, the inquiring device will transmit initial paging messages to the responding device using the device access code and timing information acquired from the inquiry response packet. The responding device must be in the page scan state to allow the inquiring device to connect with it. Once in the page scan state, the responding device will acknowledge the initial paging messages and the inquiring device will send a paging packet, which provides the clock timing and access code of the inquiring device to the responding 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 inquiring device that has initiated the connection assumes the role of a master device and the responding device assumes the role of a slave device in a new ad hoc network. Each ad hoc network has one master device and up to seven active slave devices. All communication is directed between the master device and each respective slave device. The master initiates an exchange of data and the slave responds to the master. When two slave devices are to communicate with each other, they must do so through the master device. The master device maintains the ad hoc network's network clock and controls when each slave device can communicate with the master device. Members of the ad hoc network join and leave as they move into and out of the range of the master device. Ad hoc networks support distributed activities, such as collaborative work projects, collaborative games, multi-user gateways to the Internet, and the like. A user's device that joins a particular ad hoc network, does so to enable its user to participate in the currently running collaborative activity. FIG. 2 discloses one embodiment of the user's terminal 101. Included in the terminal 101 is a display 201 for displaying messages received from the access point 127 and the other terminals 119, . . . 123 in a piconet, e.g. the ad hoc network 109, where the terminal 119 may serve as an inquiring device. An input device 203 such as the key pad 113, enables the user to enter data for transmission to the access point or other terminals. Input device 203 enables the user to input changes to the user's personal profiles stored in a storage area 205, including phone book information 207, Service Discovery Database 209, and a Personal profile database 211. A CPU 213 is connected to both the input 203, the storage devices 205, and to a memory 215 containing an operating system (not shown) and protocol for the Bluetooth connection/disconnection processes described above. A short-range transceiver 217 is linked to the antenna 115 for sending and receiving signals to the devices 119, 121 and 123 and to the access point 125. In the ad hoc network 109 of FIG. 1, the inquiring device 119 sends inquiries to other Bluetooth devices in the area, such as the user's terminal 101. The inquiring device 119 periodically transmits inquiry packets. The general inquiry access code (GIAC) of the packet is recognized by all Bluetooth devices as an inquiry message. During the inquiry procedure, any other Bluetooth devices that are in the inquiry scan state, such as the user's terminal 101, are scanning for the receipt of inquiry packets. If the user's terminal 101 in the inquiry scan state receives the inquiry packet with a matching IAC, it will respond with an inquiry response packet that has sufficient information to enable the inquiring device 119 to build its inquiry response table of essential information required to make a connection. Any Bluetooth device recognizing the inquiry packet can respond. The inquiring device 119 can now initiate a connection with the user's terminal 101. The inquiring device 119 uses the information provided in the inquiry response packet, to prepare and send a paging message to the user's terminal 101. To establish a connection, the inquiring device 119 must enter the page state, where it will transmit paging messages to the user's terminal 101 using the access code and timing information acquired from the inquiry response packet. The user's terminal 101 must be in the page scan state to allow the inquiring device 119 to connect with it. Once in the page scan state, the user's terminal 101 will acknowledge the paging messages and the inquiring device 119 will send a paging packet, which provides the clock timing and access code of the inquiring device 119 to the user's terminal 101. The user's terminal 101 responds with a page acknowledgment packet. This enables the two devices to form an asynchronous connection-less (ACL) link and both devices transition into the connection state. The inquiring device 119 can then send to the user's terminal 101, a Service Discovery Protocol (SDP) search request packet. The SDP Request packet carries 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 pattern for the user's terminal 101 to match in the service registry of its SDP database 209. If the user's terminal 101 has the service requested, it responds with the service's handle. The service handle identifies the service for which the attributes are being requested. The attribute ID list identifies the attributes that the inquiring device 119 is requesting. The SDP service registry in the SDP database 209 stores service records in a browsing hierarchy. The service records are arranged into a hierarchy structured as a tree that can be browsed. The inquiring device 119 can begin by examining the public browse root, and then follow the hierarchy out to service classes which are the branches of the tree, and from there to the leaf nodes, where individual services are described in service records. To browse service classes or to get specific information about a service, the inquiring device 119 and the user's terminal 101 exchange messages carried in SDP packets. There are two types of SDP packets, the SDP Service Search Attribute Request packet and the SDP Service Search Attribute Response packet. The SDP Request packet carries 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 pattern for the user's terminal 101 to match in its SDP service registry in the database 209. If the user's terminal 101 has the service requested, it responds with the service's handle. The service handle identifies the service for which the attributes are being requested. The attribute ID list identifies the attributes that the inquiring device 119 is requesting. The SDP response packet returned by the user's terminal 101 carries the SDP Service Search Attribute Response which includes a service record handle list and the attributes. The service record handle list and the attributes are then examined by the inquiring device 119. As described above, an inquiry response packet from the user's wireless terminal 101, has sufficient information to enable the inquiring device 119 to build an inquiry response table of essential information required to make a connection. The Bluetooth frequency hop synchronization (FHS) packet structure for an inquiry response packet sent by the user's wireless terminal 101, includes a class-of-device (CoD) field. In one aspect of the invention, whenever the user of the wireless terminal 101 wants to provide his/her personal profile information to inquiring devices, the user sets the personal profile response state to “ON”. This causes the user's wireless device 101 to write into the class-of-device (CoD) field of its inquiry response packet, its status as having its personal profile available. The inquiring device 119 constructs the inquiry response table with the information in the inquiry response packets received from responding devices, such as the user's wireless terminal 101. The inquiry response table shows the essential information gathered by the link controller in the inquiring device 119, which is needed to make a connection with any of the responding wireless devices. In this aspect of the invention, any responding devices are flagged, such as the user's wireless terminal 101, that have a class-of-device (CoD) field with the status of having its personal profile available. There are several options that can be programmed in the inquiring device 119, for processing the data gathered in the inquiry response table. The inquiring device 119 can be programmed to determine whether the class-of-device (CoD) field for a responding device has the status of having its personal profile available. If so, then the inquiring device 119 can browse or search the SDP service records of the user's wireless terminal 101, since it is now known that they have personal profile information available. Since an analysis of the class-of-device (CoD) field only requires the receipt of an inquiry response packet, and does not require the completion of a connection between the two devices, this option provides a quick search of responding devices. The inquiring device 119 can provide to its user a “QUICK SEARCH” option in its initial logon menu, which can invoke the process to check the data gathered in the inquiry response table to determine whether the class-of-device (CoD) field for any responding device has the status of having its personal profile available. This implementation is optional. The inquiring device 119 can be programmed to determine whether the class-of-device (CoD) field for a responding device, such as the user's wireless terminal 101, has a specific type of personal profile information specified in the class-of-device (CoD) field. The inquiring device 119 can match it with an entry in a search options list table in the inquiring device 119. For example, the user's wireless terminal 101 can be set by its user to indicate in its class-of-device (CoD) field of its inquiry response packet, that a dating/match-making personal profile is available. The inquiring device 119 can be programmed by its user to recognize that particular class-of-device (CoD) and respond by browsing or searching the SDP service records of the user's wireless terminal 101. The inquiring device 119 can be programmed for optional special processing of the SDP service records with dating/match-making personal profile information from the user's wireless terminal 101. FIG. 3A is an overview of a typical user profile 300 stored in memory 215 (FIG. 2) as a record and including contact information 301 having a pointer to an entry in the phonebook 207 (FIG. 2) for responding to queries from another user in the ad hoc network. The profile 300 further includes a standardized profile part 304 defining the user's personal information, interest and other matters, as will be described in more detail in connection with FIG. 3B. In one embodiment, the record may include a plurality of “bit masks” 306 1 . . . 306 N, where the plurality is an integer “N”. Each bit mask contains two bytes representing a profile, where byte 308 identifies the profile in part 304 and byte 310 enables the user to characterize the content of that profile. The profile may be characterized, in one embodiment by identifying the qualities of the profile using binary 1s (illustrated by filled circles) and binary 0s (illustrated by empty circles) to indicate yes/no choices, respectively or vice versa. There can be bit mask values that are assigned by convention to indicate generic interests such as art, dating, and sports. The bit masks 306 can be used to facilitate the user's selection of one profile among many profiles that the user has stored in the SDP database 209. The bit masks can also be used to facilitate communication with the inquiring device 119. The inquiring device 119 can retrieve a bit mask 306 in an SDP response packet returned by the user's terminal 101. The SDP response packet carries the SDP Service Search Attribute Response which includes the bit mask. The bit mask can then be examined by the inquiring device 119, comparing its value with reference bit mask values indicating the generic interests. Profile 300 of FIG. 3A further includes user and/or manufacturer defined profile part 312 represented by a datastream 314, including a user identification field 316 having a plurality of 3-part sub-fields 3181, 3182, to 318, where the plurality is an integer “n”. Each subfield contains a name portion 320 identifying a user or a manufacturer associated with the terminal, a format portion 322 defining specific information related to the name or the manufacture, and a value portion 324 providing a code representing the specific information related to the user or manufacturer. The datastream 314 can be used to facilitate the user's selection of one profile among many profiles that the user has stored in the SDP database 209. The datastream 314 can also be used to facilitate communication with the inquiring device 119. The inquiring device 119 can retrieve a datastream 314 in an SDP response packet returned by the user's terminal 101. The SDP response packet carries the SDP Service Search Attribute Response which includes the datastream 314. The datastream 314 can then be examined by the inquiring device 119. FIG. 3B shows a more detailed view of the personal profile 300 comprising a plurality of sub-profiles. A sub-profile 300 1 defines message processing. A sub-profile 300 2 provides editing of personal profiles related to user information, interests, etc. A sub-profile 300 N provides processes for filtering messages received from users on the ad hoc network. Each sub-profile includes a list of user interests defined by a plurality of fields, each field including a series of attributes, where each attribute is defined by a name, a type and a value. The sub-profile 300 1 in FIG. 3B, sorts received messages that are received from the ad hoc network or access point into advertisements 303, warnings 305, announcements 307, and personal messages 309. Using the Platform For Interconnect Content Selection (PICS) Rules, published at http://www.w3.org/PICS, a screening program that provides an indicator describing the content of each message. The indicator is recognized by the sub-process and accepted or rejected according to the user's interest as inputted via a screen 311 in FIG. 3B. The user clicks on the messages to be rejected and allows the other messages to be processed for display to the user. The screen 311 permits the user to change message selections at any time, without changing the records in the personal data server 129 (see FIG. 1) at anytime, thereby enabling the personal profile to be current with the users messages interest. A sub-profile 300 2 in FIG. 3B, enables the user to install and edit user's private profile information, including phone book information related to age, gender, profession, contact information, picture and other related information that the user wishes to make available to other users in the ad hoc network. Also included in the sub-profile 300 2 are the user's interest 315, which may be in different categories indicated in a screen 317 in FIG. 3B. The categories include, for example, Art, Present, Dating, and Sports. Each interest is further expanded in a screen 319 in FIG. 3B, listing specific interest in a category. The sub-profile 300 2 in FIG. 3B, further includes a shopping list 321 for different merchants, A, B, C, D, each list including key words or merchandise in which the user has an interest as described in an accompanying sub-screen (not shown). The sub-screen allows the user to edit or delete from the contents in the shopping list. The sub-profile 300 2 in FIG. 3B, may also include a digital signature, which can be generated by the user in the event that merchandise is ordered and payment is required by the merchandiser. Digital signatures and their protection are described in the text Applied Cryptography by B Schneier, published by John Wiley & Sons, New York, N.Y., Part 2.6, ISBN 0-471-12845-7), 1996 Responsive to screen 302 in FIG. 3B, the sub-profile 300 n filters user profiles. The sub-profile 300 n enables the user to establish a state 325 “accepting all messages”, or alternately a state 327 “rejecting all messages”, or alternately a state 329 “filtering all messages”. This is accomplished using the PICS rules related to user information 313, or using user interests 315, or using shopping list 321. This provides the ability to allow the user to edit/remove keywords filtering the messages. TABLE A FORMATTING OF ALL USER PROFILES IN ONE SDP RECORD 400 A B C D E F G H 1 UserInformation 2 Contact Info vCard String 3 UserProfile ID List List of Profiles 4 UserProfileID1 UserProfile 1 UUID 5 Version Profile version Unit 16 0x0100 6 Profile Filter bitmask 7 UserProfileID2 UserProfile 2 UUID 8 Version Profile version Unit 16 0x0100 9 Profile Filter bitmask 10 UserProfileIDn UserProfile n UUID 11 Version Profile version Unit 16 0x0100 12 Profile Filter bitmask 13 UserDefined ProfileIDList 14 Profile ID 1 SupportProfile UUID 15 FieldName ProfileVersion String 16 FieldType ProfileVersion Unit 8 17 FieldValue ProfileVersion varies 18 Profile ID 2 SupportProfile UUID 19 FieldName ProfileVersion String 20 FieldType ProfileVersion Unit 8 21 FieldValue ProfileVersion varies 22 Profile ID 3 SupportProfile UUID 23 FieldName ProfileVersion String 34 FieldType ProfileVersion Unit 8 25 FieldValue ProfileVersion varies A B C D E F G H Table A is a representation of user personal profiles formatted in one SDP record, including contact information, standard user profiles and user and/or manufacturing profiles Table A shows all user profiles formatted in one Service Discovery Protocol (SDP) record 400 stored in the SDP database 209 (FIG. 2). Table A is organized into eight columns labeled “A” through “H” and into 25 rows labeled “1” through “25”. The record 400 shown in Table A includes the contact information part 301 shown in rows 1 and 2, standardized profile part 304 shown in rows 3 through 12, and user and/or manufacturer defined profile part 312 shown in rows 13 through 25. The contact information part 301 of Table A includes a vCard string shown in Table A at columns E and F, row 2, the contents of which appear in FIG. 4A. FIG. 4A is a representation of a text-encoded vCard format 401 available in the contact information part 301 of Table A. The contact information part 301 includes the name of the individual, telephone for both voice and fax. vCards are an electronic business card for Personal Data Interchange. The vCard facilitates various data interchanges including exchanging business cards, Internet mail, computer/telephone applications and video and data conferencing. The Card is described in the vCard V2.1 specification published by the Internet Mail Consortium at http://www.imc.org/pdi/vcardoverview.html. The Internet Engineering Task force (IETF) has released the specification for vCard version 3. The two parts of the definition are: RFC 2425, MIME Content-Type for Directory Information and RFC 2426, vCard MIME Directory Profile. In the future, other formats may replace the vCard, such as XML formats based on DTDs. The standardized profile part 304 of Table A shown in rows 3 through 12, includes User ProfileID lists, such as User ProfileID # 1 shown in Table A at column B and C, row 4, and User ProfileID # 2 shown in Table A at column B and C, row 7, up to User ProfileID # n shown in Table A at column B and C, row 10. Each User ProfileID profile includes a Version Number shown in Table A at column C, row 5, a profile filter shown in Table A at column C, row 6, a record, e.g. a bit mask shown in Table A at column D, row 6, a UUID shown in Table A at column E, row 4, and a bit mask code shown in Table A at column F, row 5, as represented by reference 306 1 in FIG. 3A. The User/Manufacturer Defined Profile Part 312 of Table A shown in rows 13 through 25, includes a plurality of Profile IDs shown in Table A at column B, rows 14, 18, and 22. The Profile IDs are each identified by a UUID shown in Table A at column E, row 14, and including a field name shown in Table A at column C, row 15, a field type shown in Table A at column C, row 16 and a field value shown in Table A at column C, row 17 as described in conjunction with reference 314 of FIG. 3A. Each field is associated with a Profile Version shown in Table A at column D, row 15 defined by a bit string shown in Table A at column E, row 15 for the name, a descriptor shown in Table A at column E, row 16 for the format and a parameter shown in Table A at column E, row 17, which varies for the value. Non-standard profiles 450, as shown in FIG. 4B, may be prepared and included in the SDP record. FIG. 4B is a representation of an XML encoded non-standard profile available in the SDP record of Table A. Each non-standard profile may be XML encoded defining the Document Type, Element and User Profile Version, which track the information content of the standardized profiles 304. The XML program, Version 1.9 is described in the W3C recommendation of February 1998. TABLE B FORMATTING THE USER PROFILES IN ONE SDP RECORD 400 WITH POINTERS TO THE PHONE BOOK AND PROFILES DATABASE A B C D E F G H 1 UserInformation 2 Index Index of the Unit8 vcard of the user in the PhoneBook 3 UserProfile ID List List of Profiles 4 UserProfileID1 UserProfile 1 UUID 5 Version Profile version Unit 16 0x0100 6 Profile Filter bitmask 7 UserProfileID2 UserProfile 2 UUID 8 Version Profile version Unit 16 0x0100 9 Profile Filter bitmask 10 UserProfileIDn UserProfile n UUID 11 Version Profile version Unit 16 0x0100 12 Profile Filter bitmask 13 UserDefined ProfileIDList 14 Profile ID 1 Index in the Unit8 Profiles DB 15 Profile ID 1 Index in the Unit8 Profiles DB 16 Profile ID 1 Index in the Unit8 Profiles DB A B C D E F G H Table B is a representation of the user profiles of FIG. 3A, formatted in one Service Discovery Protocol (SDP) record in SDP database 209, with pointers to the Phone book 207 and Profiles database 211. Table B is organized into eight columns labeled “A” through “H” and into 16 rows labeled “1” through “16”. The record 400 shown in Table B includes the contact information part 301 shown in rows 1 and 2, standardized profile part 304 shown in rows 3 through 12, and user and/or manufacturer defined profile part 312 shown in rows 13 through 16. Table B shows user profiles 400 formatted in one SDP record with pointers to the phonebook database 207 and profile database 211 (See FIG. 2) in the user's terminal 101. The contact information part 301 of Table B includes an index shown in Table B at column B, row 2 of the vCards in the phone book 313 (FIG. 3B). The standard profile's part 304 of Table B includes a list shown in Table B at column D, row 3 of user profile IDs, as described in Table A. The user and/or manufacturer defined profiles 312 of Table B include an index shown in Table B at column D, row 14, list of profile IDs, as described in Table A. A user may use the index shown in Table B at column B, row 2, the list shown in Table B at column D, row 3 and the index shown in Table B at column D, row 14, to point to the profile in the SDP database 209 shown in FIG. 2. FIG. 5 in conjunction with FIG. 2, describes a process 700 for creating and editing profiles in the user's mobile terminal 101. In step 701, the process starts and the phone book database 207 is entered in step 702. A phonebook editing menu (not shown) stored in the memory 215, is activated to input the user's contact information in step 703. The contact information, in one embodiment, includes age, gender, profession and other details as indicated in FIG. 3B. A test is made to determine whether the profiles database 211 should be entered in step 705. A “no” condition exits the phone book and the editing menu in step 707. A “yes” condition activates a profile editing menu (not shown), stored in the memory 215 for preparing a standardized profile 400 in step 709 for storing as an OBEX file in the profile database 211. In step 711, a profile is chosen to fill out among a number of available profiles related to interest, shopping lists, etc. In step 713, the process transfers to entry point A in FIG. 6 if the user wishes to complete the profile. Otherwise, step 721 determines the user interest in completing other profiles. A “yes” selection returns the process to step 711 and 713. A “no” selection exits the profile-editing menu in step 731 and the process ends in step 733. In FIG. 6, a test is made in step 715 to determine whether the profile is standard format or not. A “yes” condition initiates step 717 whereby the profile items and categories are displayed on the terminal screens 302, 311, 317, 319 and the like described in FIG. 3B. The relevant items are selected in step 719 to complete the profile, which is stored as an SDP service record in the SDP database 209 or as an OBEX file in the profiles database 211. In step 729 the user is queried to determine interest in completing other profiles. A “yes” selection transfers the process to entry point B in FIG. 5 for repeat of steps 711 and 713. A “no” selection transfers the process to entry point C in FIG. 5, where the profile editing menu is exited in step 731. In FIG. 6, if the user wishes to enter a non-standard profile in either the SDP database 209 or the profile database 211, e.g. a User/Manufacturer Defined Profile 312 (FIG. 3A), step 722 is performed to assign a name to the profile. A name or format assigned is assigned to the item in step 724 and a value is assigned to the item in step 725. A test 728 is performed to determine if additional items are to be defined. A “yes” selection returns the process to step 724. A “no” selection transfers the process to step 729 where a “yes” selection returns the process to entry point B and steps 711, 713 in FIG. 5, as previously described in FIG. 5. A “no” selection returns the process to entry point C in FIG. 5, as previously described. FIG. 7 describes a process 800 for an inquiring Bluetooth terminal or Access Point 801, such as the inquiring device 119 of FIG. 1, to access the personal profile of the user's Bluetooth Terminal 803, such as the user's wireless terminal 101 of FIG. 1, having user profile support, using the Bluetooth packet structure and SDP Service Search Request format. In step 805, the inquiring terminal 801 transmits a user Bluetooth inquiry 805 and the user 803 responds with an inquiry response 807. The inquiring terminal 801 sends an SDP inquiry in step 809 to determine whether the user's terminal support's user personal profiles. In step 811, the user 803 provides an SDP inquiry response indicating that the personal profiles are available. The inquiring terminal 801 reads all or part of the profiles and submits multiple SDP inquiries, if necessary, in step 813. The user 803 responds to the SDP inquiries in step 815. The inquiring terminal 801 retrieves more detailed contact information profiles, not available to SDP, by means of an OBEX request 817 using object exchange protocols. Object exchange (OBEX) protocols are described in the Infrared Data Association, Version 1.2, PO Box 3883, Walnut Creek, Calif. USA 94958. Multiple OBEX requests 817 may be made by the inquiring terminal 801 and the user 803 provides OBEX responses to the requests in step 819, after which the process ends. FIG. 8 describes an alternative embodiment for storing user profiles outside the user's mobile terminal 850. The profiles may be stored in a user profile server 851 linked to the desktop computer or laptop 853 via Internet 855. The user may use the desktop computer or laptop 853 to create, edit and alter profiles in the profile server. The user's mobile terminal 850 has access to the profile server 851, via a Wireless Application Protocol (WAP) gateway 857, serving a cellular telephone network 861 to which the mobile terminal 850 has access. The gateway implements the Wireless Application Protocol supported by and available from the WAP Forum. Any Bluetooth inquiries for personal profiles can be sent to the user profile server 851, via the WAP gateway linked to the Internet for accessing the user profile server. The profiles are downloaded to the user's mobile terminal 850 for response to inquiries from other terminals in an ad hoc network. Storing the personal profiles in the server 851 reduces the storage load on the phone book, SDP, and profile databases in the user's mobile terminal shown in FIG. 2. The resulting invention enables the user of a wireless, mobile terminal to install a personalized user profile in his/her terminal and to update that profile in real time. For example, the invention enables a sales representative to update his/her virtual business card in real time to match the perceived interests of a potential customer. As another example in a dating/match-making scenario, during a chance meeting involving the exchange of virtual business cards, the user may can modify his/her personal interest information in real time, to match the perceived interests of the other user. In an alternate embodiment of the intention, a push-mode enables the user's terminal to broadcast user profile information. FIG. 9 is a network process diagram of an embodiment of the invention using profile push and profile comparison between two Bluetooth devices. Inquiring device 119, user's terminal 101, and wireless device 121 engage in a Bluetooth device inquiry stage 905. Then, inquiring device 119 sends a profile push message 907 to the user's terminal 101. The profile push message 907 contains enough information to characterize the profile in inquiring device 119 so as to enable user's terminal 101 to compare the similarity between the user profiles in the two devices. Such characterizing information can be some limited information about the user or the user's device 119, for example. Such characterizing information can be a bit mask, which can be examined by the user's terminal 101 in step 908, comparing its value with reference bit mask values indicating any generic interests. In this example, user's terminal 101 determines at step 908 that the two user profiles compare sufficiently to justify expressing an interest in obtaining more information about the profile of inquiring device 119. Then the user's terminal 101 returns a profile response 909, such as “I'm interested”, to the inquiring device 119. In the meantime, the inquiring device 119 sends another profile push message 911 to the wireless device 121, similar to message 907. In this example, the wireless device 121 determines at step 912 that the two user profiles do not compare Then the wireless device 121 returns a profile response 913, such as “Not interested”, to the inquiring device 119. In response to the profile response 909, “I'm interested”, sent by the user's terminal 101 to the inquiring device 119, the inquiring device 119 prepares to send personal information in step 914. The inquiring device 119 sends a profile message 925 to the user's terminal 101 with the profile information “My Phone Number”. FIG. 10 is a network process diagram of the embodiment of FIG. 9, adding authentication between the two Bluetooth devices. Following step 914, the inquiring device 119 sends an authentication request 915 to the user's terminal 101. In step 916, both users input the same PIN on their respective devices 101 and 119. Then the user's terminal 101 returns an authentication response 917 to the inquiring device 119. Then, the inquiring device 119 sends the profile message 925 to the user's terminal 101 with the profile information “My Phone Number”. In another alternate embodiment of the intention, the user's short-range wireless terminal can share information in its personal profile with the inquiring wireless terminal, if their respective user profiles match within a predefined tolerance. In another alternate embodiment of the intention, the user's short-range wireless terminal can share the general information portion of his/her local user profile with another short-range wireless terminal, if their respective user profiles have a first level of close matching. If their respective user profiles have a second level of closer matching, the two terminals can further share more detailed information in their respective user profiles. General information can be transferred in a push model, without authentication of the receiving party and even without Bluetooth encryption. However, sending of the more detailed, private part of the user's profile should be protected by Authentication and Encryption. For example, before sending the more detailed, private part of the profile, the sending device triggers the exchange of the Bluetooth PIN between the sender and the receiver (if that has not been done before) to turn on the encryption of the baseband connection. In the same way, and in the case of the Pull model, the Pull request for the more detailed, private part of the profile triggers the device owning the profile to request Authentication of the device that issues the Pull request. Bluetooth Authentication usually requires that the two users exchange the PIN outside the channel, such as orally. In some scenarios, this may not desirable. The invention provides other ways for the two users to share a secret without orally communicating with each other. The server 129 in FIG. 1 can provide matchmaking via Bluetooth links by registering users, such as the users of devices 101 and 119. Registration can include checking user qualifications for matchmaking, such as being above a certain age. Then, when the two respective registered users of devices 101 and 119 try to exchange privacy sensitive information without having to actually engaged in a conversation with each other, they link to the server 129, which delivers the same PIN to both devices 101 and 119, thereby enabling the Bluetooth Authentication procedure to run automatically in the background for both devices 101 and 119. In addition to the Bluetooth standard, the resulting invention applies to wireless standards such as the IEEE 802.11 Wireless LAN standard, the HIPERLAN standard, the IEEE 802.15 Wireless Personal Area Network (WPAN) standard, the Infrared Data Association (IrDA) standard, the Digital Enhanced Cordless Telecommunications (DECT) standard, the Shared Wireless Access Protocol (SWAP) standard, the Japanese 3rd Generation (3G) wireless standard, and the Multimedia Mobile Access Communication (MMAC) Systems standard of the Japanese Association of Radio Industries and Businesses. While the invention has described in connection with a preferred embodiment, various changes can be made without departing from the spirit and scope of the invention. Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7143149 *Sep 21, 2001Nov 28, 2006Abb AbDynamic operator functions based on operator positionUS7255277 *Apr 6, 2006Aug 14, 2007Dragos Iii JohnMethod of designating dating statusUS7395268 *Jun 23, 2004Jul 1, 2008Nec Infrontia CorporationAddress link system, method and program productUS7551888Apr 14, 2003Jun 23, 2009Nokia CorporationMethod and system of displaying content associated with broadcast programUS7603106 *Jan 25, 2008Oct 13, 2009Cvon Innovations LimitedSystem and method for determining mobile device capabilitiesUS7801058 *Jul 20, 2007Sep 21, 2010Mobitrum CorporationMethod and system for dynamic information exchange on mesh network devicesUS7965983Dec 4, 2006Jun 21, 2011Sprint Spectrum L.P.Method and system for conveying medical information to a medical service personUS8073437 *Oct 20, 2006Dec 6, 2011Lg Electronics Inc.Mobile communication terminal for providing contents and method thereofUS8081954 *Oct 5, 2009Dec 20, 2011Apple Inc.System and method for determining mobile device capabilitiesUS8081956 *Oct 5, 2009Dec 20, 2011Apple Inc.System and method for determining mobile device capabilitiesUS8086177 *Apr 29, 2004Dec 27, 2011Orange FranceCommunication device for a landborne vehicleUS8095124 *Oct 20, 2006Jan 10, 2012Verizon Patent And Licensing Inc.Systems and methods for managing and monitoring mobile data, content, access, and usageUS8254880Jan 24, 2008Aug 28, 2012Apple Inc.Access controlUS8331952 *May 27, 2003Dec 11, 2012Core Wireless Licensing S.A.R.L.Method of enabling a wireless information device to access location dataUS8473614Jan 24, 2008Jun 25, 2013Apple Inc.User interface for collecting criteria and estimating delivery parametersUS8561145 *Dec 7, 2005Oct 15, 2013Samsung Electronics Co., Ltd.Service providing method using profile information and system thereofUS8606292May 21, 2010Dec 10, 2013Sprint Spectrum L.P.Methods and systems for limiting mobile station operation in a group settingUS8634826 *Mar 26, 2010Jan 21, 2014Sprint Spectrum L.P.Use of in-vehicle femtocell as basis to limit operation of in-vehicle wireless communication deviceUS8874104Jan 20, 2014Oct 28, 2014Sprint Spectrum L.P.Use of in-vehicle femtocell as basis to limit operation of in-vehicle wireless communication deviceUS8892037 *Nov 12, 2007Nov 18, 2014Maeglin SoftwareMethods and systems for community-wide information exchange via individual communications terminalsUS8914024Jan 9, 2009Dec 16, 2014Ximoxi, Inc.Discovery of network members by personal attributesUS8990103Aug 2, 2010Mar 24, 2015Apple Inc.Booking and management of inventory atoms in content delivery systemsUS8996402Aug 2, 2010Mar 31, 2015Apple Inc.Forecasting and booking of inventory atoms in content delivery systemsUS20060168137 *Dec 7, 2005Jul 27, 2006Samsung Electronics Co., Ltd.Service providing method using profile information and system thereofUS20100150021 *Dec 17, 2008Jun 17, 2010Verizon Corporate Resources Group LlcDevice-optimized transmission and reception for multi-mode, multi-media communicationsUS20100287052 *Oct 22, 2009Nov 11, 2010Minter David DShort-range commercial messaging and advertising system and mobile device for use thereinUS20120029992 *Jul 27, 2011Feb 2, 2012Pasquale De FacendisSystem and method for maximizing value through collaboration and pooling of buyers, sellers and parties with common interestsUS20120040615 *Nov 12, 2007Feb 16, 2012Auriffeille Jean-FrancoisMethods and systems for community-wide information exchange via individual communications terminalsUS20140317212 *Jun 30, 2014Oct 23, 2014Linkedin CorporationInline mediaUS20140370876 *Sep 3, 2014Dec 18, 2014Lexmark International, Inc.Provisioning User Attributes for use with Mobile Computing DeviceWO2009088366A1 *Jan 5, 2009Jul 16, 2009Jook IncProfile exchange method and systemWO2009088367A2 *Jan 5, 2009Jul 16, 2009Jook IncProfile management method and systemWO2009088369A1 *Jan 5, 2009Jul 16, 2009Jook IncSelective wireless communicationWO2009121027A2 *Mar 27, 2009Oct 1, 2009LogincubeCreating online resources using information exchanged between paired wireless devices* Cited by examinerClassifications U.S. Classification370/338, 370/401, 370/352International ClassificationH04L29/08, G06F13/00, H04L12/56, H04L12/28, H04L29/06, G06F17/30Cooperative ClassificationH04L67/04, H04L67/36, H04L67/306, H04L63/08, H04L63/102, H04L63/0428, H04W8/18, H04L29/06European ClassificationH04L63/10B, H04L29/08N35, H04L29/06, H04L29/08N29U, H04L29/08N3RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services