OVER A PERSONAL AREA NETWORK

CROSS REFERENCE TO RELATED APPLICATION

[0001] The present application is a non-provisional filing of, and claims benefit under 35 U.S.C. §119(e) from, U.S. Provisional Patent Application Serial No. 62/165,773, filed May 22, 2015 and entitled "Context Information Exchange Over a Personal Area Network", the contents of which are incorporated herein by reference in their entirety.

BACKGROUND

[0002] Individuals frequently carry multiple devices at one time, such as a smartphone, a tablet computer, a smartwatch, and a laptop computer. Each generation of such devices is more versatile than the last. Not long ago, it was common to use a mobile phone merely for voice and SMS communications, whereas nowadays a mobile phone may have the computing power of a previous-generation laptop. Modern mobile devices may also include of a myriad of sensors such as satellite navigation receivers and acceleration sensors. An even more dramatic advance is taking place in wearable devices, especially with respect to watches. A few years ago, a state-of- the-art smartwatch contained little more than a barometer and compass, whereas today a smartwatch is a miniature smartphone with sensors for measuring parameters as wide-ranging as heartrate and skin conductivity.

SUMMARY

[0003] In at least one embodiment, a plurality of devices is communicatively connected via a personal area network (PAN)— also referred to as a piconet. The devices in the PAN exchange context information and, based on the exchanged context information, may coordinate context changes. The exchanged context information may include, for example, an indication that a given PAN device has detected a context change. Additionally or alternatively, the exchanged context information may include sensor data obtained by the respective devices in the PAN, and one or more of the PAN devices may detect a content change based on the exchanged sensor data. For example, a given PAN device may detect a context change based on sensor data obtained via one or more sensors of the given device. As another example, the given device may detect a context change based on sensor data received from a second device in a PAN, the received sensor data in turn having been obtained by a second-device sensor of the second device.

[0004] In at least one embodiment, user devices communicate within the PAN. The devices share context information with each other and change context accordingly. Various of the embodiments relate to data sharing of the PAN illustrated in FIG. 1.

[0005] In at least one embodiment, whenever a context is detected by or changed in one PAN device, all other PAN devices activate the same context. Devices that are not present (and thus are not in the PAN) may not need to be aware of the context change.

[0006] In at least one embodiment, one or more devices are configured to establish a PAN, which is then used to share context related information between accompanying devices. A PAN device that detects context change (perhaps by user interaction) informs other devices in the same PAN of the detected context change, and the other devices change their respective contexts accordingly.

[0007] In an exemplary embodiment, a method is provided of restricting access to personal data (such as sensor data) at a second device based on context change at a first device. In the exemplary method, information is received at the second device that identifies a first context that was selected by the first device. In response to the received information, the first context is selected at the second device. In response to selection of the first context, personal data access on the second device is restricted so as to permit access only to personal data associated with first context.

[0008] In another exemplary embodiment, a method is provided of coordinating personal data access across devices of a user. In the exemplary method, a first device of the user is operated in a first context, where the first context has first data access permissions. The first device switches from the first context to a second context, where the second context has second data access permissions that are different from the first data access permissions. The switch to the second context may be performed as a result of user input to the first device or may be initiated automatically in response to detection by one or more sensors of the first device that the context should be changed. In response to the switching to the second context, information is sent to a second device of the user identifying the second context. In response to the sent information, the second context is selected at the second device. In response to selection of the second context at the second device, personal data access on the second device is restricted so as to permit access only to personal data associated with the second context. [0009] In a further exemplary embodiment, a system is provided for restricting access to personal data at a second device based on context change at a first device. The system includes a second device with a processor and a non-transitory computer-readable storage medium storing instructions operative, when executed on the second device processor, to perform functions including: (i) receiving information identifying a first context selected by the first device; (ii) in response to the received information, selecting the first context at the second device; and (iii) in response to selection of the first context, restricting personal data access on the second device so as to permit access only to personal data associated with first context. The system may further include a first device that has a processor and a non-transitory computer-readable storage medium storing instructions that are operative, when executed on the first device processor, to perform functions including: (i) operating the first device in a first context having first data access permissions; (ii) switching the first device from the first context to a second context; and (iii) in response to switching to the second context, sending information to the second device of the user identifying the second context.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1 is a functional block diagram illustrating an architecture in which a plurality of user devices coordinate to share context information.

