FIELD OF THE INVENTION

Generally the present invention pertains to provision of alarms based on environmental monitoring. In particular, however not exclusively, the present invention relates to the provision of alarm signals utilizing communications-enabled mobile devices.

BACKGROUND

Contemporary solutions for automatically detecting unusual, typically undesired, events such as fire and fluid leaks are often based on dedicated stand-alone alarm devices that are configured to monitor a predetermined environmental parameter such as the amount of smoke or carbon monoxide in the air and to trigger an audible, relatively loud alarm signal when the measured value exceeds a predetermined threshold. These devices are, upon installation, mounted in target locations such as the ceiling or floor of the space to be monitored and usually remain there untouched, or 'forgotten', between the necessary battery changes or other mandatory service operations.

For example, a smoke detector, generally provided in a form of a book-sized plastic disc, may be fixedly mounted in the ceiling of the monitored space such as a living room of a private house where it is used to audibly warn with siren- type noise the residents, which may be in sleep etc., about the detected excessive amounts of smoke typically indicative of fire nearby. The detector may be battery-powered or connected to the mains.

Notwithstanding the obvious benefits the current solutions obviously offer in detecting and warning about various potentially hazardous conditions, some problems and defects remain associated therewith. The solutions are often self- containing and independent but, partially for that particular reason, also relatively inflexible what comes to the intended use scenario and use environment, detection logic, monitored variables, alarm provision techniques, and linkability thereof. A number of specialized devices must be acquired for each monitoring and alarming purpose, and in any case, the spatial reach of the triggered alarm is modest. For instance, even a loud audible siren will be practically efficient, i.e. catch the attention of listeners, only within the immediate vicinity of the associated loudspeaker or horn, which applies in particular to indoor conditions but al- so to large outdoor areas such as industrial compounds that may suffer from surprisingly high level of background noise, i.e. ambient noise, which reduces the effect of the siren considerably at higher distances. If nobody is around or responsive to the alarm, the detected condition may naturally emerge even to a real catastrophe despite the technically timely detection thereof.

SUMMARY OF THE INVENTION

The objective is to alleviate one or more problems described hereinabove and not yet satisfactorily addressed by the known arrangements, and to provide a feasible solution for environmental monitoring and related communication of alarms.

The objective is achieved by the embodiments of a mobile device, a stand, a network arrangement, a system and a method in accordance with the present invention. Computer software that may be stored on a carrier medium may be provided to carry out method items when run on a computer.

Accordingly, in one aspect of the present invention an electronic mobile device, such as a smartphone, a tablet or other mobile consumer electronics device, comprises

-a data input entity configured to obtain data, preferably audio data, indicative of environmental sounds occurring in a monitored environment,

-an alarm repository configured to store a number of predetermined indications of alarm sounds and/or alarm-triggering sounds,

-an analyzer configured to detect an alarm sound or an alarm-triggering sound in the monitored environment based on the obtained data and indications in the alarm repository, -a context finder configured to determine context information associated with the mobile device, such as location context, and to adapt the execution of the analyzer utilizing the context information, and -a notification entity configured to preferably wirelessly transmit an alarm signal based on the detection result, such as detection of the alarm sound or alarm- triggering sound, to enable remote notification of the alarm-triggering condition.

In one embodiment, the data input entity incorporates or is at least functionally connected to at least one microphone capable of converting sound into electrical form. The microphone may be configured to capture audible sound and/or inaudible sound (out of normal hearing range of humans) such as ultrasound. In some embodiments, the data input entity may be configured to receive, via the microphone and as acoustic, e.g. audible and/or ultrasonic, signaling, data indicative of environmental sounds occurring in the monitored environment.

In another, either supplementary or alternative, embodiment the data input entity includes a data receiver, such as a wireless receiver, for receiving, as electric (analogue or digital) signal(s), data indicative of environmental sounds occurring in the monitored environment. The receiver may be preferably implemented as a wireless LAN (WLAN, wireless local area network) receiver/transceiver or e.g. as a Bluetooth receiver/transceiver. For instance, a wireless microphone or an alarm device may be configured to provide the data via a radio frequency signal ( F signal) to the receiver. Still, an optical receiver such as infrared or visible light receiver could be exploited.

Optionally, the data input entity may incorporate a variety of UI (user interface), particularly user input, elements such as a number of keys, knobs, buttons, a touchscreen, a (contactless) gesture interface, a touchpad, and/or a speech recog- nizer to enable manually triggering or cancelling an alarm by the user of the mobile device not forgetting the obviously great number of other potential uses for device and application control. Optionally, the user may also indicate the seriousness and/or other characteristic of the alarm via the UI provided by the data input entity.

In a further embodiment the alarm repository is configured to store predetermined indication of an alarm sound or alarm-triggering sound as a number of digital sound samples. Alternatively or additionally, the indication may include a number of parameters characterizing the sound, the parameters optionally characterizing at least one sound feature selected from the group consisting of: frequency, frequency range, duration, harmonics, intensity, timbre, melody, pause or break, tempo, and audio-to-text conversion result.

Yet in a further embodiment, the analyzer is configured to detect an alarm sound or an alarm-triggering sound through utilization of a procedure in which the obtained data is, either as such or in a processed form, compared to indications in the alarm repository (again as such or as processed) to find a match, if any, according to predetermined, optionally adaptive, criteria. The analyzer may apply a number of signal processing activities such as FFT (Fast-Fourier Transform) algorithm in the procedure. One shall note that the analyzer may be configured to deem a certain sound represented by the obtained data as an alarm sound based on a number of recognizable general characteristics that are often associated with alarm sounds. Thus, instead of or in addition to indications of certain very specific alarm sounds, i.e. default sound of a certain alarm device model or e.g. a sound fully congruent with a predetermined detailed standard, the alarm repository may contain indications representing alarm sounds or a certain class of alarm sounds more generally, such indications being thus shared by several existing and/or expected future alarm sounds. The shared characteristics, which may be initially determined based on analyzing different alarm sounds and/or related specifications or standards, may imply e.g. certain sound frequency or frequency range in combination with a distinctive pulsing pattern, by which many beep type alarms, for instance, may be characterized.

An alarm sound detected by the analyzer on the basis of at least one matching in- dication in the alarm repository may include an alarm sound selected from the group consisting of: smoke detector alarm, fire detector alarm, carbon monoxide detector alarm, gas detector alarm, refrigeration appliance alarm, temperature alarm, fridge alarm, freezer alarm, high temperature alarm, low temperature alarm, freezing alarm, burglar alarm, door alarm, door open alarm, window alarm, glass-breaking alarm, moisture alarm, water alarm, liquid leakage alarm, motion alarm, vibration alarm, personal security (device) alarm, baby alarm (or 'baby monitor' alarm), clothes iron alarm, and doorbell chime (may be alternatively considered as an alarm- triggering sound).

An alarm-triggering sound detected by the analyzer may further include at least one sound selected from the group consisting of: yelling noise, a call for help, moaning noise, animal-produced sound, dog barking, speech, crying, child crying, bang, falling down noise, glass-breaking noise, squeaking noise, crash noise, and snoring sound. Regarding e.g. speech or a call for help, also more specific instances thereof may be detected such as predetermined key sentences or words like 'help' utilizing the applicable speech recognition technology. Utilization of such technology may facilitate in making a distinction between e.g. a call for help, i.e. indication of an accident or other hazard, and loud yells at other events, which might be rather in- nocent and take place at a sports contest, etc. Instead of or in addition to actual speech recognition technology, speech detection technology could be applied to generally detect the presence of speech in the obtained data.

An alarm sound -providing device (alarm device) may be configured to produce the same, preferably distinctive, sound, when the condition for alarming, or in the case of multiple conditions any of them, is met, such as a detection of excessive amounts of smoke in the monitored environment. Alternatively, the alarm device may dynamically apply a sound message coding scheme in which the alarm sound, or 'audio code', is dynamically constructed or at least adapted utilizing the applied coding specification in order to output a more informative message. A somewhat similar effect could be obtained through definition of a plurality of alarm sounds, each relating to a certain detection scenario, from which plurality a best-suiting alarm sound is run-time selected by the alarm device for reproduction upon need.

