WO2018121862A1

WO2018121862A1 - Method and system for providing a proximity service to a mobile terminal in a smart space

Info

Publication number: WO2018121862A1
Application number: PCT/EP2016/082816
Authority: WO
Inventors: Francesco ARENELLA; Cristina Fra'; Massimo Valla
Original assignee: Telecom Italia SpA
Current assignee: TIM SpA
Priority date: 2016-12-29
Filing date: 2016-12-29
Publication date: 2018-07-05
Anticipated expiration: 2019-06-29

Abstract

It is disclosed a method and system for providing a proximity service to a mobile terminal in a smart space comprising a number of proximity nodes. A proximity server stores information on the proximity nodes, logically organized according to a logical hierarchy based on their influence areas. A client application executed by the mobile terminal monitors proximity events relating to a proximity node. Upon determination of an entering event, the client application determines whether the proximity node for which the entering event has been detected has at least one child proximity node according to the logical hierarchy, by sending a configuration request to the proximity server and receiving therefrom a configuration response. In the affirmative, the client application starts monitoring proximity events relating to the determined child proximity node(s).

Description

METHOD AND SYSTEM FOR PROVIDING A PROXIMITY SERVICE TO A MOBILE TERMINAL IN A SMART SPACE

Technical field

The present invention relates to the field of communication networks. In particular, the present invention relates to a method and system for providing a proximity service to a mobile terminal in a smart space.

Background art

As known, a smart space is an environment (public or private, indoor or outdoor) capable of providing digital services to mobile terminals (typically, smartphones). A smart space typically comprises a number of smart objects, namely devices, actuators, sensors, etc. with which the mobile terminals may interact in order to access the digital services.

WO 2005/066587 describes a system for storing, retrieving and executing jobs relating to the presence of one or more WCIs (wireless communication interfaces) in other computing devices. The system comprises a host system (processor, memory and input/output devices) and at least one WCI. The WCI may comply with one or more of the variety of network protocols, such as IEEE 802.1 1 b, IEEE 802.1 1 a, Bluetooth, CDMA, GSM, GPRS, RFID, etc. Different wireless communication protocols have different operation ranges. To request a job to be executed under certain condition, the user provides a job specification including what to do and when to do, namely the job trigger condition. The job trigger condition may be a proximity trigger condition. A proximity trigger condition is the presence rule of one or more WCIs of other computing devices, which includes two states, "present" or "absent". The system comprises a scheduler (software) which periodically polls the WCI to receive frames from which identifiers of WCIs of other computing devices are detected, and evaluates the trigger conditions. For retrieving frames allowing detection of the trigger identifiers, the WCI periodically scans the communication channels. If the system comprises multiple WCIs in different communication protocols having different operation ranges, the operation range of each WCI is used to determine the scanning frequency of that WCI. To further reduce the power consumption, a shorter range WCI might enter a power saving mode and wakes up when a longer range WCI detects a trigger condition. For example, the system may be a mobile phone with two WCIs, a GSM WCI and an IEEE 802.1 1 b WCI. A trigger condition given by the user is "in proximity of A and B", where A is the identifier of a GSM base station and B is the identifier of a nearby IEEE 802.1 1 b AP. Since GSM WCI has a longer operation range than IEEE 802.1 1 b WCI, the IEEE 802.1 1 b WCI enters a power saving mode while the GSM WCI does the scanning twice a minute. When the GSM WCI detects A, the system wakes up the IEEE 802.1 1 b WCI that starts scanning the communication channel 30 times per minute for detecting B.

Summary of the invention

The Applicant has noticed that the system described by WO 2005/066587exhibits some drawbacks.

In particular, the Applicant has noticed that according to WO 2005/066587, it is the user herself/himself who provides to the host system the trigger conditions for executing the jobs. The trigger conditions are therefore locally stored by the host system. The trigger conditions however depend not only on the user's needs, but also on the arrangement and configuration of the WCIs. The WCIs may indeed be displaced or removed, so that the trigger conditions stored at the host system may become outdated. New WCIs may also be added. Such changes in the configuration of the WCIs may require a change or update of the trigger conditions. WO 2005/066587 however disadvantageously does not provide any mechanism allowing an update (possibly, an automatic update) of the trigger conditions stored at the host system, so as to reflect possible changes in the configuration of the WCIs.

In view of the above, it is an object of the present invention to provide a method and a system for providing a proximity service to a mobile terminal in a smart space which overcomes the aforesaid drawbacks.

In the present description and in the claims, the expression "proximity service" will designate a digital service provided to a mobile terminal located within a smart space, whose provision is triggered by the mobile terminal determining a proximity event relating to a proximity node of the smart space.

Moreover, in the present description and in the claims the expression "proximity node" will designate an object or device for which proximity events are determinable by the mobile terminal. For instance, a proximity node may be defined by its GPS coordinates, proximity events being determinable by the GPS sensor of a mobile terminal; or a wireless device (GSM/GPRS, UMTS, LTE/LTE- Advanced, 5G, RFID, Wi-Fi, Bluetooth) for which proximity events are determinable by a corresponding wireless sensor of a mobile terminal; or multimedia object (e.g. an image such as a QR code, or a soundtrack) for which proximity events are determinable by the camera or microphone of a mobile terminal; and so on.

Moreover, in the present description and in the claims, the expression "proximity event" determinable by a mobile terminal for a proximity node will designate one of the following events (i) mobile terminal entering an influence area of the proximity node or (ii) mobile terminal exiting the influence area of the proximity node, wherein "proximity area" is an area surrounding the proximity node and having a certain extent that depends on the technology upon which the proximity node is based. For instance, GPS allows providing proximity nodes with influence areas with potentially unlimited extent; wireless technologies (such as GSM/GPRS, UMTS, LTE/LTE-Advanced, 5G, RFID, Wi-Fi, Bluetooth, etc.) allow providing proximity nodes with influence areas whose extent is limited by their ranges; and recognition of multimedia objects (image or soundtrack) allows providing proximity nodes with very small influence areas defined by the capability of clearly recognizing the multimedia object. In particular, it is an object of the present invention to provide a method and a system for providing a proximity service to a mobile terminal in a smart space which - upon a change in the configuration of the smart space and its proximity nodes - enables an automatic update of the information on the proximity nodes stored at the mobile terminal, based on which the mobile terminal determines possible proximity events that could trigger provision of the proximity service. According to embodiments of the present invention, the above problems are solved by a method and a system for providing a proximity service to a mobile terminal in a smart space comprising a number of proximity nodes, wherein a proximity server stores information on the proximity nodes, that are logically organized according to a logical hierarchy based on their influence areas. A client application executed by the mobile terminal monitors proximity events relating to one of the proximity nodes of the smart space. Upon determination of an entering event relating to this proximity node, the client application determines whether this proximity node has any child proximity node according to the logical hierarchy, by sending a configuration request to the proximity server and receiving therefrom a configuration response. In the affirmative, the client application starts monitoring proximity events relating to the child proximity node(s).

Advantageously, the information on the proximity nodes - hierarchically organized based on the influence areas of the proximity nodes - are stored at the proximity server and downloaded by the mobile terminal step-by-step, starting first from the upper hierarchical layer and passing then to the lower hierarchical layer only if an entering event relating to a proximity node of the upper hierarchical layer is determined.

