WO2009043020A2 - System and method for injecting sensed presence into social networking applications - Google Patents

Abstract

A method for injecting sensed presence into social networking applications includes receiving sensor data associated with a user (102), inferring a presence status of the user based upon analysis of the sensor data, storing the sensor data and presence status within a database, and sending the presence status to a social networking server (126) to update the user's presence information for the social networking applications based upon the user's preferences. A system for injecting sensed presence into social networking applications includes at least one sensor (110) proximate to a user, the at least one sensor being used for collecting sensor data associated with the user, a presence server (116) for receiving and storing the sensor data, an inference engine for analyzing the stored data and to infer a presence status for the user, and a presentation engine for presenting the information to the user and other users.

Description

SYSTEM AND METHOD FOR INJECTING SENSED PRESENCE INTO SOCIAL NETWORKING APPLICATIONS

RELATED APPLICATIONS

[0001] This application claims benefit of priority to United States Provisional Patent Application Serial Number 60/976,371 filed 28 September 2007, which is incorporated herein by reference.

BACKGROUND

[0002] Presence is currently limited to a user's contactable status. For example, a first user's status and availability is provided by presence servers in a network environment. A second user needing to contact the first user may thereby determine the optimal way (and likelihood of success) in contacting the second user. A presence server may determine this status by detecting events made by the first user. For example, if the first user is typing on a keyboard of a computer, these key input events indicate that the first user is sitting at, and using, the computer. The presence server thus displays the status of the first user as 'using the computer'. Using this presence information, the second user may decide to send an instant message to the first user's computer to initiate communication. Alternatively, the second user may decide to call a telephone located near the first user's computer, knowing that the first user will probably answer. [0003] Thus, presence is a useful tool for making informed decisions about other users. However, this presence information is limited to locating and communicating with its users.

[0004] Social networking applications, such as MySpace, Facebook, Skype, allow users to interactively define their presence in greater detail, thereby allowing other permitted users to view this additional presence information.

However, the burden of updating the presence information interactively typically results in infrequent updates and therefore often old (and often incorrect) presence information. SUMMARY

10005] A method foi injecting sensed piesence into social netwoiking applications includes iecemng sensoi data associated with a usei, inlemng a piesence status of the user based upon analysis of the sensor data, stoimg the sensoi data and piesence status within a database, and sending the presence status to a social networking server to update the user^'s piesence information for the social networking applications based upon the user's preferences

[0006] A software product includes instructions, stored on computer- readable media, where the instructions, when executed by a computer, peiform steps for injecting sensed piesence into social networking applications The instructions include instructions for receiving sensor data associated with a usei, instructions foi inferring a presence status of the user based upon analysis of the sensor data, instructions for storing the sensor data and presence status within a database, and instructions foi sending the presence status to a social netwoiking seiver to update the user's piesence information foi the social networking applications based upon the user's preferences

[0007] A system foi injecting sensed piesence into social netwoiking applications includes at least one sensoi pioximate to a user, the at least one sensor being used foi collecting sensoi data associated with the usei, a piesence seiver foi receiving and storing the sensor data, an inference engine for analyzing the stored data and to infer a presence status for the user, and a presentation engine for presenting the information to the user and othei users

BRIEF DESCRIPTION OF THE FIGURES

[0008] FIG 1 shows a system for injecting sensed presence into social networking applications, according to an embodiment

[0009] FIG 2 shows the presence server of FIG 1 interacting with applications, a cell phone, a PDA, embedded sensors, and a notebook computer

[0010] FIG 3 is a flowchart illustrating one exemplary method for injecting sensed presence into social networking applications [0011] FIG 4 shows an example of a snapshot of a user's data page as accessed from a portal of the system of FIG 1 DETAILED DESCRIPTION OF THE EMBODIMENTS [0012 J To make a piesence system useful foi a social netw oik additional sensoi input and activity determination is used That is piesence outside a woik envnonment is detected to piovide a usei s status that is useful in the social environment Once the usei^'s status is determined, it may be shared with other useis, as permitted by the user

[0013] FIG 1 shows a system 100 for injecting sensed presence into social netwoiking applications A user 102 has, for example, a cell phone 106, a personal digital assistant (PDA) 108 and an embedded sensor unit 110 Cell phone 106 may include a camera for sensing images around user 102 and a global positioning sensor (GPS) unit for determining the location of user 102 PDA 108 may include a temperature sensoi foi sensing temperature near user 102 Embedded sensors 110 may include one or more accelerometeis for determining activity of user 102 Embedded sensors 110 may include a tiansceiver to enable wireless communication with cell phone 106, PDA 108 and/or network 120 Embedded sensors 1 10 may be attached to a usei^'s body (e g , a usei's running shoes) as illustrated m FIG 1 Howevei, embedded sensors may also be used in othei manners, such as earned by anothei user, attached to personal pioperty (e g , a usei 's bicycle, car, ski boot), or embedded in the ecosystem of a city oi town (e g , a carbon dioxide sensor oi a pollen sensor attached to a structure in a city) Network 120 may include the Internet and other wired and/or wireless networks

[0014] A second user 104 is shown with a notebook computer 112 that may include one or moie sensors that collect information of user 104 Such sensors are becoming common amongst items carried by people during everyday activities These sensors are periodically interrogated and resulting sensor data sent to a presence server 116 via network 120 Presence server 116 analyzes this sensor data to infer activity of users 102 and 104 Foi example, sensor data received from sensors associated with user 102 is used to define a presence status 122 of user 102 Similarly, sensor data from sensors associated with user 104 is used to define a presence status 124 of user 104

[0015] Through analysis of histoπcal server data, presence server 116 may determine behavioral patterns based on movements of users 102 and 104. For example piesence sen ei 1 16 ma) infei that usei 102 and usei 104 iiequent the same coffee shop by deteimining that usei 102 and usei 104 \ isit the coffee shop each morning w hen tiavelmg to then lespective places of w ot k

[0016] Diffeient sensois may be used to collect data associated with a usei, such as one oi more of the following cameias, microphones, acceleiometers, GPS locators, iadio sensors (e g , Bluetooth device contact logs, 802 15 4 langmg, 802 1 1 localization), temperature sensors, light sensors, humidity sensois, magnetometeis, button click sensors and device status sensors (e g , cell phone rmger status sensors) As noted above, such sensors may be included within devices carried by a user

[0017] In another example, wireless sensors external to cell phone 106 may relay information to cell phone 106, which then sends the information to pi esence server 1 16 foi processing For example, embedded sensor unit 110 may include one or more sensor types that periodically provide sensor data to cell phone 106 via a wneless communication link 1 1 1, such as Bluetooth