In said coding, a distinguishable, such as a spatially (e.g. frequency-wise) and/or temporally distinguishable, feature of the alarm sound may be configured to characterize at least one property associated with the alarming scenario selected from the group consisting of: location, alarm source or reason, ID of the alarm device, seriousness of the situation in accordance with a predetermined scale, recorded duration of the alarming condition, sensor value or data (or value/data derived therefrom), and intermediate or final addressee of the alarm. At least one feature may be selected from the group consisting of: frequency, frequency range, duration, intensity, melody, a pause or break, tempo, timbre, spoken message (speech synthesis being applied in the alarm device), and harmon- ics.

In some embodiments, the alarm sound may be configured to include audible and inaudible, optionally ultrasonic, portions, i.e. frequency-wise distinguishable portions. Both of the portions may indicate at least one (different) property regarding the alarming scenario. In some embodiments, the audible portion may be utilized for warning near-by person(s) whereas the inaudible portion provides additional data to receiving device(s) such as the mobile device. In some other embodiments, the alarm sound may exclusively contain inaudible frequencies such as ultrasound.

The analyzer may be configured to interpret, or 'decode', the audio coding through the utilization of indications of alarm sounds and alarm-triggering sounds stored in the alarm repository. As a result, the mobile device may recognize the alarms and incorporated information potentially indicative of a plurality of properties associated with the alarming scenario by following a predetermined sound message (de)coding scheme or standard implied by the stored indications.

In some embodiments, the alarm device may be configured to function as a repeater, i.e. upon receipt of a radio or audio signal from another, potentially dif- ferent, alarm device, it may forward it as is, or as modified or at least utilizing alternative data transfer technology. As a result, even a single mobile device may be capable of monitoring relatively large areas as the alarm devices spread within the area may be configured to forward the alarms towards it. Optionally, the mobile device may itself be configured to function as a repeater. It may communicate alarm-related data such as the alarm sound, portion thereof, and/or data derived therefrom forward as audible and/or inaudible sound. Alternatively or additionally, feasible RF technology such as short-range radio technology, optionally complying with WLAN or Bluetooth specifications, may be utilized for carrying out the repeating function. The alarm repository, which may be implemented as a database, for instance, may be initially established and subsequently updated e.g. by the mobile device manufacturer or software manufacturer, or by a selected third party, and supplied in connection with the mobile device and/or alarm provision software among other delivery options.

Preferably the repository may be expanded and/or changed, if not created from the scratch, by the users. This may apply both to personal alarm repositories stored either locally at the mobile devices or at a remote location, and a common repository accessible e.g. via a network service and available for more general download. New or updated indications may be added to the repository through programming or teaching/learning procedures to be described in further detail hereinafter, for instance.

New or updated indications may be received from a network service (described in further detail hereinafter) automatically, e.g. periodically, or in response to manual triggering. The users may be given a possibility to update new indications to the network service to supplement the existing central repository and enable distribution and exploitation of the indication by other users. A group of users and/or associated mobile devices between which the new indications of alarm sounds are preferably automatically transferred may be formed or maintained at the service. E.g. in a family context one user may teach his/her mobile device to recognize smoke alarm sound at the summer cottage, whereupon the mobile devices or other family members are updated correspondingly to detect such sound.

As the indications may cover a wide variety of different sounds some of which may not be equally relevant to all users, the alarm repository may be optionally provided as a modular entity that may be obtained and utilized, optionally updated, also in parts. Different indications may be organized into a number of groups based on the type of the sound and/or emitting device (e.g. smoke alarms, burglar alarms, etc.), for instance.

In a further embodiment, the context finder is configured to determine context information through the utilization of the obtained data indicative of the environ- mental sounds occurring in the monitored environment. On the basis of amount and/or nature of the ambient sounds, or 'soundscape', the context finder entity may then establish the context information such as activity context information and/or location context information.

Additionally or alternatively, the data input entity may comprise a receiver, such as a satellite (GPS (Global Positioning System), GLONASS (Global Navigation Satellite System), etc.) receiver, a short-range RF receiver/transceiver (WLAN, Bluetooth, etc.) and/or a cellular receiver/transceiver (e.g. GSM (Global System for Mobile Communications), UMTS (Universal Mobile Telecommunications System)) that facilitates location context determination based on the received da- ta. The mobile device may be configured to receive dedicated positioning signals or apply the received other signals for positioning through the analysis of e.g. signal strength and application of triangulation, for instance.

Optionally, the mobile device includes an inertial sensor such as an accelerome- ter. Such sensor may be provide valuable data about the context of the mobile device relative to activities such as movements, acceleration, shocks, vibration, falling, etc. The obtained data may be utilized, optionally together with data indicative of environmental sounds, in determining the likelihood of an emergency situation such as a car crash or falling down, which may induce a need to locally trigger an alarm and send the alarm signal by the mobile device.

In some embodiments, passivity, immobility and/or silence, i.e. some extremes of activity and sound detection, may be detected utilizing e.g. inertial sensor, positioning signal, and/or microphone signal, respectively. Such detection may be utilized in detecting a possible emergency situation regarding the user of the mobile device and triggering an alarm.

Adaptation of the execution of the analyzer may include at least one action selected from the group consisting of: activation of the analyzer execution, deacti- vation of the analyzer execution, simplification of the analysis, complication of the analysis, adding a new data input to the analysis such as a sensor input, deleting a data input, changing or adjusting an analysis rule to trigger an alarm, changing or adjusting the sub-task to be executed during the analysis, activating a sub-task, and deactivating a sub-task.

In some embodiments, the context information may also be utilized to activate, deactivate or otherwise adapt the function of the data input entity. Adapting may comprise changing the parameters regarding the audio input filter(s), sampling rate, and/or the audio compression method, for instance. Further, the notification entity may be adapted such as the method and/or timing of transmission selected responsive to the context.

In some embodiments, a further feature such as the active mode, or 'usage profile', associated with the mobile device, such as with the monitoring and alarming software, and/or the user thereof, may be preferably automatically determined utilizing the context information. The mode may refer to a certain combination of device settings regarding e.g. data input, analysis, communication, alarms, etc. Each profile may be linked at the mobile device with a certain combination of monitored parameters, sensors, sensor settings and/or analysis rules. For example, a number of dedicated modes, or 'profiles', regarding home and out-of-home situations may be allocated. The context and/or mode information may in some embodiments be funneled by the notification entity to a network service for storing context and/or mode data therein and optionally streamlining the user's service profile (mode) in accordance therewith. Alternatively, the active profile may be selected manually by the user of the mobile device via the UI thereof. The active profile may, in turn, be utilized in determining the logic for input data analysis and/or alarm triggering.

In a further embodiment, the notification entity may be generally configured to transmit RF signals or acoustic, e.g. ultrasonic, signals. For example, a cellular or a short-range transmitter, such as WLAN or Bluetooth transmitter, may be ap- plied for the purpose.

Further, the alarm signal may be transferred utilizing a textual or multimedia message such as an SMS (Short Message Service) or MMS (Multimedia Messaging Service) message, respectively. As a further example, e-mail is given. Alter- natively or additionally, circuit-switched, e.g. HSCSD (High Speed Circuit- Switched Data), or packet- switched, e.g. GPRS (General Packet Radio Service), data transfer may be used. As one more example, a call such as a voice call may be established to provide the alarm signal. Optionally DTMF (Dual-Tone Multi- Frequency) signaling may be utilized therewith for alarm-related data transfer.

In some embodiments, the alarm signal may especially incorporate location information such as coordinate information. The location information may facili- tate arranging rapid assistance to solve the hazard or other emergency situation implied by the alarm.

In some embodiments, the destination or recipient (e.g. certain device ID, service ID, user ID) of the alarm signal may be pre-defined (but optionally user- changeable or remotely changeable at/by a network service, for instance) or dynamically determined and, in the latter case, depend e.g. on at least one factor selected from the group consisting of: location of the alarm device, location of the mobile device, alarm type or reason, time of alarm, and destination/recipient in- formation indicated by the alarm device optionally via the alarm sound.