In this way, the mobile terminal locally stores only the information strictly needed to monitor proximity events relating to proximity nodes of the relevant hierarchical layer.

Moreover, in case a change in the configuration of the proximity nodes occurs (e.g. as decided by the owner of the smart space), the information on the proximity nodes as stored at the proximity server are centrally updated and then distributed to each mobile terminal entering the smart space. In this way, the information allowing each mobile terminal to determine proximity events are advantageously always updated.

According to a first aspect, the present invention provides a method for providing a proximity service to a mobile terminal in a smart space comprising a number of proximity nodes, the method comprising:

a) at a proximity server, storing information on said proximity nodes (21 -27), said information being logically organized according to a logical hierarchy based on influence areas of said proximity nodes (21 -27);

b) at said mobile terminal:

• monitoring proximity events relating to a proximity node of said number of proximity nodes;

• upon determination of an entering event relating to this proximity node, determining whether this proximity node has at least one child proximity node according to the logical hierarchy stored by the proximity server, by sending a configuration request to the proximity server and receiving therefrom a configuration response; and • in the affirmative, monitoring proximity events relating to the at least one child proximity node.

Preferably, the proximity service is provided to the mobile terminal upon determination of an entering event relating to the at least one child proximity node.

Preferably, the method further comprises, upon determination of an exiting event relating to the at least one child proximity node, continuing monitoring proximity events relating to the proximity node and the at least one child proximity node.

Preferably, the method further comprises, upon determination of an exiting event relating to the proximity node, stopping monitoring proximity events relating to the at least one child proximity node. Preferably, at step b) the configuration response comprises information allowing the mobile terminal determining a sensor of the mobile terminal to be activated for receiving context data to be used for monitoring proximity events relating to the at least one child proximity node.

According to an advantageous variant, at step b) the mobile terminal also deactivates a further sensor of said mobile terminal providing context data for monitoring proximity events relating to a further proximity node which, according to the logical hierarchy stored by the proximity server, is the parent of said proximity node. Preferably, at step b) monitoring proximity events relating to the at least one child proximity node is also based on a set of local attributes.

According to preferred embodiments, the set of local attributes comprises:

- a first local attribute indicating whether the mobile terminal is currently within the influence area of the at least one child proximity node or outside the influence area of the at least one child proximity node;

a second local attribute indicating a number of consecutive detections of a proximity event relating to the at least one child proximity node that are required to determine a proximity event; and a third local attribute indicating the number of already determined proximity events relating to the at least one child proximity node.

Preferably, at step b) monitoring proximity events relating to the at least one child proximity node comprises calculating a current distance between the mobile terminal and the at least one child proximity node.

Preferably, at step b) monitoring proximity events relating to the at least one child proximity node comprises comparing the calculated current distance with a maximum distance specified in the configuration response and:

(i) if the mobile terminal was previously outside the influence area and the calculated distance is shorter than or equal the maximum distance, detecting an entering event; or

(ii) if the mobile terminal was previously within the influence area and the calculated distance is longer than the maximum distance, detecting an exiting event.

Alternatively, at step b) monitoring proximity events relating to the at least one child proximity node comprises comparing a video or audio stream provided by a multimedia sensor of the mobile terminal with the reference image or soundtrack stored in the configuration response, and:

(i) if the mobile terminal was previously outside the influence area and the reference image is recognized in the video or audio stream, detecting an entering event; or

(ii) if the mobile terminal was previously within the influence area and the reference image is not recognized in the video or audio stream, detecting an exiting event.

Preferably, an entering event relating to the at least one child proximity node is determined if the entering event has been detected for a minimum number of consecutive times, and an exiting event relating to the at least one child proximity node is determined if the exiting event has been detected for a minimum number of consecutive times, the minimum number being specified in the configuration response.

Preferably, an entering event relating to the at least one child proximity node is determined if the mobile terminal has to monitor proximity events of the type "entering", and an exiting event relating to the at least one child proximity node is determined if the mobile terminal has to monitor proximity events of the type "exiting", an indication of whether the mobile terminal has to monitor proximity events of the type "entering" and/or "exiting" being comprised in the configuration response.

Preferably, an entering event relating to the at least one child proximity node is determined if the number of already determined entering events is lower than a maximum number of entering events that may be notified to the mobile terminal and an exiting event relating to the at least one child proximity node is determined if the number of already determined exiting events is lower than a maximum number of exiting events that may be notified to the mobile terminal, the maximum number being specified in the configuration response.

According to a second aspect, the present invention provides a system for providing a proximity service to a mobile terminal in a smart space comprising a number of proximity nodes, the system comprising:

a proximity server storing information on the proximity nodes, the information being logically organized according to a logical hierarchy based on influence areas of the proximity nodes; and a client application to be executed by said mobile terminal, the client application being configured to:

• monitor proximity events relating to a proximity node of said number of proximity nodes;

• upon determination of an entering event relating to this proximity node, determine whether the proximity node has at least one child proximity node according to the logical hierarchy stored by the proximity server, by sending a configuration request to said proximity server and receiving therefrom a configuration response; and

• in the affirmative, monitoring proximity events relating to said at least one child proximity node.

According to a third aspect, the present invention provides a computer program product loadable in the memory of at least one computer and including software code portions for performing the steps of the method as set forth above, when the product is run on at least one computer.

Brief description of the drawings

The present invention will become clearer from the following detailed description, given by way of example and not of limitation, to be read with reference to the accompanying drawings, wherein:

- Figure 1 schematically shows a system for providing a proximity service to a mobile terminal in a smart space, according to embodiments of the present invention;

- Figure 2 shows an exemplary tree graph representing the hierarchical organization of the proximity nodes shown in Figure 1 ;

- Figure 3 is a flow chart of the method for providing a proximity service, according to embodiments of the present invention; - Figure 4 is a more detailed flow chart of the proximity event determination step of the flow chart of Figure 3; and

- Figures 5, 6 and 7 are even more detailed flow charts of three steps of the flow chart of Figure 3. Detailed description of preferred embodiments of the invention

Figure 1 schematically shows a system for providing a proximity service to a mobile terminal (indicated with the reference number 1 in Figure 1 ) in a smart space (indicated with the reference number 2), according to embodiments of the present invention.

The mobile terminal 1 may be for instance a smartphone, a tablet, a smart head-mounted device (e.g. with the screen in the shape of a pair of eyeglasses), or any other kind of portable computing device.

The mobile terminal 1 preferably comprises a number of (three, by way of non limiting example) sensors 1 1 , 1 2, 13.