[0011] FIG. 2 depicts example user interfaces of a context-enabled smartphone.

[0012] FIG. 3 illustrates an architecture in which sensor data and context control are shared in a personal area network (PAN).

[0013] FIG. 4 is a flow chart illustrating a method of coordinating contexts among user devices over a PAN.

[0014] FIG. 5 is a schematic block diagram of a wireless transmit-receive unit (WTRU) that may be employed as a user device in some embodiments.

DETAILED DESCRIPTION

[0015] Once a user has established a personal area network (PAN), the network generally follows the movements of the user. For example, portable devices such as a user's smartphone and smartwatch generally move around in conjunction with the movements of the user. However, as the user moves around, other devices may join or drop away from the PAN. For example, some devices such as thermostats, smart appliances, and in-vehicle accessories may join or drop out of the network as the user approaches or distances himself from those devices. [0016] Embodiments are described herein in which devices in a PAN select a user context and share information about that context, thereby allowing other devices in the PAN to select the corresponding context and to implement data access restrictions according to the selected context. In some embodiments, a device in the PAN selects a context based on sensor data, e.g. based on a location as determined by a global positioning system (GPS) chipset. In some embodiments, a device in the PAN selects a context based on the identity of other devices in the network. For example, presence of an in-vehicle accessory in the network may indicate that the user is in a vehicle and may thus lead to selection of an appropriate context for vehicular activity.

[0017] In some situations, when a new device joins a PAN, the newly added device may have a context different from the context of other devices already in the network. For example, the context of a device that has just-recently powered on and joined the PAN may be a default context because the device has not received any recent sensor data from which context may be determined. The default context may differ from the contexts of the other devices in the PAN that have been receiving context information and updating context accordingly while the joining device was powered off.

[0018] As another example, a device may be operating outside a PAN using one context, and that device may subsequently join the PAN. For example, the device may move into range of the PAN, or the network may move into range of the device. This may occur where a user has an active PAN established among devices he is carrying, and, for example, he returns to a location where his laptop was left behind; the laptop may then join the network. However, the newly joining device may have selected a different context. For example, a laptop left at work may remain in a "work" context, while the smartphone and smartwatch carried with the user select a "commuting" context. The selection of different contexts may be the result of different sensor data collected at the newly joining device as compared to sensor data collected at the devices in the PAN.

[0019] To resolve conflicts between a context selected by a newly joining device and a context selected by the devices previously in the PAN, the joining device may present the user with an option to resolve the context conflict manually. The user may further be presented with the option of whether to continue resolving such conflicts in the future on a case-by-case basis or whether the user's choice of context should set a permanent rule that memorizes context changes related to the particular devices. In one embodiment, a context conflict is resolved automatically between the devices of the PAN. For example, the devices (both existing and joining) may compare timestamps of respective sensor measurements and/or context changes and may resolve the context conflict based on the timestamps. Recent measurements and context changes may be given priority over less-recent measurements or changes. In such an example, a device that was recently powered on could advantageously inherit the context from other devices in the PAN. As another example, the devices in the PAN may compare locations at which respective sensor measurements were obtained and/or where respective context changes were detected. Measurements and changes that are nearer to the PAN's current location (which may include measurements/changes of the joining PAN device) may be given priority over those that are less near.

[0020] In an embodiment, a context conflict is resolved via user input from one or more of the PAN devices. For example, upon detecting a context conflict, a given PAN device may prompt the user (via a user interface) to select a valid context. In response to receiving a context selection via the user interface, the PAN device may set its context (or the context of one or more other devices in the PAN) based on the received context selection.