In some embodiments, the alarm may be indicated to the same user that is associated with alarming mobile device. The user may be alarmed via e-mail, other mobile device, network service, phone call, pager, etc. Information about the dif- ferent available contact means regarding the users may be stored in the alarming mobile device and/or at the network service. They may be mutually prioritized or alternatively, the alarm may be provided for delivery via many or all of those. In some embodiments, the user may select active method(s) and/or active device(s) through which he/she desired to receive alarms. Indication of such selection may be stored at the network service. In some embodiments, the optimum alarming technique regarding a certain user is selected dynamically.

In some embodiments, at least some of the final recipients of the alarm signal notifications are determined by the associations hosted by a network service con- figured to initially receive the alarm signal as to be explained in more detail here- inlater. The mobile device may be thus configured, by default, to transmit the alarm signal to the network service for final addressee determination and routing. Nevertheless, the mobile device may be advantageously utilized to access the service and change the fixed recipients and/or adjust the logic for recipient selec- tion to be dynamically performed by the service upon receipt of the alarm signal. The logic may exploit the aforementioned and/or other factors. For example, the location of the potential recipients (e.g. contacts of the user of the mobile device in the network service) may be configured to affect the final selection of the alarm recipients as explained hereinbelow. In some embodiments, the mobile de- vice may be configured to receive from a network service, optionally following a corresponding request first sent to the network service, an indication of proper recipient(s) regarding the alarm signal that is then configured respectively. In a further embodiment, the mobile device includes a local alarm entity such as an audio output entity. The audio output entity may output e.g. audible speech signal indicative of the detected alarm-triggering condition, such as 'Warning: smoke detected! ', through sample playback and/or speech synthesis. Alternatively or additionally, the speech signal may indicate instructions such as 'Go to the nearest exit!' or request input from the user such as confirmation from the user regarding e.g. the condition or status of the user 'Please press button x to confirm that you are fine! ', and/or the validity of the alarm. Further, the local alarm entity may output a predetermined non-speech alarm sound, such as a beep or siren sound, optionally determined or adapted by the detected particular alarm sound or alarm-triggering sound.

In addition to the audio output entity, the local alarm entity may incorporate a visual alarm entity such as a display or a number of lights, e.g. LEDs (light- emitting diode), for visually indicating the alarm.

In a further embodiment, the mobile device includes at least one camera (sensor) for obtaining still and/or video images. The mobile device may further include a light for illuminating the camera field of view and related targets. The camera and the optional shooting light may operate in visible and/or invisible wavelengths such as infrared range. The camera may be triggered or the functional mode thereof adapted by the analyzer upon the detection of alarm or alarm- triggering sound, and/or a separate sensor such as infrared (thermal radiation) sensor may be utilized for the purpose. Camera data may be forwarded by the notification within or in connection with the alarm signal, for instance. Camera data may be utilized in determining the context information and/or be included therein. In a further embodiment, the mobile device is provided as a modular entity a part of which may be formed by an existing electronic device such as a smartphone or other consumer electronics apparatus. Different modules with characterizing features, such as various sensor modules and communication modules, may be connected together to establish a desired kind of an aggregate device. For example, a smartphone may be connected to a charger device optionally incorporating also a smoke detector or other sensor device to form the aggregate best suiting the intended use scenario. The housing, power supply, dimensions, materials, etc. of the modules may vary depending on the estimated use conditions, use frequency, available budget, etc.

In a further embodiment, the mobile device substantially is or includes a weara- ble element such as a wearable computer, optionally a wristop computer. Alternatively or additionally, the mobile device may be connected, preferably wire- lessly, to a wearable sensor, display and/or user input device such as a wristband. The wristband may include an UI for data output (e.g. display and/or a loudspeaker) and/or data input (e.g. an emergency feature, such as a button, for trig- gering an alarm and/or an acknowledgement feature for stopping the alarm/prevent triggering one). It may include a sensor such as an accelerometer for providing activity information regarding the user to the mobile device. The wearable device may include an attachment means such a clip or ring for attaching to a target element such as a wristwatch band or the user's finger, respective - ly.

In a further embodiment, a stand, or a 'dock', is provided whereto the mobile device may be releasably disposed. The stand may be powered by a battery or via mains. It may provide electricity to the mobile device via a connector or wireless- ly, e.g. inductively or capacitively. Preferably the stand is adjustable. At least a part of it may be rotatable and/or tiltable, for example, such that the alignment of the hosted mobile device and related elements such as the camera or microphone thereof may be adjusted. The support portion receiving the mobile device may be adjustable, for instance. Optionally at least limited remote control may be pro- vided over the adjustable features. For example, the mobile device may be configured to receive control instructions from a remote entity. The mobile device may then instruct the stand via a physical connector or audio commands reproduced by the loudspeaker of the mobile device and captured by the microphone of the stand, for instance, to respond to the instructions. One or more electric mo- tors such as electric servo motors may be provided in the stand to enable remote control. The remote entity may refer to a network service or another mobile device providing the control instructions optionally via the network service. Alternatively or additionally, the stand may comprise an F-based data transfer means of its own, such as a wired or wireless transceiver, for the receipt of control in- formation. In a further embodiment, a first system comprising an embodiment of the mobile device, optionally of the stand, and of an alarm device capable of emitting the alarm sound is provided. According to another aspect of the present invention, a stand for a mobile device such as the mobile device described herein is provided, comprising a battery or a connector for an external power supply for providing power to the stand and optionally charging the mobile device, a support portion for receiving the mobile device and an electric motor for dynamically adjusting the alignment of the mo- bile device while docked in the stand, said stand further comprising a data interface for receiving instructions to adjust the alignment, said data interface optionally comprising an electrical interface for the mobile device, a network interface such as LAN (Local Area Network), WLAN (Wireless LAN) or a cellular interface, or as a further option, a microphone for receiving said instructions in acous- tic (audible and/or inaudible) form.

In a further aspect of the present invention, a network arrangement, such as a number of at least functionally connected servers, for running a network service comprises

-a data input entity configured to receive an alarm signal sent by a mobile device associated with a first service user in response to an alarm sound or other triggering event detected by the device, -a user data manager configured to maintain, respective to the service users including the first service user, user data including dynamically updateable location data indicative of the location of the users and/or relationship data indicative of the associations, such as friendship or professional type relationship, between the users,

-an alarm router configured to determine a number of other service users for receiving an indication of the alarm signal based on the user data of the first service user, and -an alerting entity configured to output an indication of the alarm signal to the determined other service users as recipients. In one embodiment, the alarm router is configured to determine the other service users through the utilization of the location information. For example, a number of other users closest to the mobile device (or the alarm device, these two locations typically being in practical situations about the same) may be selected.

In another, either supplementary or alternative, embodiment, the alarm router is configured to determine the other service users through the utilization of relationship data. For example, a number of other users associated with the first user may be selected. The associations may include e.g. group memberships in addition to or instead of one-to-one relationships.

In a further, either supplementary or alternative, embodiment, the alarm router is configured to determine the other service users through the utilization of user profile data stored in the user data. The profiles may indicate the profession and/or the skills each user has (e.g. first aid), whereupon the alarm router may be configured to match the indicated characteristics of the alarming scenario with the profile data to find a number of suitable recipients with profession and/or skills potentially useful in facilitating solving the alarmed situation or providing related aid.

In a further, either supplementary or alternative, embodiment, the alarm router is configured to determine the other service users through the utilization of calendar data stored e.g. among the user data or group data. For example, the users assigned with a temporal watch shift (guard shift) according to the calendar data upon receipt of the alarm signal may be selected as alarm recipients. Optionally, at the beginning of a watch shift the service arrangement may be configured to transmit a notification message to a user(s) supposed to be alert in view of potentially forthcoming alarm indications. Further optionally, the arrangement may be configured, upon receipt of an acknowledgement regarding such notification, to switch the watch responsibility from the previous guard to the new guard (i.e. change at least the primary recipient of the alarm) and preferably notify the previous guard accordingly.