The sensors 1 1 , 1 2, 1 3 are preferably capable of providing context data indicative of the position of the mobile terminal 1 within the smart space 2, as it will be described in detail herein after. Sensor 1 1 , 12, 13 of the mobile terminal 1 may be e.g. a sensor based on GPS or any known radio communication technology (e.g. GSM/GPRS, UMTS, LTE/LTE- Advanced, 5G, RFID, Wi-Fi, Bluetooth, etc.). Alternatively, sensor 1 1 , 12, 13 of the mobile terminal 1 may be a multimedia sensor, such as a camera capable of capturing images from the environment surrounding the mobile terminal 1 or a microphone capable of capturing sounds (e.g. ultrasounds) in the environment surrounding the mobile terminal 1 . According to a preferred embodiment, the mobile terminal 1 comprises sensors of different types. For instance, by way of non limiting example, sensor 1 1 may be a GPS sensor, sensor 12 may be a Bluetooth sensor and sensor 13 may be the camera of the mobile terminal 1 . The smart space 2 preferably is a public or private, indoor or outdoor environment (e.g. a shopping mall) comprising a number of (seven, by way of non limiting example) proximity nodes 21 -27.

In the present description and in the claims, the expression "proximity node" will designate an object or device whose proximity is detectable by at least one sensor of the mobile terminal 1 . Proximity node 21 -27 of the smart space 2 may be a device based on GPS or any known radio communication technology (e.g. 2G, 3G, Long Term Evolution (LTE)/ Long Term Evolution - Advanced (LTE-A), 5G , RFID, Wi-Fi, Bluetooth, etc.). Alternatively, proximity node 21 -27 of the smart space 2 may be a multimedia object, such as an image (e.g. a picture, a barcode, a QR code, etc.) which can be captured by a camera of the mobile terminal 1 , or a soundtrack which can be captured by a microphone of the mobile terminal 1 .

According to a preferred embodiment, the smart space 2 comprises proximity nodes of different types. For instance, by way of non limiting example, proximity node 21 may be based on GPS (namely, it is defined by the geographic coordinates of the smart space 2), proximity nodes 22 and 23 may be based on Bluetooth (namely, they may be Bluetooth devices placed at different locations in the smart space 2) and proximity nodes 24-27 may be multimedia objects (e.g. images such as QR codes placed at different locations in the smart space 2).

According to embodiments of the present invention, the system 3 for providing a proximity service to the mobile terminal 1 in the smart space 2 preferably comprises a client application 4 executed by the mobile terminal 1 , a communication network 5 and a proximity server 6 configured to cooperate with the client application 4 via the communication network 5.

The client application 4 preferably comprises a proximity manager 41 and a sensor manager 42. The sensor manager 42 is preferably configured to cooperate with sensors 1 1 , 12, 13 of the mobile terminal 1 for the purpose of gathering therefrom context data allowing detection of proximity events relating to the proximity nodes 21 -27 of the smart space 2, as it will be described in detail herein after.

The proximity manager 41 is in turn configured to cooperate with the sensor manager 42 for receiving the context data and to process them for detecting proximity events, as it will be described in detail herein after. Further, the proximity manager 41 is preferably configured to cooperate with the proximity server 6 via the communication network 5 for exchanging configuration requests and configuration responses, as it will be described in detail herein after.

The client application 4 is preferably developed as a software library, which may be implemented either within a mobile application developed by the owner of the smart space 2 (herein after also termed "space owner") or by other parties (e.g. the service provider).

The communication network 5 may be either a public communication network (e.g. public Internet) or a private communication network, and it may be based on any known network protocol (e.g. Internet).

The proximity server 6 preferably comprises a proximity server API (Application Programming Interface) 61 and a node database 62. The node database 62 preferably stores node configurations, as it will be described in detail herein after. The proximity server API 61 is preferably configured to interact with both the node database 62 and the proximity manager 41 for the purpose of reading node configurations from the node database 62 and providing them to the proximity manager 41 via the communication network 5, as it will be described in detail herein after.

The proximity server 6 may be implemented as a stand-alone machine connected to the communication network 5. More preferably, the proximity server 6 is implemented in the communication network 5 using a cloud computing technique.

The system 3 also preferably comprises a computer 7 configured to cooperate with the proximity server 6 via the communication network 5. The computer 7 is preferably provided with a user interface allowing a node configurer (e.g. a space owner) to write node configurations, as it will be described in detail herein after. On the other hand, the proximity server API 61 is preferably configured to interact with the computer 7 for the purpose of receiving node configurations therefrom and writing them in the node database 62, as it will be described in detail herein after.

According to embodiments of the present invention, from the logical point of view the proximity nodes 21 -27 of the smart space 2 are preferably hierarchically organized, the hierarchical organization of the proximity nodes indicating the order in which proximity events relating thereto shall be detected by the proximity manager 41 executed by the mobile terminal 1 .

Preferably, the hierarchical organization of the proximity nodes reflects their geographical hierarchy.

In particular, each proximity node 21 -27 of the smart space 2 preferably has associated a respective influence area, upon which the concept of "proximity event" is based. In particular, in the present description and in the claims, the expression "proximity event" relating to a proximity node will designate either the mobile terminal 1 entering the influence area of that proximity node ("entering event") or the mobile terminal 1 exiting the influence area of that proximity node ("exiting event").

The proximity area of a proximity node has an extent that may be set by the space owner according to its needs and whose maximum value depends on the technology upon which the proximity node is based. For instance, GPS allows providing proximity nodes with influence areas with potentially unlimited extent; wireless technologies (such as GSM/GPRS, UMTS, LTE/LTe- Advanced, RFID, Wi-Fi, Bluetooth, etc.) allow providing proximity nodes with influence areas whose extent is limited by their ranges; and recognition of multimedia objects (image or soundtrack) allows providing proximity nodes with very small influence areas defined by the capability of clearly recognizing the multimedia object.

The influence area of a proximity node with larger extent may include one or more influence area(s) of one or more proximity nodes with smaller extent.

For instance, with reference to the above exemplary nodes 21 -27, proximity node 21 based on GPS may have a large influence area (1 km or so on) defining the outer boundary of the smart space 2, e.g. including a whole shopping mall.

Besides that, proximity nodes 22 and 23 based on Bluetooth may be provided with smaller influence areas comprised in the influence area of proximity node 21 , which may correspond to separate areas of the smart space 2, e.g. two different shops A and B of the shopping mall.

Finally, proximity nodes 24-27, which are multimedia objects, may have associated still smaller influence areas comprised in the influence areas of proximity nodes 22 and 23. For instance, influence areas of nodes 24, 25 may correspond to different counters of shop A, whereas influence areas of nodes 26, 27 may correspond to different counters of shop B.

As mentioned above, the hierarchical organization of the proximity nodes reflects their geographical hierarchy. In particular, the proximity nodes are preferably logically arranged according to a tree graph having N layers, wherein a proximity node of the n^th layer and having a certain influence area is the parent of one or more proximity nodes of the (n+1 )^th layer having smaller influence areas comprised in its influence area.

Figure 2 shows a N=3 layer tree graph referring to the exemplary proximity nodes 21 -27. Proximity node 21 , having the largest influence area, is the root node of the tree graph (layer n=1 ) and is parent of the proximity nodes 22 and 23 (layer n=2). The proximity node 22 is in turn parent of proximity nodes 24 and 25 (layer n=3), while the proximity node 23 is parent of the proximity nodes 26 and 27 (layer n=3).

The hierarchical organization of the proximity nodes 21 -27 of the smart space 2 is preferably stored within the node database 62 of the proximity server 6.