[0021] The PAN device may further store information regarding a given context conflict and how the context conflict was resolved. Consider, for example, a case in which the given device was in a first context at a first location when it became disconnected from the PAN. Later, the device reconnects with the PAN when the other devices in the PAN are in a second context. This gives rise to a potential conflict, with the devices already in the PAN being in one context and the rejoining device being in a different context. The user may be presented with an option (e.g. through a user interface) to resolve the conflict by selecting between the context of the rejoining device (the first context) and the context of the PAN (the second context). If the user selects the first context, then the other devices in the PAN may switch to the first context as well, and a conflict-resolution rule may be generated to implement the user's decision in future analogous situations. For example, a conflict-resolution rule in this instance may be the following:

IF (DeviceA left PAN while in First Context) AND (Device A rejoins PAN when PAN is in Second Context) THEN (Set PAN to First Context)

[0022] In some embodiments, a conflict-resolution rule may be based at least in part on a detected location change. For example, the conflict-resolution rule in the previous example may contain the additional step of checking if a street address is the same as in the memorized rule. For example, the rule may be, for example, as follows:

IF (DeviceA left PAN while in First Context at Address B) AND (Device A rejoins PAN when PAN is in Second Context at Address B) THEN (Set PAN to First Context) Those of skill in the art will appreciate that additional and/or different logic may be added to the conflict-resolution rules.

[0023] The PAN network could be based on Bluetooth, which is one of the more-popular PAN technologies. For example, context information, sensor data, etc., may be sent as one or more packets over a Bluetooth communication link via a radio frequency communication (RFCOMM) serial interface. Each context may have a unique identifier (UUID) that can be shared via the PAN.

[0024] Context selection may employ complex logic and/or may employ fuzzy logic. In some embodiments, the more sensor data available to a given PAN device, the better the context selection by the device. Data from accompanying devices may also be used in selection of the context.

[0025] In another exemplary embodiment, a user has defined multiple contexts, which can be selected on a plurality of devices. The devices are capable of accessing personal information from a common repository for one or more PAN devices. For example, FIG. 1 illustrates an architecture in which a user has a plurality of devices capable of communicating over a PAN, such as a music player 102, a smartphone 104, a smartwatch 106, a vehicle (or in-vehicle accessories) 108, and other internet of things (IoT) connected devices 110, 112, which may be, for example, home appliances or home automation devices or sensors. These devices may communicate with one another over a personal area network 114. The personal area network 114 may be implemented using direct short-range radio connections among the devices.

[0026] Personal data of the user may be stored in data storage of the individual devices or it may be stored in, for example, a raw data module 116. Raw data module 116 may be implemented in cloud-based storage. In some embodiments, a context agent 1 18 is associated with each user and serves as a software-based user agent for transactions with a marketplace infrastructure 120. The marketplace infrastructure 120 may operate to enable exchange of information and incentives between users and organizations 122. For example, organizations 122, such as online retailers, may seek personal data of consumers through the marketplace infrastructure 120 and may offer incentives (such as payment or discounts) to consumers who are willing to share such data. The context agent 1 18 of each user may operate automatically based on individual user preferences to determine whether, in each case, the offered incentives are sufficient. If the offered incentives are sufficient, the context agent 118 may operate to release a requested portion of user data (which may be anonymized) to the marketplace 120 to provide to the requesting organization. The marketplace 120 may itself introduce additional anonymity, e.g. by aggregating personal data from several users before providing the data to organizations 122. [0027] In an exemplary embodiment, the personal data that is accessible to devices in a PAN depends on the context of the devices at a particular time. The PAN devices are capable of sharing context information over a PAN and when one device changes context, the accompanying devices switch context accordingly.