In a further, either supplementary or alternative, embodiment the alerting entity may utilize a variety of different methods for alert provision to the service users. For example, it may exploit at least one technique selected from the group consisting of: messaging via the service UI preferably accessible via the internet, messaging via the mobile device and software associated with the service, messaging via an external network service such as Facebook™ or Twitter™ optionally through the external network service -integrated application such as Face- book™ application, e-mail, textual or multimedia messaging such as SMS or MMS messaging, respectively, a phone call, and a pager message.

In some embodiments, different users may be provided with different information regarding the alarm in connection with the alarm indication. The nature and/or amount of data may depend on the utilized alert provision method and its technical limitations or other characteristics. For example, less data may be provided using SMS than e-mail. Additionally or alternatively, the data may depend on the receiving user himself/herself, e.g. on the user profile such as the relationship with the user associated with the alarming mobile device. Each user may optionally determine the desired technique of alarm reception and store the default and/or priority order of available communication methods at the service. Alternatively or additionally, the alerting entity may dynamically select the technique based on a number of factors such as location and related availability of different methods of communication regarding each user.

In a further, either supplementary or alternative, embodiment the arrangement comprises or is at least utilizing a cloud computing service for performing actions and/or storing data. As alluded hereinabove, the arrangement may comprise a number of applications embedded in other network service.

In a further embodiment, a second system comprising an embodiment of the mobile device, optionally supplemented by stand and/or the alarm device, and of the network arrangement is provided. In a further aspect, a method for alarm provision to be performed by a mobile device comprises

-storing a number of predetermined indications of alarm sounds and/or alarm- triggering sounds,

-obtaining data, preferably audio data, indicative of environmental sounds occurring in a monitored environment, -detecting an alarm sound or an alarm-triggering sound in the monitored environment based on the obtained data and indications in the alarm repository, -determining context information associated with the mobile device, such as location context, and adapting the execution of the analyzer utilizing the context information, and

-transmitting, based on the detection result, such as detecting an alarm sound or alarm- triggering sound, an alarm signal to enable remote notification of the alarm-triggering condition.

Yet in a further aspect, a method for alarm routing and notification to be performed by a network service arrangement comprises

-managing, respective to the service users including a first service user, dynamically updateable location data indicative of the location of the users and/or relationship data indicative of the associations, such as friendship or professional type relationship, between the users,

-receiving an alarm signal sent by a mobile device associated with the first service user based on an alarm sound or other triggering event detected by the device, -determining a number of other service users for receiving an indication of the alarm signal based on the user data of the first service user, and

-providing the indication of the alarm signal towards the determined other service users as recipients.

The previously presented considerations concerning the various embodiments of the mobile device, arrangement and system may be flexibly applied to the embodiments of the above methods mutatis mutandis, and vice versa, as being appreciated by a skilled person.

The utility of the present invention arises from a plurality of issues depending on each particular embodiment. First of all, many existing terminal devices, espe- cially mobile devices such as cell phones, may be cleverly harnessed for one more useful purpose, i.e. detecting alarms and conveying alarm information, without a need to invest in new or at least expensive specialized monitoring hardware. Many people already have fully or near fully working surplus termi- nals, such as previous models of their favorite mobile phone, on hand so acquiring new devices for enabling the surveillance of desired spaces may in such cases be omitted. With the optional stand, the mobile device may be aligned as desired optionally remotely and in real-time. The monitored spaces may include buildings (homes, industrial buildings, offices, etc.), outdoor areas, floors, rooms and mobile environment such as vehicles and their cabin(s) and/or environment. Also living organisms such as the users of the mobile devices, optionally being kids, and animals such as pets potentially present in the environment may be monitored. Different features of the mobile devices such as audio capturing, image capturing, alarming and/or data transfer capabilities may be exploited. The mobile devices may be flexibly configured to monitor a myriad of different alarms utilizing the integrated data input interface, microphone, camera and additional sensors at least functionally connected thereto, optionally wirelessly.

Also the related software, exploited algorithms and alarm sound 'fingerprints' and/or e.g. (de)coding scheme (to interpret the coded indications of sounds) stored in the alarm repository may be dynamically personalized, altered or updated optionally via a network service and e.g. push-type automated procedure. The users may be provided with a possibility to update and add new indications of alarm sounds or alarm-triggering sounds in a central database for public exploitation.

The mobile devices may even be exploited as personal security devices carried along and capable of detecting alarm- triggering conditions based on the analysis of the sensor data such as microphone and/or accelerometer data or in response to an explicit alarm-triggering input via the UI such as keypad of the device.

As one further remark, the context sensitivity and adaptivity of the analyzer and optional other features of the mobile device bring in supplementary benefits. For example, power consumption caused by the alarm monitoring and forwarding tasks may be minimized, detection performance enhanced and a number of other actions executed by the device optimized.

Yet, the present invention may funnel the alarm signals to a large number of re- cipients through the utilization of the existing social relationships between users. Still, also completely new social relationships may be established via the suggested network service. The network service may be functionally connected to or integrated with an existing social networking service (arrangement) to facilitate creating a large user base and target audience for the alarms. Accordingly, the social relationships already registered by such existing service may be automatically adopted. By taking into account different users' registered special abilities, training, location, status, etc. preferably in real-time or near real-time, the recipients of alarm signals may be dynamically selected in an optimized fashion. Further, the users of the network service may monitor each other and mutually exchange messages. Different user groups, such as 'alarm rings', may be established by group forming, inviting and joining procedures, for example. In a typical scenario, a bunch of friends may decide to register a common group the members of which more or less commit to receiving alarm messages from the other members of the group. Even the best method of communicating the alarms and/or data provided with the alarms may be dynamically determined on the basis of a number of factors such as location, status, user preferences, capabilities of the registered user terminals, etc. The expression "a number of refers herein to any positive integer starting from one (1), e.g. to one, two, or three.

The expression "a plurality of refers herein to any positive integer starting from two (2), e.g. to two, three, or four.

The terms "first" and "second" do not denote herein any particular priority or order. Instead, they are used to distinguish one entity such as a physical or logical element from another entity. The term "alarm-triggering sound" may herein refer to a sound the presence of which triggers the alarm at the mobile device such as the transmission of an alarm signal, or at least elevates the need to the trigger the alarm and send the signal in case further conditions are also to be fulfilled for triggering the alarm. Yet, the "alarm-triggering" sound may refer to a sound the observed nonexistence of which in the obtained analyzed data triggers the alarm or at least elevates the need for the alarm, correspondingly.

Different embodiments of the present invention are disclosed in the dependent claims.

BRIEF DESCRIPTION OF THE RELATED DRAWINGS

Next the invention is described in more detail with reference to the appended drawings in which

Fig. la illustrates a first potential use scenario and embodiment of the present in- vention.

Fig. lb illustrates another potential use scenario of the present invention.

Fig. 2 is a block diagram representing the internals of an embodiment of a mobile device in accordance with the present invention.

Fig. 3 is a block diagram representing the internals of an embodiment of a net- work arrangement in accordance with the present invention.

Fig. 4 is a flow chart of an embodiment of a first method in accordance with the present invention.

Fig. 5 is a flow chart of an embodiment of a second method in accordance with the present invention.

Fig. 6 illustrates few exemplary views of the UI of an embodiment of the mobile device according to the present invention.

DETAILED DESCRIPTION Figure la is a sketch illustrating one use scenario and embodiment of the present invention. The monitored environment 100 may refer to a substantially fixed space such as a building, floor(s), room(s), yard, terrace, corridor, pier, compound, or a mobile environment such as a vehicle (e.g. car or truck) and potentially surroundings thereof. The environment 100 is provided with a number of alarm devices 101 such as smoke sensors, carbon monoxide sensors, temperature sensors, etc. as mentioned hereinbefore. The sensors 101 may mutually differ and in some cases communicate with each other by relaying alarm information, for example. In the visualized scheme, the smoke or carbon monoxide sensor 101 detects the fire 100a within the monitored space and triggers an audible or inaudible alarm 101b that is captured by a mobile device 102 through a data input entity such as a microphone. Alternatively, the microphone utilized could be exter- nal and e.g. wirelessly coupled to the mobile device 102 optionally through Bluetooth, WLAN or other short-range RF connection. The data input entity may further comprise an A/D (analog-to-digital) converter and optional digital audio encoders). The data ultimately obtained may thus include digitalized audio data in a form of sound samples and/or parameterization(s) representing the sound signal captured by the microphone(s). Additionally, the mobile device 102 could be provided with an explicit request message to alert a remote party by sending an alarm signal.