In particular, for each proximity node 21 -27 of the smart space 2, the node database 62 preferably stores a respective node configuration. A node configuration preferably is a set of attributes describing the proximity node so as to allow detection of proximity events relating thereto and determination of its relationship with other proximity nodes within the hierarchical organization.

In particular, a node configuration of a proximity node preferably comprises one or more of the following attributes:

· attribute "id": it comprises both the node type (GPS, GSM/GPRS, UMTS, LTE/LTE Advanced, 5G, RFID, Wi-Fi, Bluetooth, image, audio, etc.) and a node name uniquely identifying the proximity node ("node_id");

• attribute "label": it comprises a logical name assigned to the proximity node and may comprise additional information on the node

(e.g. id of the radio interface, URI of the multimedia content, etc.);

• attribute " accuracy": it comprises information defining the influence area of the proximity node. The content of the attribute "accuracy" depends on the node type. For GPS proximity nodes and wireless proximity nodes (GSM/GPRS, UMTS, LTE/LTE Advanced, 5G, RFID, Wi-Fi, Bluetooth, etc.), the attribute "accuracy" preferably comprises a numerical value indicating the maximum distance between the mobile terminal 1 and the location of the proximity node, within which the mobile terminal 1 is to be considered within the influence area of the proximity node. For multimedia proximity nodes, the attribute "accuracy" is not set, since the influence area of a multimedia proximity node is defined by the capability of clearly recognizing the multimedia object;

• attribute "point ": it comprises information indicative of the location of the proximity node (where applicable). For instance, for a GPS proximity node the attribute "point " comprises its geographic coordinates in terms of latitude and longitude. On the other hand, for proximity nodes located in circumscribed spaces, the attribute "point" may comprise their Cartesian coordinates within such space;

· attribute "detect ion": it comprises a value indicative of the number of consecutive times the proximity manager 41 shall detect a proximity event (e.g. an entering event) before determining its occurrence. The higher the number of consecutive detections, the higher the certainty degree of the proximity event determination. On the other hand, the lower the number of consecutive detections, the higher the speed of the proximity event determination. The value of the attribute "det ect ion" may accordingly be set according to whether the determination of a proximity event shall be faster or more certain. For instance, a faster determination of a proximity event is preferred if the aim of the smart space 2 is catching the attention of a large number of visitors in a certain shop counter, e.g. by providing special offers. On the other hand, a more certain determination of a proximity event is preferred if the aim of the smart space 2 is e.g. switching on/off a certain user appliance when the user enters/exits a certain room of its house. According to an advantageous variant, the attribute "detect ion" may assume three different textual values (e.g. "SLOW", "MEDIUM" and "FAST");