[0018] Where sensoi operation is resouice taxing, sensoi opeiation may be done on demand via an explicit query from piesence seivei 1 16 Sensoi data is pushed fiom consumei devices 106, 108, 110 and 112 to presence seiver 116 wheie it is analyzed to infei activity of the associated usei [0019] Another type of sensor that may be used in system 100 is a software sensor that measure artifacts of other software running on a computing platform to determine a user's behavior, mood, etc Since no actual sensor is being read, these software sensors may also be termed virtual sensors Where processing allows, inference may occur within the computing device (e g , cell phone 106, PDA 108, notebook computei 1 12), otherwise data is sent to presence seiver 1 16 foi inference

[0020] In another example, a sensor may not be immediately associated with a user, but may be indirectly associated to the user by locality For example, to determine air quality associated with user 102, sensor information from a statically deployed sensor infrastructure 114 that measures air quality may be used if that data is obtained from one or more sensors of the infrastructure that are near to the location of user 102 Such sensor infrastructures may operate independently of user 102 and presence server 1 16. but may be matched to user 102 through time and location information of user 102. In another example, where users 102 and 104 are near one another and user 104 has one or more different sensor types to those of user 102, while users 102 and 104 are proximate, sensor data from user 104 may be applicable to user 102 and vice versa. Thus, sensors may be shared.

[0021] As more and mode consumer devices include sensors, these device may be used to unobtrusively collect information about a user. By collecting information related to a user, presence server 1 16 (via data fusion and analysis) may determine characteristics and life patterns (e.g., presence status 122, 124) of the user and/or of particular groups of users. These characteristics and life patterns may be fed back to the users in the form of application services 1 18, such as on a display of a consumer device (e.g., cell phone 106). These characteristics (e.g., presence status 122, 124) may also be sent to a social networking server 126 that supports one or more social network applications 1 19, such as Facebook and MySpace, and instant messaging. For example, user 102 may also have an account with a social networking application such as Facebook, and therefore configures presence server 1 16 to send presence information of user 102 to social networking server 126 for use by social networking application 1 19, thereby alleviating the need for user 102 to continually update presence information within that social networking application. That is, presence information for one or more associated social networking applications may be updated with presence information (e.g., presence status 122, 124) for the associated user (e.g., user 102) by presence server 1 16. Thus, as user 104 accesses social networking application 119, shared presence status of user 102 is automatically updated by presence server 1 16 via social networking server 126. [0022] Presence server 1 16 may consist of a set of servers that: (1) hold a database of users and their associated presences 122, 124; (2) implement a web portal that provides access to presence information via per-user accounts; and (3) contain algorithms to draw inferences about many objective and subjective aspects of users based upon received and stored sensor data. Presence server 116 may include one or more interfaces (e.g., using one or more application programming interfaces (APIs)) to clients (e.g., thin clients) running on consumer computing and communication devices, such as cell phone 106, PDA 108, and notebook computer 112. The clients may send \ ia push opeiation information about the usei to piesence sen ei 1 16 and iecen e hom piesence seix ei 1 16 mfeπed infoimation about the usei and the usei s life patterns based on sensed data Data sensing clients may make use of sensoi shaπng and calibiation functions to impiove the quality of data gatheied foi each user, thereby enhancing the peiformance of piesence seiver 1 16

|0023] While processed user information is available (both for individual leview and group shaπng) via the web portal, APIs for the retrieval and presentation of (a subset of) this information are available, through one or more plug-ins (i e , a pull operation) to popular social netwoik applications such as Skype, Pidgin, Facebook, and MySpace

[0024] FIG 2 shows (in an embodiment) presence servei 1 16 of FIG 1 interacting with applications 1 18, cell phone 106, PDA 108, embedded sensors 1 10 and notebook computei 1 12 , collectively called consumer devices 220, in furthei detail Piesence servei 1 16 is shown with storage 210, an inference engine 212 and a presentation engine 214 Storage 210 is used to store received sensoi data and user's piesence status 122, 124 Applications 1 18 may include instant messaging 202, social netwoiks 204, multimedia 206, and blogosphere 208

[0025] Infeience engine 212 analyzes leceived sensoi data and determines piesence information (e g , 122 and 124) foi each user This presence information is, for example, piesented to designated applications running on one oi more user devices (e g , phone 106, PDA 108 and notebook computer 112) A usei ^'s presence information may be pushed to certain devices based upon the user's permission That is, m certain embodiments, the user must allow others to view their presence information for the information to be made available to, and/oi pushed to, other useis [0026] Certain embodiments of system 100 support opportune peei-to- peer communication between consumer devices using available short range radio technologies, such as Bluetooth and IEEE 802 15 4 Communication between consumei devices and presence server 116 takes place accoidmg to the availability of the 802 11 and cellular data channels, which can be impacted both by the device feature set and by radio coverage For devices that support multiple communication modes, communication can be attempted first using a TCP/IP connection over open 802 1 1 channels second using GPRS EDGE-enabled bulk oi stieam tiansfei and finally SMS/MMS is used as a tailback, in ceitain embodiments of system 100

A. Sensing

[0027] Illustiatively, a sensing client (e g , thin sensing client) is installed on a consumer device (e g , cell phone 106, PDA 108, and computei 1 12) to peπodically poll on-boaid sensors (both haidware and software) and to push the collected sensor data, via an available network connection (wired oi wireless, e g , 107, 109, 1 13), to presence seiver 1 16 for analysis and storage For sensing modalities that aie particularly iesomce taxing (especially foi mobile devices), sensor sampling may be done on demand via an explicit query from presence servei 116 Sampling rates and durations for each of the sensors aie set in accordance with the needs of inference engine 212 Typically, the sensing clients use low rate sampling to save eneigy and switch to a higher sampling rate upon detection of an interesting event (i e , set of circumstances) thereby impioving sampling resolution foi penods of inteiest while preserving powei ioi penods of less interest Given the pπcmg schemes of MMS/SMS and the battery dram implied by 802 1 1 oi cellulai iadio usage, data may be compressed befoie sending to piesence server 1 16, using standaid generic compiession techniques on iaw data and/oi domain-specific iun-length encoding (e g , for a stand/walk/run classifier, only send updates to piesence servei 1 16 when the state changes) to reduce communication cost and powei usage When using SMS, the maximum message size may be used to minimize the price per bit Furthermore, preliminary data analysis (e g , filtering, inference) may be migrated to consumer devices 220 Given the computational power of many new cellular phones, significant processing may be done on these mobile devices to reduce communication costs However, aggregate (trans-users) analysis may be done withm presence server 116

1) Hardware Sensors:

[0028] Cell phone 106 may represent one or more of a Nokia 5500 Sport, N80, N800 and N95 cell phones PDA 108 may represent one or more of a Nokia N800 Cell phone 106 and PDA 108 may be combined as in a phone/PDA hybrids such as an Apple iPhone Embedded sensors 110 may represent one or more of a Nike+ system, a recreational sensor platform such as a Garmin Edge, a SkiScape. and a BikeNet.

[0029] The SkiScape platform is. for example, used at a ski area to sense information on skiers and/or the ski area environment. Sensing devices may be attached to skiers, and fixed nodes communicate with the skiers^" sensing devices. The fixed nodes may also capture data such as images, sound, and radar information including snow depth. Additional information on SkiScape may be found in the following paper which is incorporated herein by reference: Eisenman et al., SkiScape Sensing (Poster Abstract), in Proc. of Fourth ACM Conf. on Embedded Network Sensor Systems, (SenSys 2006), Boulder, Nov. 2006.

[0030] The BikeNet system includes a mobile networked sensing system for bicycles. Sensors collect cyclist and environmental data along a cycling route. Application tasking and sensed data uploading occur when sensors come within radio range of a static sensor access point or via a mobile sensor access point along the cycling route. Additional information on BikeNet may be found in the following paper which is incorporated herein by reference: Eisenman et al., The BikeNet Mobile Sensing System for Cyclist Experience Mapping, in Proc. of Fifth ACM Conf. on Embedded Networked Sensor Systems, (SenSys 2007) Sydney, Australia, Nov. 2007. [0031] Another example of embedded sensor 1 10 is a BlueTooth enabled 3D accelerometer, sometimes referred to as a BlueCel. The BlueCel may be attached to a user or to another entity, such as a bicycle. Notebook computer 1 12 may represent one or more of Toshiba and Hewlett Packard laptop and/or desktop computers. Through a survey of the commonly available commercial hardware, including the examples listed above, the following hardware sensors are currently available on one or more commercial-of-the-shelf (COTS) devices: embedded cameras, laptop/desktop web cameras, microphone, accelerometer, GPS, radio (e.g., Bluetooth device contact logs, 802.15.4 ranging, 802.1 1 localization), temperature sensors, light sensors, humidity sensors, magnetometers, button click sensors, and device state sensors (e.g., ringer off detectors). System 100 may exploit the availability of these sensors. 2) Virtual Software Sensors:

|0032] Software sensors are for example those that measure artifacts of other software that runs on the computing platform in an effort to understand the context of the user's behavior, mood, etc. They are ^"'virtual ^' in that they do not sense physical phenomena, but rather sense electronic evidence (''breadcrumbs^") left as the user goes about his daily routine. Examples of virtual software sensors include the following: a trace of recent/current URLs loaded by the web browser; a trace of recent songs played on the music player to infer mood or activity; and mobile phone call log mining for structure beyond what a cell phone bill commonly provides. [0033] As an example of how hardware and software sensor samples are combined to infer activity or status, if recent web searches show access to a movie review site (e.g., moviefone.com), and if a call was recently made to a particular friend, and if the time of day and the day of week is consistent with movie theatre times, and if the cell phone ringer is turned off, it is highly probably that the user is at a movie theatre.

B. Sensor Calibration

[0034] Sensor calibration is a fundamental problem in all types of sensor networks. Without proper calibration, sensor-enabled mobile devices (e.g., cell phones, PDAs and embedded sensor platforms, etc.) produce data that may not be useful or may even be misleading. There are many possible sources of error introduced into sensed data, including those caused by the device hardware itself. This hardware error can be broken down into error caused by irregularities of the physical sensor itself due to its manufacturing, sensor drift (sensors characteristics change because of age or damage), and errors resulting from integration of the physical sensor with the consumer device (e.g., cell phone 106). Physical sensor irregularities are compensated for at the factory, where a set of known stimuli is applied to the sensor to produce a map of the sensor output. To correct the device integration error, post-factory calibration of the sensor-enabled mobile device is required. [0035] One example of a calibration protocol that may be used in system

100 is CaliBree. CaliBree is a distributed, scalable, and lightweight protocol that may be used to automatically calibiate mobile sensoi de\ ices It is assumed that in mobile people-centπc sensoi netwoiks, theie will be tw o classes ot sensois w ith iespect to calibiation calibiated nodes that aie eithei static 01 mobile, and un-calibiated mobile nodes In the following discussion, the nodes belonging to the foimei class aie ieferred to as giound truth nodes These ground tiuth nodes may exist as a iesult of factory calibration, 01 end usei manual calibration In CaIiBi ee, un-calibrated nodes opportunistically interact with calibrated nodes to solve a discrete aveiage consensus problem, level aging cooperative control over their sensoi readings The average consensus algorithm measures the disagreement of sensoi samples between the un- calibrated node and a series of calibiated neighbors The algoiithm eventually converges to a consensus among the nodes and leads to the discovery of the actual disagreement between the un-calibrated node sensor and calibrated nodes sensors The disagreement is used by the un-calibrated node to generate (using a best fit line algorithm) the calibration curve of the newly calibrated sensor The calibration cmve is then used to locally adjust the newly calibrated nodes sensoi readings

|0036] In order foi the consensus algorithm to succeed, the un-calibiated sensoi deuces compare data when sensing the same envπonment as the giound truth nodes Given the limited amount of time mobile nodes may expeπence the same sensing enviionment during a particulai lendezvous, and the fact that even close proximity does not guarantee that the un-cahbrated sensor and the ground tiuth sensor expeπence the same environment, the consensus algorithm is run over time when un- cahbrated nodes encounter different ground truth nodes Additional information on CaliBree may be found in the following technical report which is incorporated herein by reference E Miluzzo et al , Cahbree — A Self Calibration Experimental System foi Wireless Sensor Networks in 5067/2008 Lecture Notes in Computer Science 314 (Springer Beilm/Heidelberg, 2008)

C. Sensor Sharing

[0037] In system 100, mobile sensing devices (e g , cell phone 106, PDA 108, embedded sensors 110) locally manage sensing requests both on behalf of the sensing clients (e g , thin sensing clients) running on the mobile device and/or services running remotely on presence server 116 These sensing requests may be multidimensional w ith each lequested sensoi sample eompπsing a pnmai y sensoi type and a metadata 01 context \ ectoi Context is the set of cπcumstances 01 conditions that suπound a paiticulai sensoi sample This context \ cctoi included in a lequest may indicate a location 01 time at which a sample is to be taken and may include moie sophisticated context tags such as sensor oiientation (e g , facing north, mounted on hip) and mfened custodian activity (e g , walking, running, sitting) This context may also include weights that indicate the lelative importance of one or more context elements