[0028] In some embodiments, the sensors of the user devices in FIG 1 may further operate to update data in the raw data module 116. Personal data in the raw data module 116 may include data that identifies or otherwise relates to a user's location, and the user's personal location may be updated by the device in which a respective sensor is active. Based on the availability of sensor data, devices such as smartphones may operate to determine an individual's context. Context can also be explicitly set by the user by launching an application distinctly related to a specific context, e.g. launching the application from a specific context module, as illustrated by the user interface of FIG. 2. FIG. 2 illustrates the user interface of an exemplary smartphone on which different contexts may be selected, e.g. "My Friends," "My Work," "My Commuting," "My Games," and "My Finance." Applications launched from a selected context use data permissions associated with the selected context. A user may also have access to a menu through which different data permissions may be selected for different contexts. For example, in the "My Commuting" context, access to data with the attribute "Contact Info" is turned "on", indicating that there is an association between the "My Commuting" context and the "Contact Info" personal data attribute. Similarly, in the "My Commuting" context, access to data with the attribute "Calendar Data" is turned "on", indicating that there is an association between the "My Commuting" context and the "Calendar Data" personal data attribute. However, in the "My Commuting" context, access to data with the attribute "Location" is turned "off, indicating that there is no association between the "My Commuting" context and the "Location" personal data attribute.

[0029] The associations between contexts and personal data attributes may be stored in various ways and in various locations. For example, the associations may be stored in the raw data module 116, which may be implemented on cloud data storage. The associations may be stored on individual devices (which may then synchronize via the PAN or other network connection). In some embodiments, a list of associated personal data attributes is stored for each of the different contexts, indicating the personal data that is accessible to applications running in each respective context. In some embodiments, for each personal data attribute, a list is stored identifying the associated contexts, thus indicating those contexts in which the respective personal data is accessible. In some embodiments, a table of personal data attributes and contexts may be stored, where each entry in the table is associated with a personal data attribute and a context, and where each entry indicates whether that attribute is associated with that context and thus can be accessed by applications running in that context.

[0030] In some embodiments, each device in the PAN has one or more sensors. Sharing of sensor data may be enabled or disabled on a per-sensor basis depending on the current context. In general, the more sensor data available to a given PAN device, the better the context detection by the device. Accordingly, to facilitate more-reliable context changes by other PAN devices, a given PAN device may exchange sensor data with the other PAN devices even though access to that sensor data in a common repository would otherwise be restricted based on a current context. Sensor data may shared within the PAN even when providing the data is disabled, in order to determine context changes more reliably. The given PAN device may (but is not required to) thereafter exclude the sensor data from any exchanges of context information with other PAN devices. Context change may depend on sensor data from multiple devices.

[0031] FIG. 3 illustrates an architecture in which sensor data (in addition to or instead of context control) may be shared among devices within the PAN before sensor visibility is selected. Both sensor and context data may be shared before selecting sensor visibility.

[0032] An exemplary functional architecture of a context-enabled user device 300 is illustrated in FIG. 3. The user device 300 is provided with one or more sensors 302 that provide data used to determine a user's current context. The user device is further provided with a wireless PAN interface 304 that may be used for communication with other devices in the PAN. In some exemplary embodiments, data from the sensor or sensors 302 may be accessed by other devices in the PAN over the wireless PAN interface 304 through a sensor application program interface (API) 306. The sharing of sensor data by more than one device in the PAN may allow more accurate determination of a user's current context. For example, GPS and WiFi sensor data from one device (such as a smartphone) may determine that a user is in a cafe, while accelerometer data from another device (such as a smartwatch) may provide a pattern of data useful for determining a specific activity of the user in the cafe (e.g. staccato movements associated with typing vs. slow movements associated with reading).

[0033] The data from sensors 302 may also be provided to a context selection module 308. In some embodiments, the context selection module 308 may also operate to receive data from other sensors in the PAN through the wireless PAN interface 304. The context selection module 308 operates to select a context of the user based on the sensor data. Through a context API 310, the user device 300 may share with other user devices in the PAN information identifying the selected context. In some embodiments, when the context selection module 308 detects a new user context based on the sensor data, the context selection module switches to the newly- detected user context and reports the newly-detected user context to other devices in the PAN over the wireless PAN interface 304. In some embodiments, when other user devices report to user device 300 that a new context has been selected by the other device, the context selection module 308 switches to a context selected by the other device. Other devices in the PAN may operate to select a context according to the same logic. Thus, in exemplary embodiments, all devices in a PAN switch to the context that was most recently detected by one of those devices. In some embodiments, this switching of context is performed only after user approval of the context switch. The user device 300 is provided with a user interface 318 through which the context selection module 308 may request and obtain approval for the context switch. The user interface 318 may further be used by the context selection module 308 to resolve conflicts between different context determinations.