• attribute "event ": it comprises the type of proximity event (namely, entering event and/or exiting event), relating to that proximity node, which the mobile terminal 1 has to monitor. The attribute "event " may preferably assume three predefined textual values, namely "IN" (entering events), "OUT" (exiting events) or "IN/OUT" (both entering events and exiting events");

• attribute "f requency": it comprises the number of times the mobile terminal 1 shall be notified of the determination of a proximity event relating to the proximity node. According to advantageous variants, the attribute "frequency" may assume a number of predefined textual values, for instance: "ONCE" (the mobile terminal 1 shall be notified only once, namely the first time a proximity event is determined), "ONCE PER EVENT" (when the proximity event types shall be notified to the mobile terminal 1 , the mobile terminal 1 shall be notified once per event type), "ALWAYS" (the mobile terminal 1 shall be always notified each time a proximity event is determined), "X" (the mobile terminal 1 shall be notified no more than X times, where X is settable to any integer number);

· attribute "des cript ion", comprising a textual description of the proximity node; and

• attribute "node s ", comprising an array of node configurations relating to child nodes of the proximity node in the logical hierarchy. The node configuration of each child node is as described below. For leaf nodes (namely, nodes having no child nodes, such as for instance the proximity nodes 24-27), the attribute "node s " is empty.

Exemplary node configurations of the proximity nodes 21 -27 are set forth herein below. The node configurations herein below are, by way of non limiting example, in a JSON (JavaScript Object Notation) format. For clarity and conciseness, the detailed node configuration is set forth only some of the proximity nodes 21 -27: { (proximity node 21 )

id": "GPS I shopping_mall_district " , accuracy" : 100 ,

detection": "FAST",

event": "IN",

frequency": "ALWAYS",

description": "district",

label": "JOL S-Cube district", point " : {

"latitude": 45.23,

"longitude": 9.45 nodes": [ { (proximity node 22)

"id": "bt|shop_A",

"accuracy" : 5,

"detection": "MEDIUM",

"event": "IN/OUT",

"frequency" : "ONCE_PER_EVENT" ,

"type " : " shop" ,

"label" : "11:22:33:44:55:66",

"nodes": [ { (proximity node 24)

"id" : "img I shopping_mall_poster "accuracy": "N/A",

"detection": "SLOW",

"event": "IN",

"frequency": "ALWAYS", "description": "poster", "label" : "URKshopping_mall_logo

^},

{ (proximity node 25)

}]

{ (proximity node 23)

id" : " bt I shop_B ",

accuracy" : " 10 " ,

detection": "FAST",

event": "IN/OUT",

frequency": "ONCE",

description": "shop",

label": "66:22:44:33:55:11",

nodes": [ { ( (proximity node 26)

"id" : "img I shopping_mall_poster

"accuracy": "N/A",

"detection": "SLOW", "event": "IN",

"frequency": "ALWAYS",

"type": "poster",

"label" : "URI<shopping_mall_logo> "

(proximity node 27)

The node configurations of the proximity nodes 21 -27 may be decided and written by a node configurer, who may be e.g. the owner of the smart space 2. The node configurer may write the node configurations by means of the computer 7 connected to the proximity server API 61 of the proximity server 6, which stores them in the node database 62.

The node configurer in particular may firstly add the root node (layer n=1 ) of the hierarchy by sending its node configuration to the proximity server API 61 e.g. via an HTTP POST request addressed to the URL http://<base_url>/nodes, having in its body the node configuration as set forth above. The proximity server API 61 then writes the received node configuration in the node database 62 by means of a "write" operation.

Then, the node configurer may add the other proximity nodes of the hierarchy. To this purpose, the node configurer preferably adds each child node in cascade to its parent node. The addition of a proximity node of layer n+1 , child of a parent node of layer n, may be performed by appending to the base URL the path from the root (layer n=1 ) to the parent node (layer n>1 ). By assuming that the proximity node with "id" attribute equal to "node_id_ (n+i) " needs to be defined as a child of node having "id" attribute equal to "node_id_n", then the space owner may send to the proximity server API 61 an HTTP POST request with the node configuration of the node "node_id_n" in its body. If the path from the root "node_id_1 " to the node "node_id_n" is known, the URL becomes as follows:

http://<base_url>/nodes/<node_id_1 >/.../"node_id_n".

In this way, the proximity server API 61 updates the node configuration of the node "node_id_n" in the node database 62 by inserting the node "node_id_ ( n+i ) " in its "node s " array.

If the node configurer wishes to delete from the node database 62 one or more proximity nodes of the smart space 2, it may send by means of the computer 7 an HTTP DELETE request to the proximity server API 61 , to the URL including the "id" attribute of the proximity node to be deleted. If such proximity node is the parent of one or more other proximity nodes, also the latter will be cancelled from the node database 62.

After a request for adding a proximity node or a request for deleting it has been received and executed by the proximity server API 61 , the proximity server API 61 preferably sends to the computer 7 an acknowledge message if the adding or deleting operation was successful, or an error message if the adding or deleting operation was not successful.

According to embodiments of the present invention, the client application 4 of the mobile terminal 1 preferably interacts with the proximity server 6 in order to gain access to a proximity service offered by the smart space 2, as it will be described in detail herein after with reference to the flow chart of Figure 3.

When the user intends to go to the smart space 2 (e.g. the shopping mall mentioned above), it preferably starts on the mobile terminal 1 the client application 4, whose proximity manager 41 sends to the proximity server API 61 a configuration request for receiving therefrom node configurations relating to possible proximity nodes belonging to the layer n^th, which are child nodes of a node of layer (n-1 ) for which an entering event has been detected (step 300).

Specifically, at the first iteration of step 300, the proximity manager 41 preferably assumes that an entering event relating to a virtual node of a virtual layer n=0, whose child nodes are all the proximity node(s) of layer n=1 , has already been detected. Hence, at the first iteration of step 300 the configuration request preferably relates to the proximity node(s) of layer n=1 of the tree graph. For instance, the configuration request may be in the form of an HTTP GET request addressed to the URL http://<base_url>/nodes.

In response to the configuration request, the proximity server API 61 preferably retrieves from the node database 62 the node configurations of all the nodes belonging to the layer n^th , if any, which are child nodes of the node of layer (n-1 )^th for which the entering event has been detected (step 301 ) and sends them to the proximity manager 41 in the form of a configuration response (step 302).

Hence, with reference to the exemplary tree graph shown in Figure 2, the first iteration of steps 301 and 302 results in the proximity server API 61 retrieving and sending to the proximity manager 41 the node configuration of the proximity node 21 .

Upon reception of the configuration response, the proximity manager 41 checks its content for determining whether it comprises the node configuration(s) of proximity node(s) belonging to the layer n^th, which are child nodes of the node of layer (n-1 )^th for which an entering event has been detected (step 306).

If the configuration response is such that no child node(s) exists of the node for which a proximity event was detected, the proximity manager 41 preferably triggers provision of the proximity service associated with the proximity node with no child nodes for which the last entering event has been determined (step 307), as further described in the following.

If instead the configuration response is such that at least one child node exists of the node for which a proximity event was detected, the proximity manager 41 preferably identifies the sensor(s) of the mobile terminal 1 (if any) which shall be activated for gathering context data indicative of possible proximity events relating to the proximity node(s) of layer n=1 (step 303).

For this purpose, for each one of such proximity nodes of layer n=1 , the proximity manager 41 preferably locally stores (e.g. in the memory of the mobile terminal 1 ) its received node configuration, and then reads the attribute "id" of this node configuration (that, as described above, comprises both the node type and the node name). For instance, with reference to the exemplary hierarchy shown in Figure 2, since at the first iteration of steps 300-302 only the node configuration of the proximity node 21 is received at the proximity manager, whose attribute " id" is equal to "GP S I shopping_maii_di st rict " , at step 303 the proximity manager 41 identifies only the GPS sensor 1 1 of the mobile terminal 1 as a sensor to be activated.

Then, at step 303 the proximity manager 41 preferably checks whether the identified sensor(s) is/are already active and, in the negative, asks the user of the mobile terminal 1 (e.g. via a text message in the display of the mobile terminal 1 ) to activate it/them. Moreover, at step 303 the proximity manager 41 preferably initializes a set of local attributes.

The local attributes initialized by the proximity manager 41 for each proximity node of layer n=1 at the first iteration of step 303 preferably comprise:

• local attribute "status ": it describes the current position of the mobile terminal 1 relative to the influence area of the proximity node. Preferably, the local attribute "status " may assume two different values, e.g. "IN" (indicating that the mobile terminal 1 is within the influence area of the proximity node) and "OUT" (indicating that the mobile terminal 1 is outside the influence area of the proximity node). This local attribute is preferably initialized to the value "OUT";

· local attribute "event_conf irmat ion": it indicates the number of consecutive detections of an entering event, or an exiting event, relating to the proximity node that are needed to trigger determination of the entering event, or of the exiting event, respectively. Such local attribute is preferably initialized to the value 0; and

• local attributes "entering_counter" and

"exit ing_counte r": they indicate the number of already determined entering events and the number of already determined exiting events for that proximity node, respectively. Such local attributes are preferably initialized to the value 0.

Then, the sensor manager 42 starts providing to the proximity manager 41 the context data gathered by the activated sensor(s) (step 304).

Preferably, at step 304 the sensor manager 42 periodically provides an update of the context data gathered by the activated sensor(s). The period for providing such updates preferably ranges from 100 ms to 1 s, depending on the sensor type.

The context data type depends on the activated sensor type, which in turn depends on the proximity node type. For instance, in case of GPS sensor, the context data comprise the current position (in terms of geographic coordinates) of the mobile terminal 1 . In case of wireless sensors (GSM/GPRS, UMTS, LTE/LTE-advanced, 5G, RFID, Wi-Fi, Bluetooth, etc.), the context data comprise received power and identifier of each wireless network or device detected within the sensor range. In case of multimedia sensors (camera, microphone, etc.), the context data preferably comprise the video or audio stream captured by the sensor.

While the proximity manager 41 is receiving the updates of the context data, it preferably uses them to determine proximity events relating to each one of the proximity node(s) of layer n=1 (step 305). The determination of proximity events relating to a certain proximity node at step 305 is preferably based on the context data provide by the activated sensor(s), the values of the attributes of the node configuration as retrieved in the node database 62 and the values of the local attributes as set by the proximity manager 41 , as it will be described in detail herein after.

When, at the first iteration of step 305, the proximity manager 41 determines a proximity event relating to a proximity node of layer n=1 , it preferably performs an action as a consequence of the determination.

In particular, if an entering event relating to a certain proximity node of layer n=1 has been determined, the proximity manager 41 preferably reverts to step 300, namely it sends a configuration request to the proximity server 6 for receiving therefrom node configurations relating to possible proximity nodes belonging to the layer n=2, which are child nodes of the node of layer n=1 for which the entering event has been determined.

In response to the configuration request, the proximity server API 61 preferably retrieves from the node database 62 the node configurations of the nodes belonging to the layer n=2, if any, which are child nodes of the node of layer n=1 for which the entering event has been determined (step 301 ) and sends them to the proximity manager 41 in the form of a configuration response (step 302).

Hence, with reference to the exemplary tree graph shown in Figure 2, if an entering event is determined for the proximity node 21 , the second iteration of steps 301 and 302 results in the proximity server API 61 retrieving and sending to the proximity manager 41 the node configurations of the proximity nodes 22 and 23 of layer n=2, namely the child nodes of the proximity node 21 .

Upon reception of the configuration response, the proximity manager 41 preferably checks its content for determining whether it comprises the node configuration(s) of proximity node(s) belonging to the layer n=2 which are child nodes of the node of layer n=1 for which the entering event has been detected (step 306).

In the affirmative, the proximity manager 41 preferably identifies the sensor(s) of the mobile terminal 1 (if any) which shall be activated for gathering context data indicative of possible proximity events relating to the child proximity node(s) of layer n=2 (step 303). For instance, with reference to the exemplary hierarchy shown in Figure 2, since at the second iteration of steps 300-302 the node configurations of the proximity nodes 22 and 23 are received at the proximity manager 41 , which are both Bluetooth devices, at step 303 the proximity manager 41 identifies also the Bluetooth sensor 12 of the mobile terminal 1 as a sensor to be activated.

Then, at the second iteration of step 303 the proximity manager 41 preferably checks whether the identified sensor(s) is/are already active and, in the negative, asks the user of the mobile terminal 1 (e.g. via a text message in the display of the mobile terminal 1 ) to activate it/them.

At the second iteration of step 303 the proximity manager 41 also initializes a set of local attributes for each child node of layer n=2, as described above.

While the proximity manager 41 is receiving the context data, it preferably repeats the above described step 305 to determine possible proximity events for the proximity node of layer n=1 (for which an entering event has already been determined) and for its child nodes of layer n=2.

In particular, the proximity manager 41 may determine either an exiting event relating to the proximity node of layer n=1 , or an entering event relating to anyone of its child nodes of layer n=2.

If the proximity manager 41 determines an entering event relating to a child node of layer n=2, it preferably reverts to step 300, thereby sending another configuration request to the proximity server API 61 .

At this third iteration of step 300, the proximity manager 41 preferably requests the node configuration of possible proximity node(s) of layer n=3 which are child nodes of the proximity node of layer n=2 for which the entering event has just been determined.

In response to the configuration request, the proximity server API

61 preferably retrieves from the node database 62 the node configurations of such child proximity node(s) of layer n=3, if any,

(step 301 ) and sends them to the proximity manager 41 in the form of a configuration response (step 302).

Hence, with reference to the exemplary tree graph shown in

Figure 2, if an entering event is determined e.g. for the proximity node 22, the third iteration of steps 301 and 302 results in the proximity server API 61 retrieving and sending to the proximity manager 41 the node configurations of the proximity nodes 24 and

25 of layer n=3, namely the child nodes of the proximity node 22. It shall be noticed that the node configurations of nodes 26 and 27 are not retrieved, since they are child nodes of the node 23, for which no entering events have been determined.

Upon reception of the configuration response, the proximity manager 41 preferably checks its content for determining whether it comprises the node configuration(s) of proximity node(s) belonging to the layer n=3, which are child nodes of the node of layer n=2 for which an entering event has been detected (step 306). In the affirmative, the proximity manager 41 preferably identifies the sensors of the mobile terminal 1 (if any) which shall be activated for gathering context data indicative of possible proximity events relating to the child proximity node(s) of layer n=3 (step 303). For instance, with reference to the exemplary hierarchy shown in Figure 2, since at the third iteration of steps 300-302 the node configurations of the proximity nodes 24 and 25 are received at the proximity manager 41 , which are both multimedia nodes (e.g. images) , at step 303 the proximity manager 41 identifies also the camera 13 of the mobile terminal 1 as a sensor to be activated.

Then, at the third iteration of step 303 the proximity manager 41 preferably checks whether the identified sensor(s) is/are already active and, in the negative, asks the user of the mobile terminal 1 (e.g. via a text message in the display of the mobile terminal 1 ) to activate it/them.

At the third iteration of step 303 the proximity manager 41 also initializes a set of local attributes for each child node of layer n=3, as described above.

While the proximity manager 41 is receiving the context data, it preferably repeats the above described step 305 to determine possible proximity events for the proximity node of layer n=1 (for which an entering event has already been determined), its child proximity node of layer n=2 (for which an entering event has already been determined), and for the latter's child nodes of layer n=3.

According to an advantageous variant, at this iteration of the algorithm the proximity manager 41 may also deactivate at step 303 the sensors gathering context data indicative of possible proximity events relating to the proximity node(s) of layer n=1 . More generally, at the n iteration of the algorithm, the proximity manager 41 may deactivate at step 303 the sensors gathering context data indicative of possible proximity events relating to the proximity node(s) of layer (n-2)^th. In this way, at step 305 the proximity manager 41 may determine only proximity events relating to the proximity nodes of layers n^th and their parent node of layer (n-1 )^th for which the last entering event has been detected.

With reference to Figure 2, the proximity manager 41 may determine either an exiting event relating to the proximity node of layer n=2, or an entering event relating to one of latter's child nodes of layer n=3.

The iteration of steps 300-306 continues, until either an entering event is determined for a proximity node having no child nodes, or an exiting event relating to any of the proximity nodes is determined. For instance, with reference to the exemplary hierarchy shown in Figure 2, steps 300-306 are iterated until either an entering event is determined for anyone of the proximity nodes 23, 24 or 25, or an exiting event is determined for anyone of the proximity nodes 21 , 22. In the first case, and specifically in case of the determination of an entering event relating to a proximity node having no child nodes, the proximity manager 41 preferably triggers provision of the proximity service associated with the proximity node with no child nodes for which the last entering event has been determined (step 307). For instance, if an entering event is determined relating to the proximity node 25, the proximity manager 41 reverts again to step 300, thereby receiving from the configuration server 6 a configuration response from which it determines that the proximity node 25 has no child nodes (step 306). Hence, the mobile terminal 1 is provided with a proximity service associated with the proximity node 25, e.g. it is provided with information of the current offers in the shop count associated with the proximity node 25. In the latter case (determination of an exiting event relating to anyone of the monitored proximity nodes), the proximity manager 41 preferably checks whether the proximity node for which the exiting event has been determined has any child node (step 308).

In the negative, the proximity manager 41 reverts to step 305, thereby continuing determining possible proximity events relating to the same proximity nodes. For instance, if the proximity manager 41 determines an exiting event relating to proximity node 25 (for which an entering event was previously determined), the proximity manager 41 continues determining possible proximity events relating to the proximity nodes 21 , 22, 23, 24 and 25.

If, instead, the proximity node for which the exiting event has been determined has child nodes, the proximity manager 41 preferably excludes from its proximity event determination all the child nodes of the proximity node for which the exiting event has been determined (step 309). The proximity manager 41 then preferably reverts to step 305, thereby continuing determination of possible proximity events relating to the non excluded proximity nodes. For instance, if the proximity manager 41 determines an exiting event relating to proximity node 22 (for which an entering event was previously determined), the proximity manager 41 preferably excludes from its proximity event determination the proximity nodes 24 and 25 (namely, the child nodes of the proximity node 22), and continues determining possible proximity events relating to proximity nodes 21 , 22 and 23.

In the latter case (proximity node for which the exiting event has been determined has child nodes), the proximity manager 41 also preferably instructs the sensor manager 42 to deactivate only the sensor(s) providing context data relating to the proximity nodes excluded at step 309 (step 31 0). In this way, the consumption of batteries at the mobile terminal 1 is advantageously optimized. Herein after, step 305 of determining whether a proximity event relating to a certain proximity node has occurred will be described in further detail, with reference to the flow chart of Figure 4.

Upon reception of an update of the context data (step 400), the proximity manager 41 first of all detects possible proximity events (namely, entering events or exiting events) relating to the proximity node (step 401 ).

With reference to the flow chart of Figure 5, the detection performed in step 401 depends on the type of activated sensor and, hence, on the type of provided context data.

If the activated sensor is a GPS sensor or a wireless sensor (GSM/GPRS, UMTS, LTE/LTE Advanced, 5G, RFID, Wi-Fi, Bluetooth, etc.), upon reception of each update of the context data, the proximity manager 41 preferably uses the updated context data for calculating the current distance between the mobile terminal 1 and the proximity node (sub-step 501 ).

In particular, if the activated sensor is a GPS sensor providing the current position of the mobile terminal 1 in terms of geographic coordinates (latitude and longitude), at sub-step 501 the proximity manager 41 preferably calculates the distance between such position and the one indicated by the attribute "point " in the node configuration. In this case, typical distance values range from tens of meters to a few kilometres. If the activated sensor is instead a wireless sensor (GSM/GPRS, UMTS, LTE/LTE Advanced, 5G, RFID Wi-Fi, Bluetooth, etc.) providing power and identifier of each wireless network or device detected within the sensor range, at sub-step 501 the proximity manager 41 preferably translates the power value in a distance value by using any known calculation technique, e.g. the one described by T. S. Rappaport in "Wireless Communication Principles and Practice", page 126, 2002, Prentice Hall. In this case, typical distance values range from a few meters to a few hundred meters.

After calculating the distance, the proximity manager 41 preferably compares the calculated distance with the value of the attribute "accuracy" specified in the received node configuration.

In case the value of the local attribute "status" is "OUT" (indicating that the mobile terminal 1 was previously outside the influence area of the proximity node), if the calculated distance is shorter than or equal to the value of the attribute " accuracy" (sub- step 502a) the proximity server 41 detects an entering event (sub- step 503a). In case instead the local attribute "status " is "IN" (indicating that the mobile terminal 1 was previously within the influence area of the proximity node), if the calculated distance is larger than the value of the attribute "accuracy" (sub-step 502b) the proximity server 41 detects an exiting event (sub-step 503b).

If the activated sensor is a multimedia sensor providing a video or audio stream, the proximity manager 41 preferably compares the video or audio stream provided by the multimedia sensor with the reference image or soundtrack stored in the node configuration. In case the value of the local attribute "status" is "OUT" (indicating that the mobile terminal 1 was previously outside the influence area of the proximity node), if the reference image or soundtrack stored in the node configuration is recognized in the video or audio stream provided by the multimedia sensor (sub-step 504a), then the proximity manager 41 detects an entering event (sub- step 505a). In case instead the value of the local attribute "status" is "IN" (indicating that the mobile terminal 1 was previously within the influence area of the proximity node), if the reference image or soundtrack comprised in the node configuration is no more recognized in the video or audio stream provided by the multimedia sensor (sub-step 504b), then the proximity manager 41 detects an exiting event (sub-step 505b). If no proximity event is detected at sub-step 502a, 502b, 504a or 504b, the proximity manager 41 preferably resets the local attribute

"event_confirmation" (sub-step 506a or 506b) and then reverts to step 400.

If a proximity event is, instead, detected at sub-step 502a, 502b, 504a or 504b, the proximity manager 41 preferably increases by 1 the value of the local attribute "event_confirmation" (sub-step 507). In this way, the local attribute "event_confirmation" stores the number of consecutive detections of a proximity event.

Then, as shown in Figure 4, the proximity manager 41 preferably checks whether one or more conditions for determining a proximity event are met (step 402). The proximity manager 41 indeed determines a proximity event if certain conditions are met. In particular, in an embodiment:

(i) an entering event is determined if at least one of the following conditions is met:

a) the proximity manager 41 has detected the entering event for a minimum number of consecutive iterations of step 401 ; b) the mobile terminal 1 has to monitor proximity events of the type "entering"; and

c) the number of already determined entering events is lower than the number of entering events that may be notified to the mobile terminal 1 ; and

(ii) an exiting event is determined if at least one of the following conditions is met:

a) the proximity manager 41 has detected the exiting event for a minimum number of consecutive iterations of step 401 ; b) the mobile terminal 1 has to monitor proximity events of the type "exiting"; and