The mobile device 102 has been preferably provided with software in accordance with the present invention for analyzing the obtained data indicative of environmental sounds 101a in the environment 100. Yet, the mobile device 102 may be provided with a plurality of different sensors such as an accelerometer, illumination sensor, camera, and technology for positioning such as a satellite receiver (e.g. GPS or GLONASS). The sensors may be optionally integrated with the mo- bile device 102.

The mobile device 102 may generally refer to a cellular phone such as a smartphone, a tablet computer, a laptop computer or other portable consumer electronics device, optionally a music or multimedia player such as a device gen- erally considered as 'MP3 player', the most popular example of which at the time of writing this probably being 'Ipod'™ by Apple Inc.™. Alternatively, the mobile device 102 may be particularly designed for monitoring/alarm provision purposes and optionally consist of different attachable modules such as sensor, processing and data transfer modules. The mobile device 102 may be supple- mented with a preferably removably connectable stand, or 'cradle' or 'dock', 103 for providing power and/or to align the device 102 optionally dynamically through remote control as described hereinbefore.

Upon receipt of (sound) data that is identified by the analyzer of the mobile de- vice 102 as an alarm sound, or indicative of alarm sound, based on the alarm repository's indications of alarm sounds, and provided that other optional conditions for providing remote notifications are met, the mobile device transmits an alarm signal 102a, preferably wirelessly, to a number of remote recipients such as a network service, or in hardware terms to a network server, arrangement 108. It is indicated in the figure by the curved arrow and caption 'ALARM' how the arrangement 108 may send the alarm-related notifications forward to users 106 that may include authorities, companies such as security companies or different organizations 106a and private users 106b both alike. The alarm signal 102a and related notifications may be transferred via a number of potentially different transmission paths established by e.g. communication networks 104 such as a cellular network and/or the internet.

In some embodiments, the mobile device 102 may be configured to directly communicate with another near-by mobile device(s), preferably wirelessly, and transmit the alarm signal thereto with reference to a 'walkie-talkie' type use scenario, for example. Yet in some embodiments, the mobile device 102 may be configured to broadcast or multi-cast the alarm signal.

The alarm signal 102a may indicate the alarm sending device (ID), the user associated with the device, location, time, reason (e.g. type of alarm sound detected such as 'smoke alarm'), seriousness (e.g. emergency or non- fatal), and/or further data such as sensor data. E.g. video or still image data and/or a sound clip may be provided. Additionally, a remote party such as network service providing the alarm forward may add to the data originally transmitted by the mobile device 102. In order to consider an environmental sound as an alarm sound or an alarm- triggering sound, the analyzer of the mobile device 102 may apply a number of different procedures as being understood by a skilled person. For instance, FFT or other frequency-domain analysis algorithms may be performed and the signal be divided into frequency bands. Amplitudes and/or amplitude changes in the frequency bands may be then detected and compared to indications of known alarm sounds or alarm-triggering sounds stored in the alarm repository. With good enough match relative to an indicated alarm sound or alarm-triggering sound according to predetermined criterion, the environmental sound may be deemed as an alarm(-triggering) sound.

In many contexts, various alarm sounds have already been more or less exhaustively standardized as to the used frequencies and other parameters, whereupon detecting those from the background noises is fully possible. Further, new alarm sounds could be designed in view of easy automated detection thereof in different conditions. Such predetermined alarm sounds could exhibit a characterizing melody or rhythm to facilitate detection thereof.

Preferably, the users may program or instruct (teach) their mobile devices 102 to recognize new alarm sounds or other alarm- triggering sounds. Optionally a central alarm repository may be maintained by the service operator at the network arrangement 108. The central repository may thus be configured to receive or re- trieve indications of new alarm sounds from the users (user terminals) either automatically or in response to manual update actions triggered by the users.

The network service arrangement 108 may comprise a number of at least functionally connected electronic computer elements such as servers 108a, 108b, 108c, associated memory devices, processing devices, and/or communication devices. Optionally, a cloud computing system may be exploited in realizing at least part of the arrangement 108. Cloud computing environment provides flexible allocation of resources, and thereby scalability, to the arrangement 108. The entities to be notified about the detected alarm may indeed include a number of parties such as a security company, an authority (e.g. police or fire brigade), and/or a number of private users, such as personal contacts or fellow group members of the user primarily associated with the mobile device 102. Naturally the user associated with the mobile device 102 may himself/herself be notified as well e.g. via a web page of the service 108 or of at least functionally connected external service, e-mail or other message accessible/obtainable via other mobile device or terminal device. The arrangement 108 may host the addressing logic and have access to addressing information necessary for channeling the alarms to proper recipients. The notified parties may be associated with different type of terminals such as desktop computers, or similar equipment, 107a and mobile devices 107b.

Alternatively or additionally, the mobile device 102 may be configured to directly address the alarm signals to at least some of the proper final recipients such as a number of top priority recipients (e.g. professional parties like security companies or authorities like police) depending e.g. on the nature of the alarm (fire-> fire brigade, burglary-> police/security company, etc.). Optionally, the mobile device 102 may be configured to receive alarms from other terminal/mobile devices of the same and/or different user(s), optionally via the network service arrangement. Optionally, the user may acknowledge the receipt of the alarm via the UI of the mobile device 102.

Figure lb illustrates one other use scenario of the present invention. The embodiments of the present invention applicable in this particular scenario may generally be, but do not have to be, similar to the ones of Figure la. The following re- marks may thus be applied to the embodiments described relative to Figure la mutatis mutandis and vice versa.

The monitored environment 100b refers in this particular example to the vicinity of the user 102b carrying/having the mobile device 102 in accordance with an embodiment of the present invention with him/her. The mobile device 102 obtains data indicative of environmental sounds via the data input entity thereof. Such data may imply an emergency situation such as a car crash potentially, but not necessarily, involving the user 102b himself/herself. In response to detecting an alarm-sound or alarm-triggering sound 101c utilizing the stored indications, the mobile device 102 may optionally substantially immediately transmit an alarm signal as described hereinbefore. Additionally, a number of other conditions may have to be fulfilled in order to the send the alarm. The conditions for triggering the alarm including e.g. the condition of detecting the alarm sound or alarm-triggering sound 101c may be monitored in parallel and/or sequentially. After noticing a fulfillment of a certain condition, the next condition(s) in line may be monitored e.g. for a predetermined time until the monitoring procedure resets. The monitored conditions and/or monitoring logic, and related alarm triggering, may optionally depend on the active user profile of the mobile device 102. Fulfillment of a certain condition may also alter the detection parameters regarding the other condition(s).

A number of conditions relative to the awareness or generally the presence of the user 102b may be monitored by tracking the usage of the mobile device 102 through the UI, such as touchscreen or keypad, thereof. Activity or passivity of the user 102b may be more specifically monitored by means of sensors such as inertial sensors. Yet, location information obtained from the GPS receiver or via the network signals, for instance, could be applied for determining the location of the device 102 and supposedly of the associated user 102b. The mobile device 102 may be configured to update the location data at the network service arrangement 108 e.g. periodically or upon a location change, or by means of manu- al triggering. Additionally or alternatively, the network service arrangement 108 may be configured to inquire the location of the mobile device 102 either from the mobile device itself or from a third party such as cellular operator. Such inquiries may be timed or otherwise triggered.