[0034] In exemplary embodiments, context changes are reported only over the PAN using short-range wireless (e.g. radio) communications and are not reported over, for example, the internet. Otherwise, an eavesdropper with access to one of the user's devices (e.g. a laptop left at work) could potentially monitor the user's activities by monitoring changes to the context selected by the other devices.

[0035] In the device 300, the context selection module 308 identifies the selected context to a data access control module 312. The data access control module 312 applies different data access control rules for different selected contexts. In an exemplary embodiment, the user device 308 includes a personal data store 314 that stores various items of personal data relating to the user. The device 300 is further provided with application software (e.g. "apps") 316. The applications 316 may seek access to various items of personal data; however, whether or not that item of personal data is available may depend on which context has been selected by the context selection module.

[0036] The data access control module 312 and the context selection module 308 may in some embodiments be components of an operating system of the user device 300. In other embodiments, one or both of the data access control module 312 and the context selection module 308 may be standalone applications. In some embodiments, the data access control module 312 includes a database, table, or other data structure that stores information that associates each type of personal data (e.g. each parameter) with those contexts in which that data is available. For example, a data structure may identify a type of personal data and may further include a list identifying each context in which that type of personal data is available to applications 316. Some embodiments may employ a two-dimensional table of data types and contexts, with each entry providing an indication (e.g. a bit or other flag) of whether or not that data type is available in the relevant context. Other types of data structures will be apparent to those of ordinary skill in the art in view of the present disclosure. Based on the selected context and on the type of data requested by an application, the data access control module 312 determines whether or not to provide the application with the requested personal data.

[0037] As an example, a sensor 302 (e.g. a GPS sensor) may provide to the context selection module 308 data indicating that the user is at his or her place of business. As a result, the context selection module 308 may select a "My Work" context and may report this selection to other devices in the PAN and to the data access control module 312. The user's personal credit card information may be stored in the personal data store 314. However, the data access control module 312 may prevent access to the personal credit card information while the user device 300 is in the "My Work" context. Thus, a request by an application 316 for access to the personal credit card information may be denied by the data access control module 312. However, the data access control module 312 may allow applications 316 to access business credit card data stored in personal data store 314 while the device 300 is in the "My Work" context. In some embodiments, the question of whether or not an item of personal data is accessible is resolved not by what application is requesting the data but by what context has been selected by the context selection module 308.

[0038] The data access properties controlled by the data access control module 312 may include both read access and write access, which may be separately defined in different contexts. For example, in some contexts, an item of personal data may be readable, but write access may be blocked. For example, in a web browser history (and or bookmarks) may be readable from several contexts but may be writeable only in a particular context. In some embodiments, the data access control module 312 further controls access to data generated by the sensors 302. For example, one or more sensors (such as a GPS chipset) may operate to determine a current location of a user, and access to that current location data may be controlled by the data access control module 312 based on the currently selected context. In some embodiments, that current location information (and/or other sensor data) may be stored in the personal data store 314, with the data access control module 312 controlling access to the data.

[0039] While the example of FIG. 3 illustrates a case in which the personal data 314 is stored on the device 300 itself, it should be noted that the principles described may also be applied to controlling access to personal data that is stored in a common data repository such as the raw data module 116.

[0040] In some embodiments, the PAN devices are capable of updating personal information in a common repository. The update depends on the context (as described with reference to the casino example below). The personal information may include sensor data obtained by one or more of the PAN devices. For example, the personal information may include a location detected by a Global Positioning System (GPS) receiver of a given PAN device. Access to the personal information and/or updates to the personal information (e.g., by an application executed by the PAN device) may be permitted, restricted, etc. based on a current context.

[0041] An exemplary method in accordance with some embodiments is illustrated in FIG. 4. In step 402, a first user device in a PAN receives sensor data (e.g. data from sensors within the first user device and/or data sent to the first user device from sensors in other devices). In step 404, the first device selects a new context based on the sensor data. In some embodiments, the first device receives user input in step 406, such as user selection of a context.