[0038] Whethei a given lequest is injected into the system locally by a sensing client running on a mobile sensoi node, oi by piesence seivei 116, difficulties may arise in tasking an appropnate mobile sensor node with that given request Considered strictly, a mobile sensor node is only appropriate to handle a given lequest if it is equipped with the proper sensor, and if it has a context vector that matches that of the request Stiict handling of a lequest may lead to excessive delay and/or a loss of data fidelity m successfully sei vicing the lequest due to thiee connected issues the uncontiolled mobility of mobile sensing device useis, the location (oi effective leach) of the lequest injection point with respect to the sensing taiget location and the mismatch between the equipped sensoi s and context of available mobile sensor nodes and the sensors and context lequned by a lequest Sensoi shaiing addresses this last difficulty

[0039] Withm system 100, not every consumer device 220 is equipped with every sensor type Node heteiogeneity arises due to a number of reasons, including cost (some sensors are more expensive, or rai e), interest (some sensors are of more importance in different interest groups, or to individual users), and hardware evolution (hardware evolves and many platform generations will be in use simultaneously, e g , many newer mobile phone models are equipped with a camera and/or accelerometer but many older/cheapei models aie not) Due to this heterogeneity, mismatches between the sensors required by sensing client requests and the sensors with which a given mobile node is equipped are likely to arise [0040] Sensor equipment and context constraints that a mobile sensing device must meet to be tasked for a given application request are loosened by allowing sensor sharing between mobile devices (e g , a buddy's device) At a high le\ el ln-situ sensoi shaiing is a function that allows an undei -qualified node to boiiov_* sensoi data fiom a qualified node in an effort to satisfy a sensing lequest while maintaining 01 impio\ ing on the data fidelity, and in a moie timely mannei

[0041 J In an example scenaπo, a student w alks fiom his dorm to school to attend a mid-day class The student carries a mobile phone equipped with a suite of simple sensors (e g , accelerometei, temperature, miciophone, camera), a GPS (e g , Nokia N95), and a low power iadio such as Bluetooth oi IEEE 802 15 4, m his pocket As he leaves the dorm building, his phone is queried via the cellular data channel to measure outdooi light intensity based upon a request made by the student's mother accessing a portal page of system 100 Recognizing that the phone is in the pocket using data mferencmg, as the student walks along the sensoi shaπng service on the phone periodically bioadcasts to discovei a node that is out of the pocket (e g , a hand-held or hip-mounted device) that can answei the light sensing lequest If such a node responds and shares its light sensoi leading, the outdoor light intensity query may be answei ed Further along, the student receives an Ozone Alert text message on his phone Curious about the ozone level m his vicinity, he launches an applet on his phone that is piogiammcd to lequest this information fiom piesence sen ei 1 16 Howevei, since the phone is not equipped with an ozone sensoi, a lequest foi the local ozone information is bioadcast by the sensor sharing service A bus mounted platform (e g , UMass DieselNet) with an attached ozone sensoi replies, shaπng the ozone ieadmg which is displayed locally on the cell phone scieen

[0042] The sensor shaπng primitive comprises a distributed sharing decision algorithm running on the mobile user devices (e g , cell phone), resource and context discovery protocols, in-situ sensor sharing piotocols and algorithms that adapt according to the iadio and sensed environment, and a context analysis engine that provides the basis for shaπng decision making

D. Analysis

[0043] Sensed data is sent from device clients in consumer devices 220 to presence server 116 and is processed by one or more analysis component (e g , inference engine 212) resident withm presence server 116 This analysis component may combine histoπcal per-user information with inferences derived from combinations of current data derived from multiple sensors to determine the presence status of the user. This presence status may include objective items such as location and activity, and subjective items such as mood and preference. While a number of data fusion, aggregation, and data processing methods are possible, the following are examples of analysis/inference outputs that are used to generate the sensed presence within system 100.

[0044] Location is a key function in any sensing system for providing geographical context to raw sensor readings. When explicit localization services like GPS are not available, due to hardware limitation or issues with satellite coverage, location of the client devices may be inferred from observed WiFi (e.g., access point identifiers), Skyhook service, Bluetooth (e.g., identifying location from static devices) cellular base station neighborhoods, and/or other unique sets of sensed data in a manner similar to ambient beacon localization. Ambient beacon localization may be used to determine a sensor^'s location by use of supervised learning algorithms that allow the sensor to recognize physical locations that are sufficiently distinguishable in terms of sensed data from the other sensors in a field. Additional information on ambient beacon localization may be found in the following paper which is incorporate herein by reference: Nicholas D. Lane et al., Ambient Beacon Localization: Using Sensed Characteristics of the Physical World to Localize Mobile Sensors, in 2007 Proceedings of the 4^th Workshop on Embedded Networked Sensors 38 (2007). [0045] Human activity-inferring algorithms are incorporated within inference engine 212 to log and predict a users' behavior. A simple classifier to determine whether a user is stationary or mobile may be built from several different data inputs, alone or in combination (e.g., changes in location by any possible means, accelerometer data). Accelerometer data may be analyzed to identify a number of physical activities, including sitting, standing, using a mobile phone, walking, running, stair climbing, and others.

[0046] Human behavior is often a product of the environment. To better understand a user's behavior, it is useful to quantify the user's environment. Image and sound data may be collected and analyzed to derive the noisiness/brightness of the environment. Conversation detection and voice detection algorithms may be used to identify the people in a user^'s vicinity that may impact behavior and mood of the user.

[0047] Part of a person s daily experience is the environment where the person lives and spends most of the time. For example, health related issues of interest may include the level of an individual^'s exposure to particulates (e.g., pollen) and pollution. By incorporating mechanisms that enable air quality monitoring around the individual through opportunistic interaction with mobile sensors and/or static pre-deployed infrastructure (e.g., sensors 1 14), these health related issues of interest may be predicted and possible prevented.

E. Presentation

[0048] Since communication devices, and in particular mobile communication devices, provide varying amounts of application support (e.g., web browser, Skype, and Rhythmbox on a laptop; web browser and Skype on the N800, SMS only on the Motorola L2), a presentation engine 214 provides a variety of means for sending the human sensing presence (e.g., presence status 122, 124), distilled from the sensed data by presence server 1 16, for display on the end user device (e.g., consumer devices 220).

1) Text only: Email/SMS

[0049] More limited platforms, such as older/low-end cell phones and PDAs, likely do not have the capability to browse the Internet and have a limited application suite. These platforms may still participate as information consumers in the architecture of system 100 by receiving text-based updates from SMS/email generator 216, rather than graphical indicators of status embedded in other applications.

2) Browser: Web Portal