In some embodiments, the user 102b may be requested to provide input to the device 102 so that the device 102 may ascertain the presence or health of the user 102b and/or generally the normality of the underlying situation. Such request may be timer-based or triggered in response to detecting an alarm sound or alarm-triggering sound. Alternatively, such request could be triggered in response to not being able to detect sounds that should be present e.g. according to the active user profile, location, calendar information, and/or some other context information. Further, such request could be created based on detecting heavy acceleration potentially indicative of e.g. fall or crash, or based on some other condition mentioned e.g. above. In some embodiments, the display of the device 102 could be configured to visualize the input request to the user 102b. Additionally or alternatively, sound and/or vibration could be applied by the mobile device 102 to get the user's attention. In touchscreen-provided devices an icon of a large button or a corresponding feature may be shown on the display (optionally supplemented with attention-seeking sound), the activation or selection of which is considered as the user acknowledgement whereupon the alarm is not triggered/alarm signal sent and the monitoring may reset. A triggered alarm may be cancelled correspondingly.

On the other hand, the user may also be given a possibility to explicitly acknowledge the real need for alarm via the UI of the mobile device or via an external, functionally connected device such as a wrist-worn panic button/strap. In some embodiments the UI of the mobile device or external device may be provided with dedicated features (buttons, icons, etc.) to either acknowledge the need for the alarm or cancel it. The features may be mutually similar but they may also differ. E.g. the confirmation/triggering feature for the alarm may be bigger in size or otherwise more easily activatable than the cancelling feature, or vice versa. Thus, the alarming may be made a multi-phase procedure and comprise e.g. the local warning (acknowledgement request) phase at the mobile device 102 potentially followed by the alarm triggering/alarm signal sending phase in case no alarm-cancelling further information such as user acknowledgement is captured. Even after transmitting the alarm signal, acknowledgement input may be still provided to cancel the alarm; indication of the cancel event may be transmitted forward to inform the remote party accordingly. In some embodiments, the user may manually trigger the alarm even in the absence of any other alarm-triggering conditions via the UI of the mobile or external device as mentioned above.

If e.g. the active user profile, past sensor data (e.g. location, acceleration, sound data), and/or calendar data indicates the user 10 is practicing sports such as riding a horse or working (e.g. a timber working in the woods with a chainsaw), but the sound data or other sensor data for no obvious reason such as the forthcoming end of the work shift abruptly changes from the predicted values according to predetermined criteria (e.g. chainsaw or riding/horse noise disappears and the movement stops according to accelerometer and/or location data, potentially indicating an accident), an alarm may be triggered and the signal sent. Additional- ly, the aforesaid confirmative input (e.g. 'Please acknowledge that you are unharmed by pressing the red button! ') may be first required. In the lack of such input optionally obtained within a predetermined period, the alarm signal is then sent. In some embodiments, children may be provided with mobile devices 102 that have the monitoring and alarming features described herein. Further, such mobile devices may bear e.g. a locking feature that prevents disabling or changing the monitoring/alarming functionalities. The unlocking may be provided via a code. Figure 2 illustrates a block diagram representing the internals of an embodiment of a mobile device 102 in accordance with the present invention. More from a point of hardware, the mobile 102 may comprise at least one processing device 210 such as a microprocessor, a DSP (digital signal processor), a microcontroller, a programmable logic chip, etc. The processing device 210 may be integrated with or at least functionally connected to a memory element 216 such as a memory chip comprising RAM (random-access memory) and/or ROM (readonly memory) memory for storing instructions and/or other data. A data transfer entity 212 may cover e.g. transceiver(s) such as RF transceiver(s) capable of transferring data between the device 102 and an external entity such as a remote sensor, terminal or network. For instance, operation in a cellular network, WLAN or LAN networking in general, infrared and/or Bluetooth connectivity may be provided. When applicable, dedicated receivers or transmitters may be provided. For positioning, e.g. satellite data receiver such as GPS or GLONASS receivers may be arranged. Further, the data transfer entity 212 typically includes at least one microphone for audio input. Yet, an accelerometer and a number of other sensors may be supplied.

The UI 214 may physically include a number of buttons, knobs, a screen (display), a touchscreen, a touch pad, a keypad, a keyboard, switches, and/or the aforementioned microphone potentially shared with the data transfer entity 212. Also e.g. accelerometer(s) may be applied for acquiring explicit user input in ad- dition to activity sensing. The UI 214 may further refer to the UI of the mobile software 318, which may imply a number of different application views and related sounds, for example, with particular reference to the embodiments shown in Figure 6. The software UI 214 may indicate and preferably enable control over both the status of local monitoring and remote monitoring taking place at remote locations, if any. Yet, the software UI 214 may be utilized to indicate the alarms regarding the other users, such as friends or fellow members of a group in the network service.

The operation of the mobile device 102 to carry out the functionalities described in this text may be thus controlled by software such as monitoring and alarming application 218 comprising instructions stored in the memory 216 and executed by the processing entity 210. The software may be tailored according to the requirements set by the underlying platform, few feasible examples of which being e.g. Symbian™, Windows Phone™, Android™ and iOS™.

The software 218 may be provided as a computer program product in a computer readable storage (carrier) medium such as a memory stick, memory card, optical disc, floppy disc, hard disc, etc. The software 218 may be further delivered over a wired or wireless network.

The mobile device 102 may be powered by a battery, preferably a rechargeable battery such as a rechargeable Li-ion battery. The mobile device 102 may be al- ternatively connected to the mains especially when it is used as a remote location monitoring device and not as a carry-along personal device. The battery may still function as a reserve power source. Optionally, upon detecting a power outage or upcoming battery run-out the mobile device 102 may be configured to transmit a related alarm signal to notify a remote party and/or to trigger a local alarm. The alarm signal may be received by the network service and an indication of the alarm may be forwarded to a number of recipients such as the user(s) associated with the device 102. From a more functional standpoint, the mobile device 102 may contain a data input entity 222, alarm repository 224, analyzer 228, notification entity 226 and context finder 230 in addition to a possible general control entity 220 taking care of data transfer and task synchronization between the other entities, for instance. As already reviewed hereinbefore, the data input entity 222 is configured to obtain data indicative of environmental sounds including actual alarm sounds emitted by alarm devices and other alarm-triggering sounds. The alarm repository 224 contains data for recognizing the predetermined alarm sounds and alarm- triggering sounds. The related indications may be stored as samples, parameters, decoding rules or logic, decoding tables, etc. Preferably the user may dynamically teach the device 102 to recognize sounds, the indications of which are then stored accordingly. For the purpose, the mobile device 102 may contain a teaching entity capable of extracting and/or storing a number of indications describing the (taught) sounds inputted via the data input entity 222. The teaching proce- dure may involve storing the taught sound in sample format, optionally in normalized, filtered and/or otherwise processed form, and/or in parametric form. The parameters utilized as indications may indicate the characteristics like frequency and intensity as mentioned hereinbefore. The analyzer 228 is configured to search matches for the obtained data from the alarm repository 224 according to predetermined criteria that may be user- adjustable in order to detect evidence of alarm sound or alarm-triggering sound in the monitored environment. The analyzer 228 may further apply a plurality of different conditions such as sound detection -related condition and optional context-related condition(s) for triggering an alarm at the mobile device 102 and even utilize a multi-step alarming procedure as reviewed in the description relative to Figure lb.

The notification entity 226 utilizes the available transceiver(s) or transmitter(s) for preferably wirelessly transmitting the alarm signal(s) towards the remote entities such as the network service arrangement. In some occasions such as with basically static mobile device installations, however, also wired communication may be satisfactorily used. Context finder 230 determines on the basis of available data such as location information, mobility information, sound data, calendar information, explicit user input (e.g. profile selection), etc. the context of the mobile device 102 in order to adapt the function of the analyzer 228. Adapting may be performed by refining the conditions monitored for triggering the alarm, for example, as already re- viewed hereinbefore.