[0042] In step 408, in response to selection of a new context, the first device reports the context change over a PAN. In step 410, the first device operates to restrict access to personal data according to the selected context. In step 412, a second user device in the personal area network receives the indication that was sent in step 408 indicating that a new context was selected at the first device. In response to the indication, in step 414, the second device switches to the context identified by the first device. In step 416, the second device operates to restrict access to personal data based on the selected context.

[0043] In an exemplary use case, Franz is a part-time gambler but would not like others to know about his hobby. He has three mobile devices: a smartwatch, a smartphone and a tablet, and each of these has a GPS sensor and tracking software. When Franz goes to a casino, he usually takes both the smartphone and smartwatch with him, but generally leaves the tablet at home.

[0044] Franz has defined a Casino context in which sharing of location information is disabled (a similar example is depicted in FIG. 2 with respect to the "My Commuting" setup). Accordingly, upon leaving for (or arriving at) the casino, Franz switches the smartwatch to the Casino context (using, for example, a user interface of the smartwatch). The smartphone accordingly switches to the same context. While in the Casino context, the GPS tracking features of the smartphone and smartwatch are disabled.

[0045] Given that the tablet is not in the PAN, the tablet's GPS tracking features may remain enabled. Since one type of personal data in the Raw Data Module may be location, the tablet may continue to update the personal location data while the smartwatch and smartphone are in the Casino context (given that the tablet is not one of the accompanying devices for which GPS tracking was disabled). [0046] Casino mode may be terminated when, e.g., Franz selects another context via one of the accompanying devices. For example, when Franz returns home, the tablet would join the PAN, but with a different context than the other devices. If a context conflict exists between the tablet and the other PAN devices, Franz may be prompted to switch off the Casino context of the smartphone and smartwatch and/or prompted to switch the smartphone, tablet, and smartwatch to a different context.

[0047] Another example illustrating multi-device co-operation is related to a flight mode. All accompanying devices may enter a Flight context (flight mode) when one device makes a determination that the device user has entered an airplane. Devices owned by the user, but not currently with the user, might well stay in a preceding context without switching to the Flight context.

[0048] Use of some sensors, and/or PAN communication in general, may be prohibited under some circumstances, such as during takeoff, landing and taxiing. For example, a typical technology for PAN is short-range Bluetooth, the use of which may be prohibited except while the airplane is at cruising altitude.

[0049] However, use of sensors such as barometers and motion sensors may be permitted during takeoff and landing. Based on cabin pressure, a barometer may be capable of sensing cabin pressure changes, thus possibly detecting airplane take-off (decreasing pressure) and landing (increasing pressure), as well as detecting when the airplane is at cruising altitude (lower but stable pressure). Motion sensors may in turn detect vibration caused by taxiing or walking.

[0050] It may be advantageous for devices to exchange information and combine their data in order to set the context correctly. Though Bluetooth transmission may be prohibited during takeoff and landing, Bluetooth reception may be permitted since receivers do not interfere with avionics. Accordingly, a Bluetooth-capable device may disable Bluetooth transmission until the device determines that Bluetooth transmission is now permissible (e.g., based on one or more sensors) and/or until the device receives a page message indicating that Bluetooth transmission is permissible.

[0051] For example, a Bluetooth-capable smartwatch may include a barometer and may initiate Bluetooth paging upon sensing (via the barometer) that the cabin pressure has stabilized. Additionally or alternatively, the smartwatch may include a motion detector and may initiate paging upon determining that the smartwatch user is walking (which may indicate that the airplane has landed or that the "fasten seat belts" sign is turned off). In another embodiment, the smartwatch may initiate paging in response to receiving an instruction via a user interface to reestablish PAN communication. The Bluetooth transmitter of a Bluetooth-capable tablet may remain inactive until receiving the Bluetooth paging from the smartwatch. Upon detecting a change in cabin pressure via the barometer (thus possibly indicating takeoff or landing of the aircraft), the smartwatch may instruct other devices to disable Bluetooth transmission. Conversely, when one device (e.g. the device with the barometer) detects that the flight has landed (e.g. using a barometer and/or accelerometer), that device may transmit a signal to other devices in the PAN indicating that those devices can exit flight mode and can resume wireless communications. In this way, all devices in a PAN may enter and exit flight mode automatically even in cases where, for example, only one of those device is equipped with sensors used to detect whether or not the devices should be in flight mode.