[0050] Platforms that support at least general Internet browsing allow users to access web portal 218, the content of which is served from storage 210. In certain embodiments, the particular visualizations generated by web portal 218 may be customized to a degree in a manner similar to Google Gadget development/configuration on personalized iGoogle pages. Web portal 218 thus may pio\ ide a flexible and complete piesentation of a usei s collected data (e g . a data log) and data shai ed by othei usei s (e g Ma a buddy list) In ceitam embodiments, the usei may also configui e all aspects of the associated account including finegrained shaπng piefeiences foi the usef s "buddies^" , thiough web portal 218

3) Application-specific Plug-ins

[0051] Depending on the application support on the usef s device, one oi moie of the following exemplary plug-ms may be used In certain embodiments, in addition to status information rendeied by the plug-in in the applications' GUI, the plug-in piovides click-through access to the web portal 218 - both to the user's pages and the shared section of any buddy's pages

• Instant messaging client buddy list shows an icon with a particulai status item for the buddy

• Facebook and MySpace pages have plug-ins to show your status and that of youi friends • iGoogle gadgets show various status items from a device user and his buddies The iGoogle page periodically iefreshes itself, so it follows the data pull model fiom piesence servei 1 16

Photography applications have plug-ms to allow pictuies to be stamped with metadata like location (minimally) and other environmental (light, temperature) and human status elements

F. Privacy Protection

[0052] The privacy of users registered with system 100 may be protected through a number of mechanisms Users' raw sensor feeds and inferred information (collectively considered as the user's sensed presence) may be securely stored within storage 210 of presence server 1 16, but may be shared by the owning usei according to group membership policies For example, the iecorded sensoi data and piesence is available only to users that are alieady part of the user^'s buddy list In certain embodiments, Buddies are determined from the combination of buddy lists imported by registered services (Pidgm, Facebook, etc ), and buddies may be added based on profile matching Thus, certain embodiments of system 100 inherit and leverage the Vi oik ahead} undei taken by a usei when ci eating his buddy lists and sub-lists (e g in Pidgin Skype, Facebook) in defining access policies to the usei s piesence data

[0053] In ceitam embodiments, useis may decide whethei to be visible to othei usei s using a buddy seaich seivice 01 via a buddy beacon sen ice In certain embodiments, useis aie also given the ability to furthei apply per-buddy policies to determine the level of data disclosuie on pei-usei, pei-gioup, oi global level Ceitam embodiments of system 100 follow the Virtual Walls model which provides different levels of disclosure based on context, enabling access to the complete sensed/inferred data set, a subset of it, or no access at all Foi example, user 102 might allow user 104 to take pictuies fiom cell phone 106 while denying camera access to other buddies, usei 102 might make the location trace of user 102 available to user 104 and to other buddies The disclosure policies are foi example set from the user's account configuration page withm web portal 218

[0054] In addition to user-specific data shaπng policies, certain embodiments oi system 100 compute and shaie aggiegate statistics across the global user population Foi this service, shared information is for example made anonymous and a\ eiaged, and access to the information is fuithei conti oiled by a quid pro quo requnement

Services [0055] Certain embodiments of system 100 help support the following goals (i) provide information to individuals about then life patterns, and (ii) piovide more texture to interpersonal communication (both direct and mdnect) using information derived from hardware and software sensors on usei devices A number of services, built upon the architecture of system 100, that aim to meet these goals are described below

A. Life Patterns

[0056] Enriching the concept put forward in the MyLifeBits pioject, certain embodiments of system 100 automatically sense and store location traces, inferred activity history, history of sensed environment (e g , sound and light levels), rendezvous with friends and enemies, web search history, phone call history, and/or VOIP and text messaging history In this way, system 100 may provide context m the foim of sensed data to the myπad othei digital observations being collected Such information may be of archi\ al inteiest to the user as a curiosity, and may also be used to help undei stand behavioi. mood, and health

B. My Presence (0057] As indicated by the increasing popularity of social networking sites like Facebook and MySpace, people (especially youth) are interested both m actively updating aspects of their own status (i.e., personal sensing presence), and surfing the online profiles of their friends and acquaintances for status updates However, it is troublesome to have each user manually update more than one or two aspects of his or her sensed presence on a regular basis

[0058] Certam embodiments of System 100 add texture and ease of use to online electronic avatars (e.g., the avatars of Facebook and MySpace) by automatically updating each user's social networking profile with mfeπed and current information (e g., "on the phone^"', "'drinking coffee'^", "jogging at the gym", '"at the movies'^") that is gleaned from hardware and software sensors by presence server 1 16

C. Friends Feeds

[0059] In the same way people subsciibe to news feeds or blog updates, and given the regularity with which users of social netwoikmg sites biowse their friends' profiles, there is clearly a need for a profile subscription service similar to really simple syndication (RSS) (Facebook has a similar service for the data and web interface it maintains) Under this model, buddies' status updates might be event dπven; a user asks to be informed of a particular buddy's state (e.g , walking, bikmg, lonely, with people at the coffee shop) at, for example, the user's cell phone

D. Social Interactions [0060] Using voice detection, known device detection (e.g , cell phone

Bluetooth MAC address), and life patterns, group meetings and other events that involve groupings of people may be detected by embodiments of system 100. In social group internetworking, friends are often interested in who is spending time with whom. Such embodiments of System 100 allow individuals to detect when groups of their buddies are meeting (or even when an illicit rendezvous is happening). A further level of analysis may deteimine whethei a com ei sation is ongoing and fuithci gioup dynamics (e g who is the dominant speakei )

E. Significant Places

[0061] Ha\ e you evei found yourself standing in front of a new lestauiant, or wandering in an unlamiliai neighborhood, wanting to know moie⁹ A call to directoiy assistance is one option, but what you really want are the opinions of youi fiiends Phone calls to survey each of them aie too much of a hassle Or alternatively, maybe you just want to analyze your own routine to find out where you spend the most time To satisfy both aims, certain embodiments of system 100 support the identification and sharing of significant places m each usei 's life patterns

