Patent Grant
7103313
This application is related to copending U.S. application Ser. No. 10/083,134, filed Feb. 27, 2002, entitled “Personal Profile Sharing and Management for Short-Range Wireless Terminals,” which is incorporated herein by reference in its entirety.
The present invention relates to short-range wireless communication systems, network and methods of operation. More particularly, the invention relates to automatic determination of Access point content and services by terminals in a short-range wireless communication system using the Bluetoooth Standard.
An ad hoc network is a short-range wireless system composed primarily of mobile wireless devices which associate together for a relatively short time to carry out a common purpose. A temporary network such as this is called a “piconet” in the Bluetooth Standard, an “independent basic service set” (IBSS) in the IEEE 802.11 Wireless LAN Standard, a “subnet” in the HIPERLAN Standard, and generally a radio cell or a “micro-cell” in other wireless LAN technologies. Ad hoc networks have the common property of being an arbitrary collection of wireless devices which are physically close enough to be able to communicate and which are exchanging information on a regular basis. The networks can be constructed quickly and without much planning. Members of the ad hoc network join and leave as they move into and out of the range of each other. Most ad hoc networks operate over unlicensed radio frequencies at speeds of from one to fifty-four Mbps using carrier sense protocols to share the radio spectrum. The distance over which they can communicate ranges from ten meters for Bluetooth ad hoc networks to over one hundred meters for wireless LAN micro-cells in an open environment. ad hoc networks consist primarily of mobile wireless devices, but can also include one or more access points which are stationary wireless devices, operating as a stand-alone server or connected as gateways to other networks.
Bluetooth is a short-range radio network, originally intended as a cable replacement. It can be used to create ad hoc networks of up to eight devices operating together. The Bluetooth Special Interest Group, Specification Of The Bluetooth System, Volumes 1 and 2, Core and Profiles: Version 1.1, Feb. 22, 2001, describes the principles of Bluetooth device operation and communication protocols. The devices operate in the 2.4 GHz radio band reserved for general use by Industrial, Scientific, and Medical (ISM) applications. Bluetooth devices are designed to find other Bluetooth devices within their ten-meter radio communications range and to discover what services they offer, using a service discovery protocol (SDP). The SDP searching function relies on links being established between the requesting Bluetooth device in a client role and the responding Bluetooth device in a server role. Once a link has been established, it can be used to find out about services in the responding Bluetooth device and how to connect to them.
Other wireless standards support ad hoc networks in addition to the Bluetooth standard, the IEEE 802.11 Wireless LAN standard, and the HIPERLAN standard. Examples include 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.
Bluetooth units have general behaviors through which they communicate with other units. These behaviors are called “application profiles”. There are 13 application profiles described in Version 1.1 of the specification, including the Generic Access Profile (GAP), Service Discovery Profile (SDP), Generic Object Exchange Profile (GOEP), and Object Push Profile.
The Generic Access Profile (GAP) defines how two Bluetooth units discover and establish a connection with each other. The service discovery protocol (SDP) defines the investigation of services available to a Bluetooth unit from other units. Generic Object Exchange Profile (GOEP) describes defines the set of protocols and procedures used by applications in handling object exchanges, e.g. File Transfer Synchronization using the Object Exchange (OBEX) Standard. The OBEX Standard is specified by the Infrared Data Association (IrDA), Object Exchange Protocol, Version 1.2. The OBEX Standard was adopted by Bluetooth as a binary HTTP protocol that allows multiple request/response exchanges. The Bluetooth Object Push Profile specification discusses the application of exchanging virtual business cards using the OBEX Standard.
Personal profiles are different from the official set of thirteen Bluetooth application profiles. Personal profiles are data sets intended to be exchanged between wireless mobile devices. Personal profiles provide information describing a user and his/her device to inform other users about the functionality and communication features of the user's device, and to inform about the characteristics and interests of the user. Currently, personal profiles are created by a user and sent to centralized servers operated by service providers for management and access by other users.
Bluetooth Access points provide TCP/IP services to the terminal applying the profile. A user terminal is capable of finding an Access Point service based on the Bluetooth Service Discovery Protocol (SDP). However, the terminal cannot obtain any additional/detailed information for the services content provided by the Access Point. If a user is interested only in some specific services/content, it is not useful to form the initial connection to all provided Access Points. Still the user cannot know the content before forming the connection and browsing the content.
What is needed is a mechanism or technique enabling a user terminal to automatically determine Access Point content and services during connection set-up and also to enable the Access Point to determine whether there is content to “push” to the terminal. Additionally, there is a need for a technique to provide information filtering in connection establishment between devices.
Prior art related to personal profiles includes EP 1 130 869 A1 entitled “Management of User Profile Data” by D. Mandata, published Sep. 5, 2001, filed Mar. 1, 2000. This reference discloses an Instant Message Broker (IMB) System to allow messages to be sent in near real time between users. IMB is a distributed processing system that integrates network technologies, such as IP and Mobil Telecomm networks, allowing users to access functionality, accomplish tasks and deliver process information to called parties. IMB includes a database for storing and managing user profile data, which represents sets of user information/or user preferences concerning the terminal device users have access to within information transmission. The database comprises for each user at least one customizable user profile, which can be created, edited and/deleted by the user. Each customizable user profile is associated with an environment of the user representing a physical location and/or a logical context of the user. The database comprises a plurality of user profiles for one user, wherein only one user profile of a user is active at the same time. Each subscriber can have a plurality of user profiles in a so-called user space which is a subscriber's own data space as provisioned within the user profile database. Users can define different context for different situations and dynamically switch between them. The currently used active context describes how the subscriber can be reached. The description includes an indication whether the user is currently on-line on a preferred terminal device. In addition, a set of alternative terminal devices is provided where the IMB subscriber may be contacted or not reachable at the preferred device. The alternative terminal devices can also be used for receiving additional copies of instant messages.
The prior art does not describe or suggest a wireless, mobile terminal containing personalized user profiles that are installed, edited by and managed by the user on the user's mobile terminal, the profiles containing a list(s) of content and services of interest to the user. Moreover, the prior art does not describe or suggest list(s) transmitted by an access point, the list transmitted to the access point with in the Service Discovery Protocol during connection set up time that enables the user to obtain information regarding content and services offered by the Access Point by matching Keywords and Types in the list with information in the user profile.
Further, the prior art does not describe or suggest an Access Point pushing information to the terminal where the pushed information matches the content and services described in the list contained in the profile.
To overcome limitations in the prior art described above, and to overcome other limitations that will be apparent upon reading and understanding the present specification, the present invention is directed to provide a method and an apparatus for storing a list of keywords, e.g. search words and a type list of information, e.g advertisement, news, indicative of content and services available at an Access Point and incorporating into the terminal profile a similar list of content and services by keyword and type where the keywords/types can be added/removed either inclusively or exclusively. The keywords and type of services of interest to the user are stored in a terminal database. On querying the Access Point within the Service Discovery Protocol during connection set-up, the Access point provides the list of keywords and types to the terminal. The user Keyword list and Types are matched to the Access point Keywords and Types list to determine if a connection should be established for matching Keywords and Type or terminated in the case of the failure of Keywords and Types of the Access Point and Terminal to match. The Access point may also connect to the terminal to obtain a list of the terminal Keywords and Types to determine if content is available to push to the terminal. Alternatively, other profiles may be stored at the Access Point to include keywords relating to WAP over Bluetooth, OBEX or a profile to store and maintain keywords. As a result, content services can be “advertised” automatically without the need for user interaction or obtained for special services. The content may be filtered within the Bluetooth communication.
In one aspect, an Access Point describes and stores content and services in terms of keywords and types in a list available from the Access Point or within outside networks connected to the Access point, and providing the content and/or services to a requesting terminal having keywords and types which match the keywords and types in the terminal within the Service Discovery Protocol and during connection set-up.
In another aspect, a personal profile in a terminal includes a field indicative of an Access Point service type of interest to the user, the field provided to the Access Point within the Service Discovery Protocol during connection set-up.
In another aspect, a personal profile in a terminal includes a field indicative of a content/topic of a service type of interest to the user and available from an Access Point.
In another aspect a personal profile in a terminal includes a field indicative of both the service type and content/topic of the service available from an Access point.
A feature of the invention is creating, editing and storing personal profiles of a user in a wireless, mobile terminal including keywords and types describing services and content of interest to a user for acquisition from an Access Point having matching keywords and content in an ad hoc network in a short-range communication system.
Another feature of the invention is storing all personal profiles of a user in a single Service Discovery Protocol (SDP) record, the record containing contact information, user or manufacturer defined information and standard format profiles of the user's interests including keywords and types of content and services that are of interest to the user and potentially available from an access point.
Still another feature of the invention is storing other profiles at the Access Point including WAP over Bluetooth, OBEX and storing and maintaining keywords and types as inclusive or exclusive keywords and exclusive and inclusive types.
The invention will be further understood from the followed description of a preferred embodiment taken in conjunction with the appended drawings.
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.
A content server 130 is coupled to access point 125 by network 127. Content server may store content that access point delivers information about, according to the present invention. Alternatively, the content may be stored locally by access point 125.
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.
Unlike the implementation of
In the ad hoc network 109 of
The user's terminal 101 can then send to the access point 125, 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 access point 125 to match in the service registry of its SDP database 262. If the access point 125 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 (i.e., the user's terminal 101) is requesting.
The SDP service registry in the SDP database 262 stores service records in a browsing hierarchy. The service records may be arranged into a hierarchy structured as a tree that can be browsed. The user's terminal 101 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 (e.g., the user's terminal 101) and the access point 125 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 access point 125 to match in its SDP service registry in the database 209. If the access point 125 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 user's terminal 101 is requesting. For example, the attribute ID list may identify attributes regarding content and service type. The SDP response packet returned by the access point 125 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 user's terminal 101.
As described above, an inquiry response packet from the access point 125, has sufficient information to enable the user's terminal 101 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 access point 125, includes a class-of-device (CoD) field. In one aspect of the invention, whenever the access point 125 provides information regarding content and service type information available to inquiring devices, the access point 125 writes into the class-of-device (CoD) field of its inquiry response packet, its status as having content and service type information available.
The inquiring device 101 constructs the inquiry response table with the information in the inquiry response packets received from responding devices, such as the access point 125. The inquiry response table shows the essential information gathered by the link controller in the inquiring device 101, 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 access point 125, that have a class-of-device (CoD) field with the status of having its content and service type information available.
There are several options that can be programmed in the inquiring device 101, for processing the data gathered in the inquiry response table. The inquiring device 101 can be programmed to determine whether the class-of-device (CoD) field for a responding device has the status of having its content and service type information available. If so, then the inquiring device 101 can browse or search the SDP service records of the access point 125, since it is now known that they have content and service type 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 101 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 content and service type information available. This implementation is optional.
As described above, the CoD may act as a trigger for the SDP keyword searching. However, embodiments of the present invention, may not employ such dedicated CoD fields. Moreover, embodiments of the present invention may involve the access point 125 sending an SDP record that includes a generic indicator pointing out that content and service type information is available.
Profile 300 of
The sub-profile 3001 in
A sub-profile 3002 in
The sub-profile 3002 in
The sub-profile 3002 in
For automatically assessing content and services available from an access point, a keyword list and a type list 324 are included in the personal profile 300. The list 324 is matched against a keyword and type list stored in an Access Point and received within the Service Discovery Protocol during connection set up as will be described in
Responsive to screen 302 in
Table A is a representation of user personal profiles formatted in one SDP record, including contact information, standard user profiles including keyword and type lists 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 (
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
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 3061 in
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
Non-standard profiles 450, as shown in
Table B is a representation of the user profiles of
In
In
Now returning to
This process begins with a step 752. In this step, the user's terminal 101 sends an SDP request to the access point 125. This request indicates that the user's terminal 101 wishes to obtain one or more lists of keywords or service information. This request may be formatted as a Bluetooth Service Search Attribute Request packet.
Next, in a step 754, the user's terminal 101 receives an SDP response from the access point 125. This response includes one or more lists of keyword(s) In addition, this response may include additional parameters, such as one or more descriptors that each indicate a service type as shown in Table C. This response may be formatted as a Bluetooth Service Search Attribute Request packet. In a step 756, the user's terminal 101 displays the service types for user selection purposes and proceeeds to compare the list of keywords received in the response with keywords stored in the personal profile database 211. A software routine may be employed to perform the comparison.
In a step 758, the user's terminal 101 determines whether this response includes any exclusive keywords stored in the keyword database 106. The presence of exclusive keywords indicates that content and/or services that the user is not interested in. If so, operation proceeds to a step 760, where the connection between the user's terminal 101 and the access point 125 is terminated. Otherwise, a step 762 is performed. In this step, terminal 102 determines whether the response includes any inclusive keywords stored in keyword database 106. The presence of inclusive keywords indicates that content and/or services that the user is interested in. If so, then a step 768 is performed. Otherwise, operation proceeds to a step 764, where the connection between terminal 102 and access point 125 is terminated.
In step 768, the establishment of a session between the user's terminal 101 and the access point 125 continues. This step may include establishing secure link between the user's terminal 101 and the access point 125 through processes such as authentication. In addition, this step 768 may include the user's terminal 101 sending a request to the access point 125 for the delivery of content items. Examples of content items include hypertext documents, images, data files, database entries, multimedia broadcasts, and audio broadcasts. As described above with reference to
Situations may occur where the SDP response received in step 754 includes at least one exclusive keyword and at least one inclusive keyword. In embodiments of the present invention, a connection with the access point 125 may be established, pursuant to step 768, even when matches exist with both one or more exclusive keywords and with one or more inclusive keywords. Accordingly, in these embodiments, when an exclusive keyword match is identified in step 758, operation continues to step 762 so that the user's terminal 101 may determine whether any inclusive keyword matches exist that indicate content that is interesting to the user.
Following step 768, optional steps 770–776 may be performed. These steps involve the access point 125 determining whether there is information that it may automatically deliver or “push” to the user's terminal 101 without first receiving a specific request. In step 770, the access point 125 sends to the user's terminal 101 a request for the keywords stored in the personal profile database 211. In response, a step 772 is performed. In this step, the user's terminal 101 retrieves the keywords stored in its personal profile database 211 and sends these keywords to the access point 125.
Next, in a step 774, the access point 125 compares the list of keywords with each of the lists of keywords stored in SDP database 262 and determines whether to send any corresponding content. During this step, the access point 125 determines whether any of the lists in its SDP database 262 contain any exclusive keywords received from the user's terminal 101. If so, then the access point 125 does not send content associated with these lists. In addition, the access point 125 determines during step 774 whether the remaining lists contain any inclusive keywords received from the user's terminal 101. If so, then content corresponding to the these inclusive keywords is designated for transmission to the user's terminal 101. In step 776, the access point 125 sends the content designated for transmission step 774 to the user's terminal 101.
The steps of
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.
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
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.
For example, the present invention may be employed in WLAN environments, where end-users are served by various WLAN networks. In some WLAN environments, end users are not able know all the WLAN network names (SSIDs) which are capable to serving them. Therefore, end user terminals may receive communications from access points that contain SSIDs. In certain environments, access points may transmit SSID in Beacon frames. However, in other environments, SSIDs may be obtained through the use of probe messages, as described in IEEE 802.11-01/658r0. This document is incorporated herein by reference in its entirety.
These probe messages involve a user terminal transmitting one or more Probe_Request messages that each request an SSID. If an access point supports the requested SSID, it replies with a Probe_Response message that indicates an SSID that it supports. The present invention, while described above in the context of SDP communications, may employ such probe messages to automatically determine access point content and services. Accordingly, in one such embodiment, the terminal may send a Probe_Request message to gather content and service type information, such as the aforementioned keywords and service types. An access point receives this request and, in return, transmits a Probe_Response message to the user terminal thast includes such content and service type information.
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.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5493692 | Theimer et al. | Feb 1996 | A |
| 5606617 | Brands | Feb 1997 | A |
| 5668878 | Brands | Sep 1997 | A |
| 5696827 | Brands | Dec 1997 | A |
| 5749081 | Whiteis | May 1998 | A |
| 5778304 | Grube et al. | Jul 1998 | A |
| 5790974 | Tognazzini | Aug 1998 | A |
| 5835061 | Stewart | Nov 1998 | A |
| 5838685 | Hochman | Nov 1998 | A |
| 5987099 | O'Neill et al. | Nov 1999 | A |
| 6006200 | Boies et al. | Dec 1999 | A |
| 6023241 | Clapper | Feb 2000 | A |
| 6041311 | Chislenko et al. | Mar 2000 | A |
| 6044062 | Brownrigg | Mar 2000 | A |
| 6049777 | Sheena et al. | Apr 2000 | A |
| 6052467 | Brands | Apr 2000 | A |
| 6064980 | Jacobi et al. | May 2000 | A |
| 6065012 | Balsara et al. | May 2000 | A |
| 6092049 | Chislenko et al. | Jul 2000 | A |
| 6108493 | Miller et al. | Aug 2000 | A |
| 6108688 | Nielsen | Aug 2000 | A |
| 6119101 | Peckover | Sep 2000 | A |
| 6138158 | Boyle et al. | Oct 2000 | A |
| 6138159 | Phaal | Oct 2000 | A |
| 6167278 | Nilssen | Dec 2000 | A |
| 6175743 | Alperovich et al. | Jan 2001 | B1 |
| 6182050 | Ballard | Jan 2001 | B1 |
| 6195651 | Handel et al. | Feb 2001 | B1 |
| 6195657 | Rucker et al. | Feb 2001 | B1 |
| 6199099 | Gershman et al. | Mar 2001 | B1 |
| 6205472 | Gilmour | Mar 2001 | B1 |
| 6236768 | Rhodes et al. | May 2001 | B1 |
| 6243581 | Jawanda | Jun 2001 | B1 |
| 6253202 | Gilmour | Jun 2001 | B1 |
| 6253203 | O'Flaherty et al. | Jun 2001 | B1 |
| 6263447 | French et al. | Jul 2001 | B1 |
| 6266048 | Carau, Sr. | Jul 2001 | B1 |
| 6272129 | Dynarski et al. | Aug 2001 | B1 |
| 6275824 | O'Flaherty et al. | Aug 2001 | B1 |
| 6285879 | Lechner et al. | Sep 2001 | B1 |
| 6317781 | De Boor et al. | Nov 2001 | B1 |
| 6321257 | Kotola et al. | Nov 2001 | B1 |
| 6330448 | Otsuka et al. | Dec 2001 | B1 |
| 6351271 | Mainwaring et al. | Feb 2002 | B1 |
| 6414955 | Clare et al. | Jul 2002 | B1 |
| 6421707 | Miller et al. | Jul 2002 | B1 |
| 6430395 | Arazi et al. | Aug 2002 | B1 |
| 6430413 | Wedi et al. | Aug 2002 | B1 |
| 6438585 | Mousseau et al. | Aug 2002 | B1 |
| 6445921 | Bell | Sep 2002 | B1 |
| 6477373 | Rappaport et al. | Nov 2002 | B1 |
| 6484196 | Maurille | Nov 2002 | B1 |
| 6493550 | Raith | Dec 2002 | B1 |
| 6496849 | Hanson et al. | Dec 2002 | B1 |
| 6510381 | Grounds | Jan 2003 | B1 |
| 6515974 | Inoue et al. | Feb 2003 | B1 |
| 6519453 | Hamada et al. | Feb 2003 | B1 |
| 6527641 | Sinclair et al. | Mar 2003 | B1 |
| 6539225 | Lee | Mar 2003 | B1 |
| 6542740 | Olgaard et al. | Apr 2003 | B1 |
| 6549768 | Fraccaroli | Apr 2003 | B1 |
| 6554707 | Sinclair et al. | Apr 2003 | B1 |
| 6560456 | Lohtia et al. | May 2003 | B1 |
| 6580698 | Nitta | Jun 2003 | B1 |
| 6625460 | Patil | Sep 2003 | B1 |
| 6674403 | Gray et al. | Jan 2004 | B1 |
| 6678516 | Nordman et al. | Jan 2004 | B1 |
| 6697018 | Stewart | Feb 2004 | B1 |
| 6721542 | Anttila et al. | Apr 2004 | B1 |
| 6785542 | Blight et al. | Aug 2004 | B1 |
| 20010021649 | Kinnunen et al. | Sep 2001 | A1 |
| 20010039546 | Moore et al. | Nov 2001 | A1 |
| 20020002705 | Byrnes et al. | Jan 2002 | A1 |
| 20020006788 | Knutsson et al. | Jan 2002 | A1 |
| 20020013815 | Obradovich et al. | Jan 2002 | A1 |
| 20020015042 | Robotham et al. | Feb 2002 | A1 |
| 20020019882 | Soejima et al. | Feb 2002 | A1 |
| 20020022453 | Balog et al. | Feb 2002 | A1 |
| 20020039882 | Ternullo et al. | Apr 2002 | A1 |
| 20020052873 | Delgado et al. | May 2002 | A1 |
| 20020061741 | Leung et al. | May 2002 | A1 |
| 20020065881 | Mansikkaniemi et al. | May 2002 | A1 |
| 20020082921 | Rankin | Jun 2002 | A1 |
| 20020083025 | Robarts et al. | Jun 2002 | A1 |
| 20020094778 | Cannon et al. | Jul 2002 | A1 |
| 20020126872 | Brunk et al. | Sep 2002 | A1 |
| 20020142792 | Martinez | Oct 2002 | A1 |
| 20020158917 | Sinclair et al. | Oct 2002 | A1 |
| 20020191017 | Sinclair | Dec 2002 | A1 |
| 20020193073 | Fujioka | Dec 2002 | A1 |
| 20020198882 | Linden et al. | Dec 2002 | A1 |
| 20030002504 | Forstadius | Jan 2003 | A1 |
| 20030008662 | Stern et al. | Jan 2003 | A1 |
| 20030013459 | Rankin et al. | Jan 2003 | A1 |
| 20030027636 | Covannon et al. | Feb 2003 | A1 |
| 20030036350 | Jonsson et al. | Feb 2003 | A1 |
| 20030054794 | Zhang | Mar 2003 | A1 |
| 20030092376 | Syed | May 2003 | A1 |
| 20030115038 | Want et al. | Jun 2003 | A1 |
| 20030119446 | Fano et al. | Jun 2003 | A1 |
| 20030119494 | Alanara et al. | Jun 2003 | A1 |
| 20030171147 | Sinclair et al. | Sep 2003 | A1 |
| 20030177113 | Wakita | Sep 2003 | A1 |
| 20030207683 | Lempio et al. | Nov 2003 | A1 |
| 20030208595 | Gouge et al. | Nov 2003 | A1 |
| 20040002948 | Mantyjarvi et al. | Jan 2004 | A1 |
| 20040181517 | Jung et al. | Sep 2004 | A1 |
| 20050136837 | Nurminen et al. | Jun 2005 | A1 |
| Number | Date | Country |
|---|---|---|
| 200135071 | Oct 2001 | AU |
| 1010909 | Mar 1999 | BE |
| 0 891 110 | Jan 1999 | EP |
| 0 944 176 | Sep 1999 | EP |
| 0 041 849 | Oct 2000 | EP |
| 1 041 849 | Oct 2000 | EP |
| 1 130 869 | Sep 2001 | EP |
| 1 187 023 | Mar 2002 | EP |
| 0 788 065 | Jun 2002 | EP |
| 1217792 | Jun 2002 | EP |
| 1271885 | Jan 2003 | EP |
| 1 282 289 | Feb 2003 | EP |
| 112999 | Feb 2004 | FI |
| 11 110401 | Jul 1999 | JP |
| WO 9749255 | Dec 1997 | WO |
| WO 9932985 | Jul 1999 | WO |
| WO 9937105 | Jul 1999 | WO |
| WO 9951048 | Oct 1999 | WO |
| WO 9966428 | Dec 1999 | WO |
| WO 0011563 | Mar 2000 | WO |
| WO 0011793 | Mar 2000 | WO |
| WO 0032002 | Jun 2000 | WO |
| WO 0069202 | Nov 2000 | WO |
| WO 0074424 | Dec 2000 | WO |
| WO 0135253 | May 2001 | WO |
| WO 0135269 | May 2001 | WO |
| WO 0139577 | Jun 2001 | WO |
| WO 0146826 | Jun 2001 | WO |
| WO 0150299 | Jul 2001 | WO |
| WO 0167799 | Sep 2001 | WO |
| WO 0182532 | Nov 2001 | WO |
| WO 0186419 | Nov 2001 | WO |
| WO 0203626 | Jan 2002 | WO |
| WO 0211456 | Feb 2002 | WO |
| WO 03017592 | Feb 2003 | WO |
| WO20044372 | Jan 2004 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20030228842 A1 | Dec 2003 | US |