c) the number of already determined exiting events is lower than the number of exiting events that may be notified to the mobile terminal 1 .

With reference to Figure 6, for the purpose of checking condition a), the proximity manager 41 preferably compares the value of the local attribute "event_confirmation" with the value of the attribute "detection" in the locally stored node configuration. According to preferred variants, the proximity manager 41 preferably maps the textual value of the attribute "detection" (which may be "FAST", "MEDIUM" or "SLOW", as described above) in a corresponding numerical integer value det (sub-step 601 ). The textual value of the attribute "detection" is preferably set by the space owner, depending on the speed with which proximity events relating to the proximity node shall be determined. For instance, the above textual values of the attribute "detection" may be translated by the proximity manager 41 into det equal to 2, 3 and 4 respectively.

Then, the proximity manager 41 preferably compares the value of the local attribute "event_confirmation" with the numerical value det (sub-step 602).

Whether the value of the local attribute "event_confirmation" is lower than det, the proximity manager 41 preferably determines that condition a) is not met yet and reverts to step 400, thereby receiving a further update of the context information and applying thereto the proximity event detection step 401 described above.

When the value of the local attribute "event_confirmation" becomes equal to the numerical value det, the proximity manager 41 determines that condition a) is met, and then preferably starts checking condition b).

For the purpose of checking condition b), the proximity server 41 preferably compares the value of the local attribute "status" with the value of the attribute "event" comprised in the stored node configuration. Therefore, in case the value of the local attribute "status " is "OUT", if the value of the attribute "event " is "IN" or "IN/OUT" (sub- step 603a), the proximity manager 41 concludes that condition b) is met. Similarly, in case the value of the local attribute "status" is "IN", if the value of the attribute "event " is "OUT" or "IN/OUT" (sub- step 603b), the proximity manager 41 concludes that condition b) is met.