[0062] Significant places are derived through a continuously evolving clustering, classification, and labeling appioach In the first step, location traces aie collected from available sources (e g , WiFi association, GPS, etc ) foi the given usei Since location tiaces always have some level of inaccuracy, the sensed locations aie clusteied accoidmg to then geogiaphical pioximity The importance of a clustei is identified by consideiing time-based inputs such as visitation fiequency, dwell time, and iegulaiity Once significant clusters aie identified, a similaiity measuie is applied to determine how "close^" the new clustei is to othei significant clustei s aheady identified (across a user^'s buddies) in the system If the similarity is greater than a threshold, then the system automatically labels (e g , '"Home^"', 'Coffee shop'^", etc ) the new cluster with the best match The user may amend the label, if the automatic label is deemed insufficient Finally, the usei has the option of forcing the system to label places considered "insignificant" by the system (e g , due to not enough visitations yet) [0063] As implied above, embodiments of system 100 keeps the labels and the cluster information ol important clustei s for all users, applying them to subsequent clustei learning stages and offering to users a list of possible labels for given clusters In addition to this "behind the scenes'^* type of place label shaimg, m certain embodiments, users may also explicitly expose their significant places with their buddies or globally to all users, using methods (e g , portal, plug-ins) previously described Accordingly, if a user is visiting a location that is currently not a significant clustei to him based on his ow n location/time tiaces the point can be matched against shaied buddies clustei s

[0064] Once the significant places ot useis ha\e been automatically identified and eithei automatically 01 manually tagged, useis may annotate then significant places The annotation may include for example identifying the cafe that has good coffee oi classifying a neighboihood as one of dangerous safe, hip oi dull

F. Health Monitoring

[0065] As many people are becoming more health-conscious in terms of diet and lifestyle, certain embodiments of system 100 also provide individuals with health aspects of their daily routines Such embodiments of system 100 aie able to estimate exposure to ultraviolet light, sunlight (e g , for Seasonal Affective Disorder (SAD) afflicted users) and noise, along with number of steps taken (distance traveled) and number of calories buined These estimates aie derived by combining mfeience of location and activity of the users with weathei information (e g , UV index, pollen and particulate levels) captuied by piesence server 1 16 fiom the web, foi example

G. Budch Search

10066] The past ten yeais have seen the giowth in popularity of online social networks, including chat groups, weblogs, fnend networks, and dating websites Howevei, one hurdle to using such sites is the requnement that useis manually input their pieferences, characteristics, and the like into the site databases Certain embodiments of system 100 provide the means for automatic collection and sharing of this type of profile information Such embodiments of system 100 automatically learn and allow users to export information about their favorite locations or "'haunts", what recreational activities they enjoy, and what kind of lifestyle they are familiar with, along with near real-time personal presence updates sharable via application (e g , Skype, MySpace) plug-ms and web portal 218 Furthei, as many popular IM clients allow searching for people by name, location, age, etc , certain embodiments of system 100 enable searching of users based upon a data mining process that also involves interests (like preferred listened music, significant places, preferred sport, etc) H. Budd> Beacon