Figure 3 is a block diagram representing the internals of an embodiment of a network service arrangement 108 in accordance with the present invention. The arrangement may be realized as a number of at least functionally connected servers 108a, for instance, optionally residing in a cloud computing environment. A data transfer entity 312, optionally a number of transceivers 312 such as Ethernet interfaces, may be provided for communication in the network. Again, processing entity 310 and memory entity 316 as described relative to Figure 2 may be required for processing and storing of instructions and other data in accordance with the present invention. The operation of the arrangement may be arranged via software application 318 containing or defining such instructions. UI 314 such as a (touch) display, a keyboard, and a mouse may provide local control over the arrangement 108 to the administrators thereof. Additionally, by UI 314 it may be referred to a service UI, such as a 'web UP (indicated in the figure via the dotted outline of the UI entity 314), provided to the mobile devices 102 or other terminal devices of remote users typically the internet through exploitation of various visual service views, for example. As mentioned hereinearlier, the UI of the service may also be integrated with other existing network services such as various social networking services via compatible applications, for example.

Logically, the input entity 322 receives the alarm signals transmitted by the mobile devices 102. A user data manager 324 maintains the user data for properly addressing the alarm signals among other potential data. The stored data may include at least one information element or entity selected from the group consisting of: user name, user ID, password, given name, family name, age, sex, date of birth, place of birth, location data, calendar data, message data, indication of ac- tive user profile, a plurality of user profiles, e-mail address, home address, cell phone number, telephone number, user ID or user name in external service, business address, profession, skills, hobbies, alarm history, alarm data, associations with other users such as family associations, friends, contacts, and group memberships. In practice, the data may be split between multiple physical and/or logi- cal repositories such as databases.

A skilled person also realizes that user groups may be generally formed around common employer, club, hobby, other interest, neighborhood, family members, etc. The user may input user data when registering at the service or afterwards. Data may also be collected automatically from a number of sources such as the mobile devices 102. In some embodiments, at least part of the user data may be imported from an external service such as a social networking service via available data import solutions, often APIs (application programming interface) designed for the purpose.

The alarm router 328 is configured to preferably dynamically determine the most appropriate targets of the notifications regarding the received alarm. The private users, authorities, external services and companies whereto the alarms can be conveyed may be all alike initially considered as the users of the service ar- rangement 108 and thus potential recipients of alarms. However, in practical circumstances it is often neither sensible nor efficient to broadcast each alarm to all service users that may not know each other at all, may not belong to the same group, and may even be located in different regions, countries or continents. As discussed hereinbefore, the available location information regarding the service users may be exploited when determining the notification targets of the received alarm signal. According to one embodiment, a predetermined number of (other) users closest to the alarming mobile device 102 may be selected, or all the users within a predetermined distance, or 'radius', from the mobile device 102 may be selected on the basis of the location condition (criterion). Additionally or alternatively, relationship data may be utilized such that only the friends, friends of friends, family members, contacts, fellow group members, and/or authorities may be selected on the basis of relationship condition. A number of different conditions, i.e. criteria, may be thus utilized in parallel and/or sequentially to filter out users from the initial user space.

As an example of one possible outcome of recipient determination, only the users that are somehow associated with the alarming user and also remain within cer- tain, e.g. 10 km, radius from the alarming mobile device according to the latest available location data, are notified about the alarm.

Alerting entity 326 shall construct the alarms and provide them forward and the general control entity 320 may again take care of data transfer and task synchro- nization between the other entities, for instance.

In case the alarm cancelling signal is subsequently received, the notified users may be contacted again and informed about the changed situation. As one option, however not particularly preferred as the sole alarming technique but more as a supplementary one, the alarm and optional subsequent alarm cancellation may be indicated via the network service through a group-related (the member of which the alarming user is) information channel such as group page or group view, e.g. as a group wall post. Alternatively or additionally, the alarm- ing user -related, e.g. publicly or more limitedly accessible, channel such as a user-specific page, profile, or wall, may be provided with a message, or 'post', indicative of the alarm and potential cancellation thereof.

Regarding the explicit notification of the determined other users about the alarm, user-specific information channels, e.g. a service page or wall, could be populated with such notification messages. The channel may be operated by the arrangement 108, or at least the arrangement 108 shall bear capability to provide such notifications to the channel, optionally hosted by an external entity. For example, an external social networking service may be provided with such notifica- tion message considering e.g. tweets in Twitter™ and wall posts in Facebook™ as examples. Suitable APIs and/or applications capable of providing such notifications to external services may be utilized for the purpose. Alternatively or additionally, e-mail notifications may be transmitted. Yet, application-specific notification may be transmitted to the mobile device 102 and mobile software 218 in accordance with the present invention for serving to the re- spective user e.g. audibly and/or visually.

Also textual messages such as SMS or multimedia messages like MMS may be utilized. Even an automated 'robot' call with a dynamically synthetized or prerecorded message may be utilized.

Upon noticing the alarm, the recipient may acknowledge reading it through his/her terminal (acknowledgement may be input via the UI of the terminal such as mobile device or desktop computer), whereupon the terminal may be configured to transmit the related acknowledgement message to the sender of the alarm, e.g. the network service arrangement or the original alarming mobile device, and/or other targets of the alarm such as other group members.

Fig. 4 shows a flow chart 402 of an embodiment of a method in accordance with the present invention.

At 404, the utilized equipment such as an embodiment of the mobile device and optionally other gear such as a number of alarm device(s), external sensor(s), stand, etc. for executing the method is obtained and configured. For instance, the necessary software may be installed at the mobile device and the device may be properly positioned relative to the monitored environment and alarm devices optionally using an alignable, preferably remote-controllable, stand. The user may optionally register at the remote network service and adjust the service settings, if necessary. Further optionally, the user may tailor the uti- lized detection, alarming and potential other parameters preferably through the mobile software to optimize the personal use experience.

At 406, a number of predetermined indications of alarm sounds and/or alarm- triggering sounds are stored for use in connection with alarm sound and/or alarm- triggering sound detection. The indications may be stored in an indication database or some other feasible data structure(s). Item 418 implies the fact that the indications may be updated. Preferably the user may dynamically add new indications, or optionally update the existing ones, by a teaching procedure, for example. New indications or indication updates may be downloaded from external entity such as the network service arrangement. The arrangement may be able to push indications to the mobile device.

Item 408 refers to obtaining data, preferably audio data, indicative of environmental sounds occurring in a monitored environment. As explained herein, e.g. microphone(s) may be utilized to input audio data that is then digitalized and op- tionally parameterized.

At 410, potential alarm sound or an alarm-triggering sound is detected by analyzing the obtained data. The data and/or parameters derived therefrom may be compared to or be otherwise analyzed relative to the indications (or data derived therefrom) in the alarm repository to find a match. Item 420 implies that the analysis is adapted by the determined context information associated with the mobile device, such as location context. The context information may be determined dynamically, optionally periodically, continuously or as triggered by predetermined events, for example.

Item 412 implies that a number of conditions may be applied to determine whether to trigger an alarm and send an alarm signal or not. One obviously applicable criterion is that an alarm sound or alarm-triggering sound has been detected in the obtained data, which is checked at 410. Other potential conditions may in- elude e.g. expiration of intermediate warning phase during which the user may cancel the forthcoming alarm via the UI of the mobile device. Some further conditions may imply detecting various sensor values exceeding or remaining below alarm-triggering threshold values. For instance, accelerometer data and location data may be assessed.

In some embodiments, an alarm may be triggered due to a lack of sound input that should be normally present in the monitored scenario (note e.g. the tim- ber/chainsaw scenario mentioned hereinbefore). The obtained sound data may indicate silence or merely other type of sounds. The associated activity data op- tionally utilized as a further triggering criterion may in those occasions indicate passivity (e.g. no acceleration), for example. Nevertheless, in many scenarios in response to detecting the alarm sound/ alarm- triggering sound or the lack of expected sound, and provided that also the other potential conditions for setting the alarm off have been met, the alarm is triggered at the mobile device, whereupon the alarm signal is sent at 414.

The method execution is ended at 416. The dotted loop-back arrow indicates the potentially repetitive nature of the various method items. The data acquisition, analysis, alarm triggering, etc. may include substantially continuous procedures, periodical procedures, and/or intermittently executed (activated/deactivated) pro- cedures, depending e.g. on the settings of the associated mobile software controlled by the user.