If condition b) is not met, the proximity manager 41 preferably reverts to step 400, thereby receiving a further update of the context information and applying thereto the proximity event detection step 401 described above.

If condition b) is met, the proximity manager 41 preferably starts checking condition c). This includes a check of the value of the attribute "fr equency" (that, as described above, specifies the number of times the mobile terminal 1 is notified upon determination of proximity events).

If the textual value of the attribute "frequency" is "ALWAYS", the whole checking of condition c) is preferably omitted and the proximity manager proceeds to step 403, as described in the following.

Otherwise, for the purpose of checking condition c), the proximity server 41 preferably maps the textual value of the attribute "f requency" into a corresponding numerical value f (sub-step 605). In particular, the textual values "ONCE" and "ONCE PER EVENT" are preferably mapped into the numerical value f =1 , while the textual value "X" is mapped into the numerical value f =X.

The proximity manager 41 then preferably compares the value of one of the local attributes "entering_counter" (for entering events) or "exit ing_count er" (for exiting events) with the value of f determined at sub-step 605.

In particular, if the value of the local attribute "status " is "OUT", the proximity manager 41 preferably checks whether the value of the local attribute "ente ring_count er" is lower than f (sub-step 606a). If instead the value of the local attribute "status " is "IN", the proximity manager 41 preferably checks whether the value of the local attribute "exit ing_counter" is lower than f (sub-step 606b). If the check of sub-step 606a or 606b has a negative outcome, the proximity manager 41 preferably concludes that condition c) is not met and that a proximity event shall not be determined. The proximity manager then preferably reverts to step 400.

