Patent Application
20130057394
Various implementations relate generally to electronic communication device technology and, more particularly, relate to a method and apparatus for providing context sensing and fusion.
The modern communications era has brought about a tremendous expansion of wireline and wireless networks. Computer networks, television networks, and telephony networks are experiencing an unprecedented technological expansion, fueled by consumer demand. Wireless and mobile networking technologies have addressed related consumer demands, while providing more flexibility and immediacy of information transfer.
Current and future networking technologies continue to facilitate ease of information transfer and convenience to users by expanding the capabilities of mobile electronic devices. One area in which there is a demand to increase ease of information transfer relates to the delivery of services to a user of a mobile terminal. The services may be in the form of a particular media or communication application desired by the user, such as a music player, a game player, an electronic book, short messages, email, content sharing, web browsing, etc. The services may also be in the form of interactive applications in which the user may respond to a network device in order to perform a task or achieve a goal. Alternatively, the network device may respond to commands or requests made by the user (e.g., content searching, mapping or routing services, etc.). The services may be provided from a network server or other network device, or even from the mobile terminal such as, for example, a mobile telephone, a mobile navigation system, a mobile computer, a mobile television, a mobile gaming system, etc.
The ability to provide various services to users of mobile terminals can often be enhanced by tailoring services to particular situations or locations of the mobile terminals. Accordingly, various sensors have been incorporated into mobile terminals. Each sensor typically gathers information relating to a particular aspect of the context of a mobile terminal such as location, speed, orientation, and/or the like. The information from a plurality of sensors can then be used to determine device context, which may impact the services provided to the user.
Despite the utility of adding sensors to mobile terminals, some drawbacks may occur. For example, fusing data from all the sensors may be a drain on the resources of the mobile terminal. Accordingly, it may be desirable to improve sensor integration.
A method, apparatus and computer program product are therefore provided to enable the provision of context sensing and fusion. Accordingly, for example, sensor data may be fused together in a more efficient manner. In some examples, sensor integration may further include the fusion of both physical and virtual sensor data. Moreover, in some embodiments, the fusion may be accomplished at the operating system level. In an example embodiment, the fusion may be accomplished via a coprocessor that is dedicated to pre-processing fusion of physical sensor data so that the pre-processed physical sensor data may then be fused with virtual sensor data more efficiently.
In one example embodiment, a method of providing context sensing and fusion is provided. The method may include receiving physical sensor data extracted from one or more physical sensors, receiving virtual sensor data extracted from one or more virtual sensors, and performing context fusion of the physical sensor data and the virtual sensor data at an operating system level.
In another example embodiment, a computer program product for providing context sensing and fusion is provided. The computer program product includes at least one computer-readable storage medium having computer-executable program code instructions stored therein. The computer-executable program code instructions may include program code instructions for receiving physical sensor data extracted from one or more physical sensors, receiving virtual sensor data extracted from one or more virtual sensors, and performing context fusion of the physical sensor data and the virtual sensor data at an operating system level.
In another example embodiment, an apparatus for providing context sensing and fusion is provided. The apparatus may include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the apparatus to perform at least receiving physical sensor data extracted from one or more physical sensors, receiving virtual sensor data extracted from one or more virtual sensors, and performing context fusion of the physical sensor data and the virtual sensor data at an operating system level.
Having thus described various embodiments in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:
Some embodiments will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments are shown. Indeed, various embodiments may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like reference numerals refer to like elements throughout. As used herein, the terms “data,” “content,” “information” and similar terms may be used interchangeably to refer to data capable of being transmitted, received and/or stored in accordance with embodiments. Thus, use of any such terms should not be taken to limit the spirit and scope of various embodiments.
Additionally, as used herein, the term ‘circuitry’ refers to (a) hardware-only circuit implementations (e.g., implementations in analog circuitry and/or digital circuitry); (b) combinations of circuits and computer program product(s) comprising software and/or firmware instructions stored on one or more computer readable memories that work together to cause an apparatus to perform one or more functions described herein; and (c) circuits, such as, for example, a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation even if the software or firmware is not physically present. This definition of ‘circuitry’ applies to all uses of this term herein, including in any claims. As a further example, as used herein, the term ‘circuitry’ also includes an implementation comprising one or more processors and/or portion(s) thereof and accompanying software and/or firmware. As another example, the term ‘circuitry’ as used herein also includes, for example, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, other network device, and/or other computing device.
As defined herein a “computer-readable storage medium,” which refers to a non-transitory, physical storage medium (e.g., volatile or non-volatile memory device), can be differentiated from a “computer-readable transmission medium,” which refers to an electromagnetic signal.
Some embodiments may be used to perform sensor integration more efficiently. Since conventional onboard sensors of hand-held devices (e.g., mobile terminals) are typically interfaced to the main processor of the devices via I2C/SPI (inter-integrated circuit/serial peripheral interface) interfaces, pre-processing of raw data and detection of events from the sensors is typically performed in the software driver layer. Thus, for example, data fusion for physical sensors may typically occur at low level drivers in the operating system base layer using the main processor. Accordingly, pre-processing and event detection is typically performed at the expense of the main processor. However, embodiments may provide a mechanism by which to improve sensor fusion. For example, embodiments may enable context fusion at the operating system level using both physical and virtual sensor data. Moreover, in some cases, a sensor co-processor may be employed to fuse physical sensor data. Some embodiments also provide for a mechanism by which to perform context sensing in a distributed fashion. In this regard, for example, context information may be determined (or sensed) based on inputs from physical and virtual sensors. After extraction of sensor data (which may define or imply context information) from the physical and/or virtual sensors, fusion may be accomplished on a homogeneous (for example, fusion contexts derived from physical sensors and operating system virtual sensors and the output is a fused context) or heterogeneous (for example, inputs are a combination of context information from lower layers and virtual sensor data). As such, the data that is fused at any particular operating system layer according to example embodiments could be either sensor data (physical and/or virtual) being fused with other sensor data, or sensor data being fused with context information from lower layers (which may itself include sensor data fused with other sensor data and/or context information from lower layers).
The mobile terminal 10 may include an antenna 12 (or multiple antennas) in operable communication with a transmitter 14 and a receiver 16. The mobile terminal 10 may further include an apparatus, such as a controller 20 or other processing device, which provides signals to and receives signals from the transmitter 14 and receiver 16, respectively. The signals include signaling information in accordance with the air interface standard of the applicable cellular system, and also user speech, received data and/or user generated data. In this regard, the mobile terminal 10 is capable of operating with one or more air interface standards, communication protocols, modulation types, and access types. By way of illustration, the mobile terminal 10 is capable of operating in accordance with any of a number of first, second, third and/or fourth-generation communication protocols or the like. For example, the mobile terminal 10 may be capable of operating in accordance with second-generation (2G) wireless communication protocols IS-136 (time division multiple access (TDMA)), GSM (global system for mobile communication), and IS-95 (code division multiple access (CDMA)), or with third-generation (3G) wireless communication protocols, such as Universal Mobile Telecommunications System (UMTS), CDMA2000, wideband CDMA (WCDMA) and time division-synchronous CDMA (TD-SCDMA), with 3.9G wireless communication protocol such as E-UTRAN, with fourth-generation (4G) wireless communication protocols or the like. As an alternative (or additionally), the mobile terminal 10 may be capable of operating in accordance with non-cellular communication mechanisms. For example, the mobile terminal 10 may be capable of communication in a wireless local area network (WEAN) or other communication networks described below in connection with
In some embodiments, the controller 20 may include circuitry desirable for implementing audio and logic functions of the mobile terminal 10. For example, the controller 20 may be comprised of a digital signal processor device, a microprocessor device, and various analog to digital converters, digital to analog converters, and other support circuits. Control and signal processing functions of the mobile terminal 10 are allocated between these devices according to their respective capabilities. The controller 20 thus may also include the functionality to convolutionally encode and interleave message and data prior to modulation and transmission. The controller 20 may additionally include an internal voice coder, and may include an internal data modem. Further, the controller 20 may include functionality to operate one or more software programs, which may be stored in memory. For example, the controller 20 may be capable of operating a connectivity program, such as a conventional Web browser. The connectivity program may then allow the mobile terminal 10 to transmit and receive Web content, such as location-based content and/or other web page content, according to a Wireless Application Protocol (WAP), Hypertext Transfer Protocol (HTTP) and/or the like, for example.
The mobile terminal 10 may also comprise a user interface including an output device such as a conventional earphone or speaker 24, a ringer 22, a microphone 26, a display 28, and a user input interface, all of which are coupled to the controller 20. The user input interface, which allows the mobile terminal 10 to receive data, may include any of a number of devices allowing the mobile terminal 10 to receive data, such as a keypad 30, a touch display (not shown) or other input device. In embodiments including the keypad 30, the keypad 30 may include the conventional numeric (0-9) and related keys (#, *), and other hard and soft keys used for operating the mobile terminal 10. Alternatively, the keypad 30 may include a conventional QWERTY keypad arrangement. The keypad 30 may also include various soft keys with associated functions. In addition, or alternatively, the mobile terminal 10 may include an interface device such as a joystick or other user input interface. The mobile terminal 10 further includes a battery 34, such as a vibrating battery pack, for powering various circuits that are required to operate the mobile terminal 10, as well as optionally providing mechanical vibration as a detectable output.
In addition, the mobile terminal 10 may include one or more physical sensors 36. The physical sensors 36 may be devices capable of sensing or determining specific physical parameters descriptive of the current context of the mobile terminal 10. For example, in some cases, the physical sensors 36 may include respective different sending devices for determining mobile terminal environmental-related parameters such as speed, acceleration, heading, orientation, inertial position relative to a starting point, proximity to other devices or objects, lighting conditions and/or the like.
In an example embodiment, the mobile terminal 10 may further include a co-processor 37. The co-processor 37 may be configured to work with the controller 20 to handle certain processing tasks for the mobile terminal 10. In an example embodiment, the co-processor 37 may be specifically tasked with handling (or assisting with) context extraction and fusion capabilities for the mobile terminal 10 in order to, for example, interface with or otherwise control the physical sensors 36 and/or to manage the extraction and fusion of context information.
The mobile terminal 10 may further include a user identity module (UIM) 38. The UIM 38 is typically a memory device having a processor built in. The UIM 38 may include, for example, a subscriber identity module (SIM), a universal integrated circuit card (UICC), a universal subscriber identity module (USIM), a removable user identity module (R-UIM), and the like. The UIM 38 typically stores information elements related to a mobile subscriber. In addition to the UIM 38, the mobile terminal 10 may be equipped with memory. For example, the mobile terminal 10 may include volatile memory 40, such as volatile Random Access Memory (RAM) including a cache area for the temporary storage of data. The mobile terminal 10 may also include other non-volatile memory 42, which may be embedded and/or may be removable. The memories may store any of a number of pieces of information, and data, used by the mobile terminal 10 to implement the functions of the mobile terminal 10. For example, the memories may include an identifier, such as an international mobile equipment identification (IMEI) code, capable of uniquely identifying the mobile terminal 10.
In an example embodiment, the network 50 includes a collection of various different nodes, devices or functions that are capable of communication with each other via corresponding wired and/or wireless interfaces. As such, the illustration of
One or more communication terminals such as the mobile terminal 10 and the other communication devices may be capable of communication with each other via the network 50 and each may include an antenna or antennas for transmitting signals to and for receiving signals from a base site, which could be, for example a base station that is a part of one or more cellular or mobile networks or an access point that may be coupled to a data network, such as a local area network (LAN), a metropolitan area network (MAN), and/or a wide area network (WAN), such as the Internet. In turn, other devices such as processing devices or elements (for example, personal computers, server computers or the like) may be coupled to the mobile terminal 10 via the network 50. By directly or indirectly connecting the mobile terminal 10 and other devices to the network 50, the mobile terminal 10 and the other devices may be enabled to communicate with each other and/or the network, for example, according to numerous communication protocols including Hypertext Transfer Protocol (HTTP) and/or the like, to thereby carry out various communication or other functions of the mobile terminal 10 and the other communication devices, respectively.
Furthermore, although not shown in
Referring now to
The processor 70 may be embodied in a number of different ways. For example, the processor 70 may be embodied as one or more of various processing means such as a microprocessor, a controller, a digital signal processor (DSP), a processing device with or without an accompanying DSP, or various other processing devices including integrated circuits such as, for example, an ASIC (application specific integrated circuit), an FPGA (field programmable gate array), a microcontroller unit (MCU), a hardware accelerator, a special-purpose computer chip, processing circuitry, or the like. In an example embodiment, the processor 70 may be configured to execute instructions stored in the memory device 76 or otherwise accessible to the processor 70. Alternatively or additionally, the processor 70 may be configured to execute hard coded functionality. As such, whether configured by hardware or software methods, or by a combination thereof, the processor 70 may represent an entity (for example, physically embodied in circuitry) capable of performing operations according to embodiments while configured accordingly. Thus, for example, when the processor 70 is embodied as an ASIC, FPGA or the like, the processor 70 may be specifically configured hardware for conducting the operations described herein. Alternatively, as another example, when the processor 70 is embodied as an executor of software instructions, the instructions may specifically configure the processor 70 to perform the algorithms and/or operations described herein when the instructions are executed. However, in some cases, the processor 70 may be a processor of a specific device (for example, the mobile terminal 10 or other communication device) adapted for employing various embodiments by further configuration of the processor 70 by instructions for performing the algorithms and/or operations described herein. The processor 70 may include, among other things, a clock, an arithmetic logic unit (ALU) and logic gates configured to support operation of the processor 70.
Meanwhile, the communication interface 74 may be any means such as a device or circuitry embodied in either hardware, software, or a combination of hardware and software that is configured to receive and/or transmit data from/to a network and/or any other device or module in communication with the apparatus. In this regard, the communication interface 74 may include, for example, an antenna (or multiple antennas) and supporting hardware and/or software for enabling communications with a wireless communication network. In some environments, the communication interface 74 may alternatively or also support wired communication. As such, for example, the communication interface 74 may include a communication modem and/or other hardware/software for supporting communication via cable, digital subscriber line (DSL), universal serial bus (USB) or other mechanisms.
The user interface 72 may be in communication with the processor 70 to receive an indication of a user input at the user interface 72 and/or to provide an audible, visual, mechanical or other output to the user. As such, the user interface 72 may include, for example, a keyboard, a mouse, a joystick, a display, a touch screen, soft keys, a microphone, a speaker, or other input/output mechanisms. In an example embodiment in which the apparatus is embodied as a server or some other network devices, the user interface 72 may be limited, or eliminated. However, in an embodiment in which the apparatus is embodied as a communication device (for example, the mobile terminal 10), the user interface 72 may include, among other devices or elements, any or all of a speaker, a microphone, a display, and a keyboard or the like. In this regard, for example, the processor 70 may comprise user interface circuitry configured to control at least some functions of one or more elements of the user interface, such as, for example, a speaker, ringer, microphone, display, and/or the like. The processor 70 and/or user interface circuitry comprising the processor 70 may be configured to control one or more functions of one or more elements of the user interface through computer program instructions (e.g., software and/or firmware) stored on a memory accessible to the processor 70 (for example, memory device 76, and/or the like).
In an example embodiment, the apparatus may further include a sensor processor 78. The sensor processor 78 may have similar structure (albeit perhaps with semantic and scale differences) to that of the processor 70 and may have similar capabilities thereto. However, according to an example embodiment, the sensor processor 78 may be configured to interface with one or more physical sensors (for example, physical sensor 1, physical sensor 2, physical sensor 3, . . . , physical sensor n, where n is an integer equal to the number of physical sensors) such as, for example, an accelerometer, a magnetometer, a proximity sensor, an ambient light sensor, and/or any of a number of other possible sensors. In some embodiments, the sensor processor 78 may access a portion of the memory device 76 or some other memory to execute instructions stored thereat. Accordingly, for example, the sensor processor 78 may be configured to interface with the physical sensors via sensor specific firmware that is configured to enable the sensor processor 78 to communicate with each respective physical sensor. In some embodiments, the sensor processor 78 may be configured to extract information from the physical sensors (perhaps storing such information in a buffer in some cases), perform sensor control and management functions for the physical sensors and perform sensor data pre-processing. In an example embodiment, the sensor processor 78 may also be configured to perform sensor data fusion with respect to the physical sensor data extracted. The fused physical sensor data may then be communicated to the processor 70 (for example, in the form of fusion manager 80, which is described in greater detail below) for further processing. In some embodiments, the sensor processor 78 may include a host interface function for managing the interface between the processor 70 and the sensor processor 78 at the sensor processor 78 end. As such, the sensor processor 78 may be enabled to provide data from the physical sensors, status information regarding the physical sensors, control information, queries and context information to the processor 70.
In an example embodiment, the processor 70 may be embodied as, include or otherwise control the fusion manager 80. As such, in some embodiments, the processor 70 may be said to cause, direct or control the execution or occurrence of the various functions attributed to the fusion manager 80 as described herein. The fusion manager 80 may be any means such as a device or circuitry operating in accordance with software or otherwise embodied in hardware or a combination of hardware and software (for example, processor 70 operating under software control, the processor 70 embodied as an ASIC or FPGA specifically configured to perform the operations described herein, or a combination thereof) thereby configuring the device or circuitry to perform the corresponding functions of the geo-fusion manager 80 as described herein. Thus, in examples in which software is employed, a device or circuitry (for example, the processor 70 in one example) executing the software forms the structure associated with such means.
The fusion manager 80 may be configured to communicate with the sensor processor 78 (in embodiments that employ the sensor processor 78) to receive pre-processed physical sensor data and/or fused physical sensor data. In embodiments where no sensor processor 78 is employed, the fusion manager 80 may be further configured to pre-process and/or fuse physical sensor data. In an example embodiment, the fusion manager 80 may be configured to interface with one or more virtual sensors (for example, virtual sensor 1, virtual sensor 2, . . . , virtual sensor m, where m is an integer equal to the number of virtual sensors) in order to fuse virtual sensor data with physical sensor data. Virtual sensors may include sensors that do not measure physical parameters. Thus, for example, virtual sensors may monitor such virtual parameters as RF activity, time, calendar events, device state information, active profiles, alarms, battery state, application data, data from webservices, certain location information that is measured based on timing (for example, GPS position) or other non-physical parameters (for example, cell-ID), and/or the like. The virtual sensors may be embodied as hardware or as combinations of hardware and software configured to determine the corresponding non-physical parametric data associated with each respective virtual sensor. In some embodiments, the fusion of virtual sensor data with physical sensor data may be classified into different levels. For example, context fusion may occur at the feature level, which may be accomplished at a base layer, at a decision level, which may correspond to middleware, or in independent applications, which may correspond to an application layer. The fusion manager 80 may be configured to manage context fusion (for example, the fusion of virtual and physical sensor data related to context information) at various ones and combinations of the levels described above.
Thus, according to some example embodiments, context data extraction and fusion of the context data that has been extracted may be performed by different entities, processors or processes in a distributed fashion or layered/linear way. A set of physical sensors may therefore be interfaced with the sensor processor 78, which is configured to manage physical sensors, pre-processes physical sensor data and extract a first level of context data. In some embodiments, the sensor processor 78 may perform data level context fusion on the physical sensor data. The sensor processor 78 may be configured to use pre-processed data and context from other subsystems that may have some type of physical data source (for example, modem, RF module, AV module; GPS subsystems, etc.) and perform a context fusion. In some embodiments, a second level, and perhaps also subsequent levels, of context fusion may be performed to fuse the physical sensor data with virtual sensor data using the processor 70 (for example, via the fusion manager 80). As such, the fusion manager 80 may fuse virtual sensor data and physical sensor data in the operating system layers of the apparatus.
As the processor 70 itself is a processor running an operating system, the virtual context fusion processes running in the processor 70 (for example, in the form of the fusion manager 80) may have access to the context and physical sensor data from the sensor processor 78. The processor 70 may also have access to other subsystems with physical data sources and the virtual sensors. Thus, a layered or distributed context sensing process may be provided.
It should also be appreciated that the independent application may perform yet another (for example, a fourth level) of context sensing and fusion. Moreover, as is shown in
As may be appreciated, the embodiment of
A specific example will now be described for purposes of explanation and not of limitation in reference to
As shown in
Meanwhile, the sensor processor 78 may also implement feature extraction for the accelerometer signal. The raw accelerometer signal may be sampled (e.g., at a sampling rate of 100 Hz) and may represent the acceleration into three orthogonal directions, x, y, z. In one embodiment, feature extraction starts by taking a magnitude of the three dimensional acceleration, to result in a one-dimensional signal. In another example embodiment, a projection onto a vector is taken of the accelerometer signal to obtain a one-dimensional signal. In other embodiments, the dimensionality of the accelerometer signal subjected to feature extraction may be larger than one. For example, the three-dimensional accelerometer signal could be processed as such, or a two-dimensional accelerometer signal including two different projections of the original three-dimensional accelerometer signal could be used.
Feature extraction may, for example, comprise windowing the accelerometer signal, taking a Discrete Fourier Transform (DFT) of the windowed signal, and extracting features from the DFT. In one example, the features extracted from the DFT include, for example, one or more spectrum power values, power spectrum centroid, or frequency-domain entropy. In addition to features based on the DFT, the sensor processor 78 may be configured to extract features from the time-domain accelerometer signal. These time-domain features may include, for example, mean, standard deviation, zero crossing rate, 75% percentile range, interquartile range, and/or the like.
Various other processing operations may also be performed on the accelerometer data. One example includes running a step counter to estimate the step count and step rate for a person. Another example includes running an algorithm for step length prediction, to be used for pedestrian dead reckoning. Yet another example includes running a gesture engine, which detects a set of gestures, such as moving a hand in a certain manner. Inputs related to each of these processing operations may also be extracted and processed for context fusion as described in greater detail below in some cases.
After extraction of the audio and accelerometer feature data by the sensor processor 78, the sensor processor 78 may pass the corresponding audio features M and accelerometer features A to the processor for context fusion involving virtual sensor data. Base layer audio processing according to one example embodiment may include communication of the MFCC feature vectors extracted above from the sensor processor 78 to the base layer of the processor 70 to produce a set of probabilities for audio context recognition. In some cases, to reduce the data rate communicated to the processor 70, the processor 70 may read raw audio data, e.g., using a single channel audio input running at 8000 kHz sampling rate and 16-bit resolution audio samples, to correspond to a data rate of 8000*2=16000 bytes/s. When communicating only the audio features, with a frame skip of 50 ms, the data rate would become about 1000/50*39*2=1560 bytes/s (assuming features represented at 16-bit resolution).
Audio context recognition may be implemented e.g. by training a set of models for each audio environment in an off-line training stage, storing the parameters of the trained models in the base layer, and then evaluating the likelihood of each model generating the sequence of input features in the online testing stage with software running in the base layer. As an example, Gaussian mixture models (GMM) may be used. The GMM parameters, which include the component weights, means, and covariance matrices, may be trained in an off-line training stage using a set of labeled audio data and the expectation maximization (EM) algorithm. The audio context recognition process in the base layer may receive a sequence of MFCC feature vectors as an input, and evaluate the likelihood of each context GMM having generated the features. The likelihoods p(M|Ei), for the set of environments Ei, i=1, . . . , N, where M is a sequence of MFCC feature vectors and N the number of environments trained in the system, may be communicated further to the middleware.
In some optional cases, a form of feature level fusion may be employed in the base layer. For example, features produced by another sensor, such as an accelerometer or illumination sensor, could be appended to the MFCC features, and used to generate the probabilities for environments E.
In some embodiments, the sensor processor 78 may also be configured to perform audio context recognition or activity recognition. For example, in the case of audio context recognition, GMMs with quantized parameters, which enable implementing the classification in a computationally efficient manner with lookup operations, may be utilized. An example benefit of this may be to further reduce the amount of data to be communicated to the base layer. For example, the sensor processor could communicate e.g. the likelihoods p(M|Ei) of the environments at a fixed interval such as every 3 seconds.
In one example embodiment, processing of accelerometer data at the base layer may include receiving a feature vector from the sensor processor 78 at regular time intervals (e.g., every 1 second). Upon receiving the feature vector, the base layer may perform classification on the accelerometer feature vector. In one embodiment, activity classification may be performed using the accelerometer feature vector. This can be implemented in some examples by training a classifier, such as a k-Nearest neighbors or any other classifier, for a set of labeled accelerometer data from which features are extracted. In one embodiment, a classifier is trained for classifying between running, walking, idle/still, bus/car, bicycling, and skateboarding activities. The activity classifier may produce probabilities P(A|Yj) for the set of activities j=1, . . . , M. A may include at least one feature vector based on the accelerometer signal. In the case of the k-Nearest neighbors classifier, the probability for activity Y, may be calculated as, for example, a proportion of samples from class Yi among the set of nearest neighbors (e.g. 5 nearest neighbors). In other embodiments, various other classifiers may be applied, such as Naïve Bayes, Gaussian Mixture Models, Support Vector Machines, Neural Networks, and so on.
The software implemented on the middleware may receive various hypotheses from the base layer, and may perform decision level fusion to give a final estimate of the context. In one embodiment, the middleware receives a likelihood for the environment based on the audio features p(M|Ei), a probability for the activity based on the accelerometer data P(A|Yj), and forms a final hypothesis of the most likely environment and activity pair given the sensory hypotheses and one or more virtual sensors. In some embodiments, an example virtual sensor input may be a clock input so that a time prior may be included in the determination regarding the likely environment. The time prior may represent the prior likelihoods for environments, activities, and/or their combinations. The method of incorporating the time prior may be, for example, the one described in the patent application PCT/IB2010/051008, “Adaptable time-based priors for automatic context recognition” by Nokia Corporation, filed 9 Mar. 2010, the disclosure of which is incorporated herein by reference.
As another example, prior information may be incorporated to the decision in the form of a virtual sensor. The prior information may represent, for example, prior knowledge of the common occurrence of different activities and environments. More specifically, the prior information may output a probability P(Yj,Ei) for each combination of environment Ei and activity Yj. The probabilities may be estimated offline from a set of labeled data collected from a set of users, comprising the environment and activity pair. As another example, information on common environments and activities may be collected from the user in the application layer, and communicated to the middleware. As another example, the values of pji=P(Yj,Ei) may be selected as follows:
where, the environments Ei, =1, . . . , 9; are car/bus, home, meeting/lecture, office, outdoors, restaurant/pub, shop, street/road, and train/metro. The activities Yj, j=1, . . . , 7, are idle/still, walking, running, train/metro/tram, car/bus/motorbike, bicycling, and skateboarding. As another example, instead of probabilities, the values of pji can either ones or zeros, representing only which environment-activity pairs are allowed.
In one embodiment, the middleware may perform decision level data fusion by selecting the environment and activity combination which maximizes the equation P(Yj, Ei|M,A,t)=p(M|Ei)*P(A|Yj)*P(Yj,Ei|t)*P(Yj,Ei), where P(Yj,Ei|t) is a probability for the environment and activity combination from the time prior. This is communicated further to the application layer. It can be noted that maximizing the above equation can be done also by maximizing the sum of the logarithms of the terms, that is, by maximizing log[p(M|Ei)]+log[P(A|Yj)]+log[P(Yj,Ei|t)]+log[P(Yj,Ei)], where log is e.g., the natural logarithm.
Accordingly, some example embodiments may employ a single interface to connect an array of sensors to baseband hardware. High speed I2C/SPI serial communication protocols with register mapped interface may be employed along with communication that is INT (interrupt signal) based. Moreover, the host resources (e.g., the main processor) may only be involved to the extent needed. Thus, some embodiments may provide for relatively simple and lean sensor kernel drivers. For example, embodiments may read only pre-processed sensor data and events and provide sensor architectural abstraction to higher operating system layers. No change may be required in kernel drivers due to sensor hardware changes and minimal architectural impact may be felt in middleware and higher operating system layers. In some embodiments, the sensor processor may deliver preprocessed data to the host. This may be characterized by a reduction in data rate and reduced processing in the host engine side while unit conversion, scaling and preprocessing of sensor data can be performed at the microcontroller level. Specialized/complex DSP algorithms may be performed on sensor data in the microcontroller level to support close to real time sensor and event processing. Sensor data may therefore be processed at higher data rates with faster and more accurate responses. In some cases, host response time may also be more predictable.
In some embodiments, improved energy management may also be provided in the subsystem level. For example, sensor power management may be done in the hardware level and a sensor control and manager module may optimize sensor on/off times to improve performance while saving power. Continuous and adaptive context sensing may also be possible. Context sensing, event detection, gestures determining algorithms, etc., may be enabled to run continuously using less power than running in the host engine side. Thus, adaptive sensing for saving power may be feasible. In some embodiments, event/gesture detection may be performed at the microcontroller level. In an example embodiment, accelerometer data may be used to perform tilt compensation and compass calibration. Context extraction and continuous context sensing may therefore be feasible in a variety of contexts. For example, environmental context (indoor/outdoor, home/office, street/road, etc.), user context (active/idle, sitting/walking/running/cycling/commuting, etc.) and terminal context (active/idle, pocket/desk, charging, mounted, landscape/portrait, etc.). Context confidence index may therefore be increased as the context propagates to upper operating system layers and when further context fusion with virtual sensors is done. Thus, for example, attempts to determine the current context or environment of the user, which may in some cases be used to enhance services that can be provided to the user, may be more accurately determined. As a specific example, physical sensor data may be extracted indicate that the user is moving in a particular pattern, and may also indicate a direction of motion and perhaps even a location relative to a starting point. The physical sensor data may then be fused with virtual sensor data such as the current time and the calendar of the user to determine that the user is transiting to a particular meeting that is scheduled at a corresponding location. Thus, by performing sensor data fusion, which according to example embodiments can be done in a manner that does not heavily load the main processor, a relatively accurate determination may be made as to the user's context.
Apart from context extraction at the baseband hardware subsystem level, some embodiments may further enable distributed context extraction and fusion. A first level of continuous context extraction and fusion may be performed with respect to physical sensor data in a dedicated low-power sensor processor configured to perform continuous sensor pre-processing, sensor management, context extraction and communication with a main processor when appropriate. The main processor may host the base layer, middleware and application layer and context information related to physical sensors from the sensor processor may then be fused with virtual sensor data (clock, calendar, device events, and the like.) at the base layer, middleware and/or application layer for providing more robust, accurate and decisive context information. At every operating system layer, various embodiments may enable decisions to be made based on the context to optimize and deliver improved device performance. Some embodiments may also enable applications and services to utilize the context information to provide proactive and context based services, with an intuitive and intelligent user interface based on device context.
Accordingly, blocks of the flowchart support combinations of means for performing the specified functions, combinations of operations for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that one or more blocks of the flowchart, and combinations of blocks in the flowcharts, can be implemented by special purpose hardware-based computer systems which perform the specified functions, or combinations of special purpose hardware and computer instructions.
In this regard, a method according to one embodiment, as shown in
In some embodiments, certain ones of the operations above may be modified or further amplified as described below. Moreover, in some embodiments additional optional operations may also be included (an example of which is shown in dashed lines in
In an example embodiment, an apparatus for performing the method of
Many modifications and other embodiments set forth herein will come to mind to one skilled in the art to which these inventions pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the inventions are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Moreover, although the foregoing descriptions and the associated drawings describe example embodiments in the context of certain example combinations of elements and/or functions, it should be appreciated that different combinations of elements and/or functions may be provided by alternative embodiments without departing from the scope of the appended claims. In this regard, for example, different combinations of elements and/or functions than those explicitly described above are also contemplated as may be set forth in some of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/IB2010/001109 | 5/13/2010 | WO | 00 | 11/9/2012 |