Fig. 5 shows a flow chart 502 of an embodiment of a second method in accordance with the present invention.

At 504, the network service arrangement such as a number of computer servers at least some of which optionally residing in a cloud is configured. For instance, the necessary software may be installed and proper execution parameters set. The necessary network connections are established. The service is ramped up to the level required for servicing the users.

The service begins receiving user registrations and user data 514 either directly or via external services such as various existing social media services. The user data may contain various data elements as reviewed in the description of Figure 3. The user data, associated with 'user accounts', for example, preferably identifies different users of the service and their contact information including e.g. e- mail address and/or address data of terminal devices through which they may be contacted for alarming or other purposes (or through which they may access the service).

Location data regarding the users' locations is preferably obtained 514. Further, relationship data indicative of the associations, such as friendship, professional type relationship, common neighborhood or group membership, between the users, is preferably obtained 516. Various user data may be stored in database(s), such as personal data -comprising and group data -comprising databases, or in other data structures. Items 514, 516 represent preferably dynamically obtainable data and related dynamic actions that may be, in practical circumstances, executed at any stage and basically independently from the more sequential items, which is highlighted in the example of the figure by positioning the items 514,516 aside from the main flow.

At 506, an alarm signal originally sent by a mobile device associated with a certain service user is received. The alarm signal may indicate an alarm sound and/or related emergency situation locally detected by the mobile device. The alarm signal may be embodied as a number of messages following a predetermined messaging scheme.

At 508, the recipients are selected for an indication of the alarm from the user base. It shall be noted that in the context of at least some embodiments of the present invention, a 'user' may refer to organizations, authorities, companies, etc. that may have an account in the service and/or that may be contacted via it, in addition to private users. Instead or in addition to explicitly designating independent users as recipients, formed user group(s) having a number of users as members may be designated, such group(s) optionally having the certain user as a member. Group designation may implicitly designate the individual members thereof as recipients. Alternatively or additionally, designating a group as a receiving user, a common group information channel such as group wall or group page may be provided as alarm indication target. The data previously obtained at 514, 516 is preferably exploited in optimizing the selection of the intended recip- ients.

At 510, the alarm is indicated to the determined service users as recipients.

The method execution is ended at 512. The dotted loop-back arrow indicates the potentially repetitive nature of the method items until the end of execution.

Figure 6 illustrates few exemplary views of the UI of the mobile device in accordance with an embodiment of the present invention. The UI may be at least partially controlled by the mobile software installed at the mobile device. Differ- ent features of various embodiments of the present invention are next reviewed below with reference to the views shown. View 602 may refer to a default 'main screen' type view of the suggested monitoring and alarming software. The monitored environments ('Villa Kirkkonum- mi', 'Cottage Jurva', 'Ice Cream Kiosk') that may be indicated in the view are preferably provided with a mobile device for at least locally obtaining data such as sound data indicative of the environmental sounds such as alarm sounds provided by alarm devices and optionally further data, typically sensor data such as image data, location data and/or accelerometer data.

In addition to the monitored remote environments, the local environment (regard- ing the particular device the UI view of which is shown in the figure) may be monitored and alarms triggered locally via the UI of the mobile device and/or remotely by transmitting alarm signal(s).

Further, in addition to the alarms, the remote mobile or other devices may pro- vide sensor data such as sensor readings or video/static images for output via the UI either directly or via the preferred network service arrangement. Data provision may be periodical or based on event-type triggers such as monitored condition/sensor value (substantial) changes, for example. The user may activate an icon representing any of the monitored environments or users/devices to obtain further information about the environment such as preferably real-time sensor data. The user may even be provided with some control over the remote devices such as the operation parameters of the mobile device and related microphone or camera (to trigger it, for example), and optionally the stand suggested herein. The monitored environments are typically associated with the user of the mobile device. The environments and the monitoring devices located on the spot may be in the user's possession, for example. Further, the environments/monitoring devices may be additionally associated with other users e.g. in the case of a family- or other user group-related environment like a home, a cottage, or e.g. a club house or office. In addition to real estate type environments or vehicles, remote users (i.e. local environment of persons carrying the mobile devices) themselves may be monitored preferably just like the user/mobile device in question by other users. In the illustrated case, the user's wife 'Jenny' is indicated as a monitored target in addition to remote real estate, basically.

Preferably the user may, e.g. via the mobile application and/or the web interface of the network service, allocate different user rights to other users for monitoring the environment of the mobile device(s) associated with him/her. Some basic level of rights may indicate only alarm reception, whereas an elevated level of rights may provide access to the mobile device or to the data provided by the mobile device optionally to the network service arrangement, for monitoring the related conditions even if no alarm has been triggered. For example, close friends or family members may be provided with at least limited access to (the data of) one's personal mobile device carried along. Other contacts defined by the existing relationships preferably maintained at the network service, such as fellow group members or mere acquaintances, may be defined as potential alarm receiv- ers having no access to the data of terminals of the user in question at least in normal, non-alarm, conditions. The basic level of rights indicating at least a right to receive an indication of an alarm set off may be in some embodiments determined as the default level for relationships unless the user specifically alters the rights via the mobile application or e.g. the aforesaid web interface of the net- work service.

If a registered user logs in using a new mobile device, the device may be automatically added to the device list of the user (account). Further, the same mobile device may be associated with a plurality of users/user accounts.

View 604 illustrates indicating the location of a monitored local and/or a number of remote mobile devices (device-carrying users) on a map. The location information may be transferred by or otherwise obtained relative to the devices to enable remote positioning thereof and e.g. the shown kind of positioning on a map display. Preferably each user may enable or disable location tracking by other parties. In some embodiments, different types of tracking rights may be allocated by the users. E.g. certain individually selected contacts, or a certain type or group of contacts, may be provided with location tracking capability. Preferably upon triggering an alarm, each recipient is provided with an indication of the location of the potential emergency or hazard, though. Access to location data and/or sensor data by others may be optionally conveniently controlled by the user through the selection of the active usage profile via the UI of his/her mobile device. Each profile may be associated with a number of characterizing settings regarding the remote access to the location and/or sensor data. View 606 illustrates establishing a new user account at the network service via the terminal UI with various user data fields to fill in regarding the username, password, contact data, etc. View 608 illustrates the monitored devices such as the gas detector and smoke detector (and the local mobile device itself as 'personal alarm'). Preferably the alarm sounds emitted by the detectors are recognized by the near-by mobile device as explained hereinbefore. View 610 shows a number of profile-related, preferably user-adjustable (however merely exemplary) settings such as a number of sensor settings like GPS update interval and camera resolution. Optionally, the user may select the active profile through one simple UI action such as icon selection via a touchscreen or via a press of a physical button.

View 612 depicts an example of a teaching view by which the type of the taught sound/emitting device may be determined e.g. through selection from a number of predetermined options and/or by defining a new type. The taught alarm may be preferably named by the user.

During the teaching procedure, the mobile device may be configured to indicate audibly and/or visually the estimated quality of the input training sound to the user. Visually, the quality may be cleverly indicated via intuitive and informative light codes and symbols. E.g. green light may refer to fully successful or good quality indication obtained, whereas e.g. yellow light and red light may indicate step-wise worsening performance. In the presence of multiple sounds, too loud input causing e.g. distortion, or e.g. high background noise, the utilized recording, learning, and/or feature extraction algorithm(s) for determining the indication of the sound to be learned may not function in optimum sense, which may be detected and briefly indicated to the user so that the user may optionally try teaching again.

View 614 visualizes image data such as video or still image data that the user may receive from a remote monitoring (mobile) device of optionally other user to his/her mobile device. The video data may be utilized to check whether everything looks normal at the remote destination, what is the weather like, etc. Aside with or instead of video or still images, audio data such as an audio clip may be received.

A skilled person may, on the basis of this disclosure and general knowledge, ap- ply the provided teachings in order to implement the scope of the present invention as defined by the appended claims in each particular use case with necessary modifications, deletions, and additions, if any. Different features of the embodiments described hereinbefore may be flexibly utilized and combined to construct new embodiments as understood by the skilled person.