|0067] The buddy seaich sen ice of embodiments of system 100 is adapted to facilitate local intei action as w ell In this mode a usei tonfiguies the buddy seaich seivice to piovide instant notification to his mobile device if a fellow usei has a profile with a certain degiee of matching attπbutes (e g , significant place foi both is "Dirt Cowboy coffee shop^"', both have piimaπly nocturnal life patterns, similar music or sports interests) All this information is automatically mined via system 100 sensing clients running on usei consumer devices 220, the user does not have to manually configure his profile information Devices with this seivice installed peπodically bioadcast the profile aspects the user is willing to advertise - a Buddy Beacon - via an available short range iadio inteiface (e g , Bluetooth, 802 15 4, 802 1 1) When a profile advertisement is leceived that matches, the user is notified via his mobile device

I. "Above Average?" [0068] Theie is much inteiest in statistics Foi example, people may want to know whether they aie popular, how they measuie up, oi whethei they have a compaiatively outgoing peisonahty By analyzing aggregate sensoi data collected by its members, certain embodiments of system 100 piovide such statistical information on items such as the top ten most common places to visit in a neighborhood, the average time spent at work, and many otheis Such embodiments of system 100 make this aggregate information available to useis, each user may configure their web portal page to display this information as desired Comparisons are available both against global averages and gioup aveiages (e g , those of a user's buddies) Tying in with the Life Patterns service, useis may also see how their compaiative behavior attπbutes change over time (i e , with the season, semester, etc ) In certain embodiments of system 100, the normal pnvacy model of system 100 is based on buddy lists, and therefore, each user must manually opt in to this global sharing of information, even though the data is made anonymous through aggregation and averaging before being made available However, m such embodiments, access to the global average information is only made available to users on a quid pro quo basis [0069] FIG. 3 is a flowchart illustrating one exemplary method 300 for injecting sensed presence into social networking applications. In step 302, method 300 receives sensor data associated with a user. In one example of step 302, a client (e.g., a thin client) within cell phone 106 samples sensors within cell phone 106 and sends this sensor data to presence server 1 16. In step 304, method 300 infers presence information of the user based upon the sensor data. In one example of step 304, inference engine 212 analyzes sensor data received from cell phone 106, PDA 108 and/or embedded sensors 1 10 and generates presence status 122. In step 306, method 300 stores sensor data and inferred presence status within a database. In one example of step 306, presence server 1 16 stores sensor data and presence status within storage 210. In step 308, method 300 sends the presence status to a social networking server based upon the user's preferences. In one example of step 308, user 102 defines preferences within presence server 1 16 to send presence status 102 to social networking server 126, thereby automatically updating presence for user 102 within Facebook.

Example of Implementation

[0070] The following is a description of an embodiment of system 100. It should be understood that the following description is provided merely as one example of how system 100 may be implemented. System 100 may be implemented in other manners in accordance with the previous description, and the scope of the invention.

A. Sensing

[0071] In this example, sensing clients are implemented on the following COTS hardware: a Nokia 5500 Sport cell phone (including the Symbian operating system, a 3D accelerometer, and BlueTooth capability); • a Nokia N80 cell phone (including the Symbian operating system,

802.1 lb/g capability, and BlueTooth capability); a Nokia N95 cell phone (including the Symbian operating system, 802.1 lb/g capability, BlueTooth capability, and GPS capability); a Nokia N800 PDA (including the Linux opeiatmg svstem. 802 1 I b g capability, and BlueTooth capability), and

• Linux notebook computei s.

[0072] Each sensing client in this example is configured to periodically push its sensed data to piesence server 1 16. The following is a description of how sensing clients are implemented on the COTS hardware.

• A Perl plugin to Rhythmbox audio player on the Lmux laptop and the Nokia N800 pushes the current song to presence servei 1 16.

• A Python script samples the 3D accelerometer on the Nokia 5500 Sport at a rate that supports accurate activity inference.

The BlueTooth and 802.1 1 neighborhoods (MAC addresses) of the sensing clients are periodically collected using a Python script. In this example of system 100, users have the option to register the BlueTooth and 802.1 1 MAC address of their devices with the system. In this way, presence server 1 16 can convert MAC addresses into human-friendly neighbor lists.

• A Python script captures camera and microphone samples on the Nokia N80 and Nokia N95 platforms Additionally, the EXlF image metadata are captured and analyzed A Perl plugin to Pidgm pushes IM buddy lists and status to presence server 1 16.

A Perl plugin to Facebook pushes Facebook friend lists to presence server 1 16.

• A Python script periodically samples the GPS location on the Nokia N95.

Lmux libraries compiled for the notebook computers and the Nokia N800 periodically sample the WiFi-deπved location using Skyhook and push to the location to presence server 1 16.

[0073] A BlueTooth enabled accelerometer or BlueCel was also used m this example of system 100. The BlueCel extends the capability of BlueTooth enabled devices, and the BlueCel's application is determined by its placement. For example, the BlueCel may be to analyze a user's weight lifting or bicycling activities by placing the BlueCel on a weight stack or bicycle pedal, respectively. The BlueCel is implemented, for example, from a Sparkfun WiTiIt module, a Sparkfun LiPo battery charger, and a LiPo battery.

[0074] In this example of system 100, a Python script reads accelerometer readings from the BlueCel over the BlueTooth interface. A sensing client menu allows the user to tell system 100 what the application is (e.g., weight lifting or bicycling), thereby allowing the client to set the appropriate sampling rate of the BlueCel's accelerometer. The BlueCel' s data is tagged with the application so that presence server 1 16 can properly interpret the data. [0075] Furthermore, in this example of system 100, existing embedded sensing systems accessible via IEEE 802.15.4 radio are levered by integrating the SDIO-compatible Moteiv Tmote Mini into the Nokia N800 device. Such existing embedded sensing systems are examples of embedded sensors 1 10.

B. Analysis [0076] Unprocessed or semi-processed data is pushed by sensing clients running on user devices to presence server 1 16 in this example of system 100. A MySQL database on presence server 1 16 stores and organizes the incoming data, which is accessible via an API instantiated as a collection of PHP, Perl, and Bash scripts. The Waikato Environment for Knowledge Analysis (''WEKA") workbench is used for clustering and classification.

[0077] The following is a description of how some of the services discussed above are implemented in this example of system 100:

[0078] An activity classifier determines whether a user is standing, walking, or running. The activity classifier makes this determination from features in data from either the Nokia 5500 Sport or the BlueCel accelerometer. Examples of such features include peak and RMS frequency and peak and RMS magnitude. The activity classifier operates of a mobile device (i.e., one of the Nokia devices of the notebook computers of this computer) to avoid the cost (energy and monetary) of sending complete raw accelerometer data via SMS to presence server 116. [0079] An indoor/outdoor classifier determines whether a user is indoors or outdoors. The classifier uses a feature vector including a number of elements to make the classilϊei be iobust to diffeient tvpes of indooi and oυtdooi eirwionments Such teatuies include the following the ability of the mobile de\ ice to acquπe a GPS estimate the numbei of satellites seen by GPS, the numbei of WiFi access points and BlueTooth devices seen as well as then signal stiengths, the fiequency of ambient light (looking foi the AC-mduced flicker), and the diffeiential between the ternperatme measured by the device and the temperatme read via a weather information feed (to detect mdooi climate control)

[0080] A mobility classifier determines whether a user is stationary, walking, or driving The mobility classifϊei consideis changes to a iadio neighboi set Additionally, the mobility classifier considers the lelative signal stiengths, both foi individual neighbors and the aggregate across all neighbors, for BlueTooth, WiFi, and GSM radios of the mobile devices The mobility classifier maps changes in the radio environment (i e , neighbors, received signal strength) to speed of movement The iesult of the afoiementioned indoor/outdooi classifiei is also included in the featuie vector Locations traces are omitted due to then lelatively high eπoi with respect to the speed of human motion

[0081 J Using Matlab processing on presence sei vei 1 16 a noise index (expiessed in decibels) is geneiated from audio samples captured fiom the Nokia N80 s and N95 s miciophones Similarly, a bnghtness index (ranging from 0 to 1) is geneiated on piesence servei 116 using Matlab from images captuied from the Nokia N 80 and N95's cameras The sounds and bnghtness indices help presence server 116 infer information about a person's surroundings For example, the noise index is combined ovei time to estimate the cumulative effect of the sound environment on a user's hearing As another example, the brightness index helps determine the positive effect of sunlight (when combined with an mdooi/outdooi classifier) on those afflicted with seasonal affective disorder Additionally, a classifier based on a voice detection algorithm determines whether a user is engaged in conveisation

[0082] A user's significant places are derived by analyzing location traces, mobility time statistics, and other data inputs Raw location data is first clustered using the EM algorithm Clusters are subsequently mapped against time statistics (viz , visitation frequency, dwell time, regulaπty, time of day, weekday/weekend, AM/PM) and other information (viz , indoor/outdoor, current and previous mobility class numbei and composition oi people gioups \ isible in a location) to dctcimmc impoitance Additionally WiFi and Bluetooth MAC addiess of neighbois aic used to dilfeientiate between o\ ei lapping clusteis Fmall\ a similaiit} measuie is computed between the new clustei and existing clusteis known by the system [0083] In this example, system 100 maintains geneiic labels foi significant clusteis Howevei, useis may alias the clusters as well to give moie personally meaningful oi gioup-oπented names The clustering m this example is adaptive in that the model changes over time depending on how the mobility trace of the usei (and othei system users) evolves - that is the significance of a place may evolve ovei time While it is often advantageous to i elate lecogmzed significant clusters to physical locations (i e , coordinates), in this example, system 100 also enables the recognition of significant places for devices that do not have access to absolute localization capabilities by using local region recognition based on what featuies are available to the device, such as WiFi, Bluetooth, and GSM capabilities Accordingly, a location clustei need not be an aggiegated set of tiue coordinate estimates, but can alternately compiise a set of location iecogmtion estimates

|0084] In this example the numbei of caloiies burned aie estimated by combining the infeience of walking fiom the activity classifiei, time spent walking, and an average factor of caloiies burned pei unit time when walking at a moderate pace Fuithei, exposme to ultraviolet light is estimated by combining the mfeience of walking oi running or standing, the inference of being outdoois, the time spent, and a feed to a web-based weathei service to learn a curient UV dose iate A similar technique is applied to estimate pollen exposure (tiee, grass, weed) and particulate exposuie [0085] As discussed above, the BlueCel facilitates many application- specific data collection possibilities Application-specific data analysis tools may be developed foi the BlueCel to support applications including bicycle riding analysis (BlueCel placed on the pedal), golf swing analysis (BlueCel affixed to the club head), weight lifting analysis (e g , to determine exercise motion correctness to avoid injury), and woikout logging (BlueCel affixed to the wrist) C. Presentation

[0086] In this example the usei s piocessed sensoi data can be \ iew ed via a web biowsei by logging into the usei s account on piesence sei\ ei 1 16 Additionally, a subset of the usei s status mfoimation is made a\ailable \ia data push and data pull mechanisms to the user s buddies through then system portal pages, and thiough plugms to social networking applications

[0087] In this example, the data a usei shares with his buddies may be iendered via a number of simple icons that distill the current sensing piesence of the user FIG 4 shows a snapshot 400, which is an example of a user^'s data page on web portal 218 Right pane 402 includes Buddy lists loaded from registeied Pidgin and Facebook accounts, and the Buddy lists aie annotated with icons repiesentmg the shared data The icons offer chck-thiough access to a fuller iepresentation of the shared user data In the example of FlG 4, buddies Patty and Selma are inferred to be standing and in a conversation, while buddy Lenny is inferred to be at the coffee shop, as indicated by the color of the activity icons next the each buddy^'s name

[0088] On login to system 100 m this example, left pane 404 shows the logged-in user's data Additionally, left pane 404 shows a buddy^'s data if an icon next to that buddy's name is clicked In the example of FlG 4, the logged-m usei Homer Simpson has clicked on the icon foi his buddy Patty Patty has a sharing policy that allows the display of the following data as shown in left pane 404 Patty^'s buddies m her vicinity (determined via BlueTooth and WiFi MAC address lecogmtion), Patty^'s trace of her last significant places visited, etc In this example, the link 406 at the bottom of the page to take a picture ("peek") from Patty^'s cell phone is disabled, Patty has disabled access foi Homer Simpson to image data m her privacy profile Instead, Homer has clicked the link 408 to view the sound level history plot 410 for Patty, ostensibly to see how noisy Selma is Icons 412 denote that a buddy imported from the usei^'s Facebook account (using a Facebook developer API) oi Pidgin account (using a Pidgm developer API) is also a registered user of system 100 [0089] Changes may be made m the above methods and systems without departing from the scope hereof It should thus be noted that the matter contained m the above descπption or shown m the accompanying drawings should be interpreted as illustrative and not in a limiting sense. The following claims are intended to co\ er generic and specific features described herein, as well as all statements of the scope of the present method and system, which, as a matter of language, might be said to fall therebetween.

Claims

CL XLMSWhat is claimed is"

1. A method for injecting sensed piesence into social networking applications, comprising. receiving sensor data associated with a user; inferring a presence status of the user based upon analysis of the sensoi data; storing the sensor data and presence status within a database; and sending the presence status to a social networking server to update the user's presence information for the social networking applications based upon the user' s preferences

2. The method of claim 1 , the presence status including one or more of location information, activity information, preference information, and mood information.

3. The method of claim 1 , the sensoi data including one oi more of location information, acceleiometei mfoimation. tempeiatuie information, light intensity information, audio information, and softwaie aitifacts

4. The method of claim 1 , the sensoi data being leceived from one or more sensors located proximate to the user.

5. The method of claim 1 , the sensor data being leceived from one or more shared sensors located proximate to the user

6. The method of claim 1 , the step of inferring comprising inferring the presence status based upon analysis of combined sensor data from a plurality of sensors associated with the user.

7. The method of claim 1 , the presence status including statistical information based upon other users^' sensor data and inferred presence status.

8 The method of claim 1 tmthei compiising mteiactmg w ith the usei \ ia a w eb poital the w eb poital pio\ iding the usei with statistical intoimation based upon othei usei s sensoi data and mteired piesence status

9 The method of claim 8, the statistical information including a iankmg of the user against statistical aveiages

10 The method of claim 1, the step of receiving sensor data compiising wirelessly transmitting sensor data from an embedded sensoi to a consumei device associated with the user

1 1 The method of claim 1 , the sensor data comprising measured artifacts of softwai e running on a computing platform associated with the usei

12 The method of claim 1, the step of inferring being executed on a computei platform associated with the usei

13 The method of claim 1 , the step of infeπing being executed on a piesence sen ei in communication with a computei platfoim associated with the user

14 A software pioduct compπsmg instructions, stoied on computei - ieadable media, wherein the mstiuctions, when executed by a computei, peiform steps for injecting sensed presence into social networking applications, compiising mstiuctions for receiving sensoi data associated with a user, instructions for mfeiimg a presence status of the usei based upon analysis of the sensoi data, instructions foi storing the sensoi data and presence status within a database, and instructions foi sending the presence status to a social networking server to update the usei s presence information for the social netwoiking applications based upon the user's prefeiences

15 A system for injecting sensed presence into social networking applications, comprising at least one sensor proximate to a user, the at least one sensor being used for collecting sensor data associated with the user; a presence server for receiving and storing the sensor data; an inference engine for analyzing the stored data and to infer a presence status for the user; and a presentation engine for presenting the information to the user and other users.

16. The system of claim 15, the presentation engine including a web portal for interacting with one or more users.

17. The system of claim 15, the presentation engine including an email generator for sending email messages to one or more users, the email message containing the presence status.

18. The system of claim 15, the presentation engine including an SMS generator for sending SMS messages to one or more users, the SMS message containing the presence status.

19. The system of claim 15, the presentation engine sending the presence status to one or more social networking applications, the social networking application being configured to automatically update the user's presence within the social networking application.

20. The system of claim 15, the at least one sensor being embedded in a device selected from the group consisting of a cell phone, a personal digital assistant, and a notebook computer.

21. The system of claim 15, the at least one sensor being an embedded sensor that wirelessly communications with a consumer device selected from the group consisting of a cell phone, a personal digital assistant, and a notebook computer.

22. The system of claim 15. the at least one sensor comprising a BlueTooth enabled accelerometer operable to communicate with a BlueTooth enabled consumer device.

23. The system of claim 22, the BlueTooth enabled consumer device being selected from the group consisting of a BlueTooth enabled cell phone, a BlueTooth enabled personal digital assistant, and a BlueTooth enabled notebook computer.

24. The system of claim 15, the system being configured and arranged for the at least one sensor to send sensor data to the presence server upon a query from the presence server.

25. The system of claim 15, the at least one sensor being a virtual sensor that determines the sensor data by measuring artifacts of software running on a computing platform associated with the user.

26. The system of claim 15, the at least one sensor comprising a first and a second sensor, the first sensor being calibrated from the second sensor.

27. The system of claim 15, the at least one sensor comprising a sensor associated with a skier.

28. The system of claim 15, the at least one sensor comprising a sensor associated with a bicyclist.