[0052] Note that various hardware elements of one or more of the described embodiments are referred to as "modules" that carry out (i.e., perform, execute, and the like) various functions that are described herein in connection with the respective modules. As used herein, a module includes hardware (e.g., one or more processors, one or more microprocessors, one or more microcontrollers, one or more microchips, one or more application-specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), one or more memory devices) deemed suitable by those of skill in the relevant art for a given implementation. Each described module may also include instructions executable for carrying out the one or more functions described as being carried out by the respective module, and it is noted that those instructions could take the form of or include hardware (i.e., hardwired) instructions, firmware instructions, software instructions, and/or the like, and may be stored in any suitable non-transitory computer- readable medium or media, such as commonly referred to as RAM, ROM, etc.

[0053] Exemplary embodiments disclosed herein are implemented using one or more wired and/or wireless network nodes, such as a wireless transmit/receive unit (WTRU) or other network entity.

[0054] FIG. 5 is a system diagram of an exemplary WTRU 502, which may be employed as a user device in an PAN in embodiments described herein. As shown in FIG. 5, the WTRU 502 may include a processor 518, a communication interface 519 including a transceiver 520, a transmit/receive element 522, a speaker/microphone 524, a keypad 526, a display/touchpad 528, a non-removable memory 530, a removable memory 532, a power source 534, a global positioning system (GPS) chipset 536, and sensors 538. It will be appreciated that the WTRU 502 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0055] The processor 518 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 518 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 502 to operate in a wireless environment. The processor 518 may be coupled to the transceiver 520, which may be coupled to the transmit/receive element 522. While FIG. 5 depicts the processor 518 and the transceiver 520 as separate components, it will be appreciated that the processor 518 and the transceiver 520 may be integrated together in an electronic package or chip.

[0056] The transmit/receive element 522 may be configured to transmit signals to, or receive signals from, a base station over the air interface 516. For example, in one embodiment, the transmit/receive element 522 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 522 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, as examples. In yet another embodiment, the transmit/receive element 522 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 522 may be configured to transmit and/or receive any combination of wireless signals.

[0057] In addition, although the transmit/receive element 522 is depicted in FIG. 5 as a single element, the WTRU 502 may include any number of transmit/receive elements 522. More specifically, the WTRU 502 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 522 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 516.

[0058] The transceiver 520 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 522 and to demodulate the signals that are received by the transmit/receive element 522. As noted above, the WTRU 502 may have multi-mode capabilities. Thus, the transceiver 520 may include multiple transceivers for enabling the WTRU 502 to communicate via multiple RATs, such as UTRA and IEEE 802.11, as examples.

[0059] The processor 518 of the WTRU 502 may be coupled to, and may receive user input data from, the speaker/microphone 524, the keypad 526, and/or the display/touchpad 528 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 518 may also output user data to the speaker/microphone 524, the keypad 526, and/or the display/touchpad 528. In addition, the processor 518 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 530 and/or the removable memory 532. The non-removable memory 530 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 532 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 518 may access information from, and store data in, memory that is not physically located on the WTRU 502, such as on a server or a home computer (not shown).

[0060] The processor 518 may receive power from the power source 534, and may be configured to distribute and/or control the power to the other components in the WTRU 502. The power source 534 may be any suitable device for powering the WTRU 502. As examples, the power source 534 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), and the like), solar cells, fuel cells, and the like.

[0061] The processor 518 may also be coupled to the GPS chipset 536, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 502. In addition to, or in lieu of, the information from the GPS chipset 536, the WTRU 502 may receive location information over the air interface 516 from a base station and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 502 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0062] The processor 518 may further be coupled to other peripherals 538, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 538 may include sensors such as an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0063] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.