If instead the check of sub-step 606a or 606b has a positive outcome, the proximity manager 41 concludes that condition c) is met, and then determines (namely, it confirms detection of) a proximity event (step 403).

As shown in the flow chart of Figure 7, at step 403 the proximity manager 41 preferably resets the value of the local attribute "event_con f irmat ion" (sub-Step 701 ).

Then, if the value of the local attribute "status " is currently "OUT" it preferably changes this value into "IN" (sub-step 702a), thereby acknowledging that the mobile terminal 1 is now within the influence area of the proximity node. The proximity manager 41 also preferably increases by 1 the value of the local attribute "entering_counte r" (sub-step 703a).

If, instead, the value of the local attribute "status" is currently "IN" it preferably changes this value into "OUT" (sub-step 702b), thereby acknowledging that the mobile terminal 1 is now outside the influence area of the proximity node. The proximity manager 41 also preferably increases by 1 the value of the local attribute

"exit ing_counte r" (sub-Step 703b).

Advantageously, therefore, the information on the proximity nodes - hierarchically organized based on the influence areas of the proximity nodes - are stored at the proximity server and downloaded by the mobile terminal step-by-step, starting first from the upper hierarchical layer and passing then to the lower hierarchical layer only if a proximity event relating to a proximity node of the upper hierarchical layer is determined.

Claims

A method for providing a proximity service to a mobile terminal (1 ) in a smart space (2) comprising a number of proximity nodes (21 -27), said method comprising:

a) at a proximity server (6), storing information on said proximity nodes (21 -27), said information being logically organized according to a logical hierarchy based on influence areas of said proximity nodes (21 -27);

b) at said mobile terminal (1 ):

• monitoring proximity events relating to a proximity node (22) of said number of proximity nodes (21 -27);

• upon determination of an entering event relating to said proximity node (22), determining whether said proximity node (22) has at least one child proximity node (25) according to said logical hierarchy by sending a configuration request to said proximity server (6) and receiving therefrom a configuration response; and

• in the affirmative, monitoring proximity events relating to said at least one child proximity node (25).

The method according to claim 1 , wherein said proximity service is provided to said mobile terminal (1 ) upon determination of an entering event relating to said at least one child proximity node (25).

The method according to claim 2, wherein it further comprises, upon determination of an exiting event relating to said at least one child proximity node (25), continuing monitoring proximity events relating to said proximity node (22) and said at least one child proximity node (25).

The method according to claim 2 or 3, wherein it further comprises, upon determination of an exiting event relating to said proximity node (22), stopping monitoring proximity events relating to said at least one child proximity node (25).

The method according to any of the preceding claims, wherein at step b) said configuration response comprises information allowing said mobile terminal (1 ) determining a sensor (12) of said mobile terminal (1 ) to be activated for receiving context data to be used for monitoring proximity events relating to said at least one child proximity node (25).

The method according to any of the preceding claims, wherein at step b) said monitoring proximity events relating to said at least one child proximity node (25) is also based on a set of local attributes.

The method according to claim 6, wherein said set of local attributes comprises:

a first local attribute indicating whether said mobile terminal (1 ) is currently within an influence area of said at least one child proximity node (25) or outside said influence area of said at least one child proximity node (25);

a second local attribute indicating a number of consecutive detections of a proximity event relating to said at least one child proximity node (25) that are required to determine a proximity event; and

a third local attribute indicating the number of already determined proximity events relating to said at least one child proximity node (25).

The method according to any of the preceding claims, wherein at step b) said monitoring proximity events relating to said at least one child proximity node (25) comprises calculating a current distance between said mobile terminal (1 ) and said at least one child proximity node (25).

The method according to claim 8, wherein at step b) said monitoring proximity events relating to said at least one child proximity node (25) comprises comparing said calculated current distance with a maximum distance specified in said configuration response and:

(i) if said mobile terminal (1 ) was previously outside said influence area and said calculated distance is shorter than or equal said maximum distance, detecting an entering event; or

(ii) if said mobile terminal (1 ) was previously within said influence area and said calculated distance is longer than said maximum distance, detecting an exiting event.

The method according to any of claims 1 to 7, wherein at step b) said monitoring proximity events relating to said at least one child proximity node (25) comprises comparing a video or audio stream provided by a multimedia sensor of said mobile terminal (1 ) with a reference image or soundtrack comprised in said configuration response, and:

(i) if said mobile terminal (1 ) was previously outside said influence area and said reference image is recognized in said video or audio stream, detecting an entering event; or

(ii) if said mobile terminal (1 ) was previously within said influence area and said reference image is not recognized in said video or audio stream, detecting an exiting event.

The method according to any of the preceding claims, wherein an entering event relating to said at least one child proximity node (25) is determined if said entering event has been detected for a minimum number of consecutive times, and wherein an exiting event relating to said at least one child proximity node (25) is determined if said exiting event has been detected for a minimum number of consecutive times, said minimum number being specified in said configuration response.

12. The method according to any of the preceding claims, wherein an entering event relating to said at least one child proximity node (25) is determined if said mobile terminal (1 ) has to monitor proximity events of the type "entering", and wherein an exiting event relating to said at least one child proximity node (25) is determined if said mobile terminal (1 ) has to monitor proximity events of the type "exiting", an indication of whether said mobile terminal (1 ) has to monitor proximity events of the type "entering" and/or "exiting" being comprised in said configuration response.

13. The method according to any of the preceding claims, wherein an entering event relating to said at least one child proximity node (25) is determined if the number of already determined entering events is lower than a maximum number of entering events that may be notified to the mobile terminal (1 ) and an exiting event relating to said at least one child proximity node (25) is determined if the number of already determined exiting events is lower than a maximum number of exiting events that may be notified to the mobile terminal (1 ), said maximum number being specified in said configuration response.

14. A system (3) for providing a proximity service to a mobile terminal (1 ) in a smart space (2) comprising a number of proximity nodes (21 -27), said system (3) comprising:

a proximity server (6) storing information on said proximity nodes (21 -27), said information being logically organized according to a logical hierarchy based on influence areas of said proximity nodes (21 -27); and

a client application (4) to be executed by said mobile terminal (1 ), said client application (4) being configured to: • monitor proximity events relating to a proximity node (22) of said number of proximity nodes (21 -27);

• upon determination of an entering event relating to said proximity node (22), determine whether said proximity node (22) has at least one child proximity node (25) according to said logical hierarchy by sending a configuration request to said proximity server (6) and receiving therefrom a configuration response; and

• in the affirmative, monitor proximity events relating to said at least one child proximity node (25).

A computer program product loadable in the memory of at least one computer and including software code portions for performing the steps of the method of any of claims 1 to 1 3, when the product is run on at least one computer.