Technical Field

The application relates to a method for operating a mobile entity and to the corresponding mobile entity. Furthermore, a method for operating a service management unit is provided and the corresponding service management entity. In addition, a method for operating a locator unit in a home network is provided. The application furthermore relates to the corresponding locator entity and to a system comprising the mobile entity, the service management entity and the locator entity. Additionally, a computer program comprising programme code and a carrier comprising the computer program is provided.

Background

Current mobile telecommunication protocols are allowing to some extend communication between a mobile entity and some of its surrounding environment. Some of the current or coming applications are listed below:

a. When a mobile entity registers to a visiting network, the networks "greets" it with a SMS (Short Message Service) Welcome message with information about the current tariffs and most important numbers or calling procedures;

b. The first time a mobile entity is purchased and it registers to its home network, an Automatic Device Configuration server might send him the applicable settings that would allow the entity to connect to the network

c. If the end-user allows it, Location-based servers allow location-based advertising d. If the end-user allows it, a Ring-back Tone server can play advertising during call setup e. The end-user can subscribe to social networks and allow their service to track the user and offer him information based on his past browsing history, selected options etc f. Car-to-World (C2W) protocols allows a (semi)autonomous car to receive information from other similar cars on the road in the close proximity or from pedestrians or other devices enabled for C2W protocols so that the car can avoid obstacles, prevent accidents or collisions, drive safely on a road. All services in the categories described in the previous section are offering limited communication and exchange of information that is related to the scope of the service. All those are one-way services, most of the time network-to-mobile entity based, they do not expect any kind of answer from the mobile entity or short, long or permanent interaction with the end-user.

The server that initiates the communication is triggered by simple triggers and it is unable to act outside its parameters. The end-user can only notice the information but it cannot interact with it. There is no clear procedure related to the subsequent actions if those are wished by the user. For location-based services, most of the time, these are considering only the information related to the actual location of the end-user, only very few are able to use or correlate this with the information about moving vectors and actual map information.

By way of example, a user can access an application server or service providing entity using an QR code attached to a label into which an address of the application server is coded. When an operator wants to change the address of the application server than the distributed QR codes all have to be changed or an application decoding the QR code. However, this is not possible without major efforts. Furthermore, the user scanning the QR code cannot be sure whether one can trust the information provided in the QR code.

Accordingly, a need exists to obviate at least some of the above identified problems and to provide a possibility to provide new fields of application for services for people located on site or moving in or into an area.

Summary

This need is met by the features of the independent claims. Further aspects are described in the dependent claims.

According to one aspect a method for operating a mobile entity is provided. A service identifier is determined from an information providing entity which provides information about a service providing entity and comprises at least an identity of the information providing entity. Furthermore, a location information is added to the service identifier and a verification request is transmitted towards a service management entity which is configured to manage a plurality of information providing entities. The verification request requests whether the information providing entity from which the service identifier is received, is a trusted information providing entity, the verification request further comprising the identity and the location information related to the information providing entity. The mobile entity furthermore receives a confirmation response from the service management entity in response to the verification request. The confirmation response informs the mobile entity that the information providing entity can be trusted, and the confirmation response includes address information of the service providing entity. The mobile entity accesses the service providing entity based on the address information of the service providing entity.

Furthermore, the corresponding mobile entity is provided comprising a memory and at least one processor, wherein the memory contains instructions executable by the at least one processor, wherein the mobile entity is operative to operate as mentioned above or as discussed in more detail below. When the mobile entity detects a service identity, it can check with the service management entity whether the information providing entity advertising a service providing entity is a trusted entity or not. Based on the response from the service management entity the mobile entity can access the service providing entity or not.

Alternatively, a mobile entity is provided comprising a first module configured to determine, from an information providing entity, a service identifier which provides information about a service providing entity and comprises at least an identity of the information providing entity, a second module configured to add a location information to the service identifier, and a third module configured to transmit a verification request towards a service management entity which is configured to manage a plurality of information providing entities, the verification request requesting whether the information providing entity from which the service identifier is received, is a trusted information providing entity, the verification request comprising the identity and the location information related to the information providing entity. The mobile entity comprises a fourth module configured to receive a confirmation response from the service management entity in response to the verification request, the confirmation response informing the mobile entity that the information providing entity can be trusted, the confirmation response including address information of the service providing entity, and a fifth module configured to access the service providing entity based on the address information of the service providing entity. Additionally, a method for operating a service management entity configured to manage a plurality of information providing entities is provided. The service management entity receives a verification request from the mobile entity, the verification request requesting whether an information providing entity identified in the verification request is a trusted information providing entity, the verification request comprising an identity related to the information providing entity. The service management entity accesses a register where identity information of the plurality of information providing entities is stored. Additionally, it is determined whether the identity of the information providing entity present in the verification request matches with the identity information for an information providing entity stored in the register. If this is the case/affirmative, address information of a service providing entity is determined by which the service providing entity can be accessed. Furthermore, a confirmation response with the determined address information is transmitted to the mobile entity, wherein the confirmation response informs the mobile entity that the information providing entity is a trusted information providing entity.

The service management entity manages the different information providing entities and informs the mobile entity whether the information providing entity for which a verification request is received. Furthermore, the service management entity provides the address information which can be used by the mobile entity to access the server or service providing entity that provides the service.

Furthermore, the corresponding service management entity is provided comprising a memory and at least one processor wherein the memory contains instructions executable by the at least one processor, wherein the service management entity is operative to operate as discussed above or discussed in more detail below.

Furthermore as an alternative, a service management entity is provided comprising a first module configured to receive a verification request from a mobile entity, the verification request requesting whether an information providing entity identified in the verification request is a trusted information providing entity, the verification request comprising an identity related to the information providing entity, and a second module configured to access a register where identity information of the plurality of information providing entities is stored. A third module of the service management entity is configured to determine whether the identity of the information providing entity present in the verification request matches with an identity information for the information providing entity stored in the register, and, in the affirmative, a fifth module is configured to determine address information of a service providing entity by which the service providing entity can be accessed, and a sixth module is configured to transmit a confirmation response with the determined address information to the mobile entity, the confirmation response informing the mobile entity that the information providing entity is a trusted information providing entity.

Furthermore, a method for operating a locator unit in a home network is provided, wherein a verification request is received from a mobile entity, the verification request requesting whether an information providing entity identified in the verification request is a trusted information providing entity, the verification request comprising the identity and location information related to the information providing entity. The locator unit determines whether the verification request received from the mobile entity is a verification request received for a service management entity which is configured to manage a plurality of information providing entities of the home network. If this is not the case, a foreign network is determined to which the information providing entity for which the verification request is received, belongs and the address information of a foreign locator unit is determined belonging to the foreign network. In addition, the verification request is relayed to the foreign locator unit.

Additionally, the locator unit located in the home network is provided, the locator unit comprising a memory and at least one processor wherein the memory contains instructions executable by the at least one processor wherein the locator unit is operative to operate as discussed above or as discussed in further detail below.

Alternatively, a locator unit is be provided comprising a first module configured to receive a verification request from a mobile entity, the verification request requesting whether an information providing entity identified in the verification request is a trusted information providing entity, the verification request comprising an identity and a location information related to the information providing entity, and a second module configured to determine whether the verification request received from the mobile entity is a verification request received for a service management entity which is configured to manage a plurality of information providing entities of the home network.

If this is not the case, a third module is configured to determine a foreign network to which the information providing entity for which the verification request is received, belongs and an address of a foreign locator unit belonging to the foreign network, and a fourth module is configured to relay the verification request to the foreign locator unit.

When the mobile entity is roaming in a foreign network, it may receive a verification request for an information providing entity which is not located in the home network. The mobile entity sends the verification request to the service management entity which has the knowledge about the different information providing entities. When the locator unit determines that the verification request is not for a service management entity of the home network, it determines the foreign network to which the service management entity and the corresponding information providing entity belongs, and relays the verification request to a foreign locator unit which belongs to the foreign network.

Additionally, a system comprising the mobile entity, the service management entity and the locator unit as discussed above is provided.

Furthermore, a computer program comprising program code to be executed by at least one processor of a mobile entity, of a service management entity or of a locator unit is provided wherein execution of the program code causes the at least one processor to execute a method discussed above or discussed in further detail below.

Additionally, a carrier comprising the computer program is provided, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

It is to be understood that the features mentioned above and features yet to be explained below can be used not only in the respective combinations indicated, but also in other combinations or in isolation without departing from the scope of the present invention. Features of the above- mentioned aspects and embodiments may be combined with each other in other embodiments unless explicitly mentioned otherwise. Brief Description of the Drawings

The foregoing and additional features and effects of the application will become apparent from the following detailed description when read in conjunction with the accompanying drawings in which like reference numerals refer to like elements.

Figure 1 shows an example system including a mobile entity, a service management entity, an information providing entity and a service providing entity in a high-level architecture comprising features of the invention.

Figure 2 shows a network overview of the system of figure 1 with the different areas and entities managed by a network provider and by a service provider.

Figure 3 shows a high-level architecture of a system as shown in Figure 1 in which a mobile entity may be located in different networks, and shows how the entities in the different networks interact.

Figure 4 shows a high-level architecture of a service management entity of one network including a locator unit and a service management unit and how the service management entity interacts with a service management entity and the corresponding locator unit of another network.

Fig. 5 shows a how a mobile entity located in a foreign network uses the service of the service providing entity.

Figure 6 shows an example flowchart of a method carried out by a mobile entity which receives a service identifier from an information providing entity and transmits a verification request to a service management entity in a network as shown in figure 1.

Figure 7 shows an example flowchart of a method carried out by a service management entity which receives the verification request from a mobile entity.

Figure 8 shows an example flowchart of a method carried out by a locator unit receiving a verification request from a roaming mobile entity. Figure 9 shows an example schematic representation of a mobile entity used in the system shown in figures 1 to 5.

Figure 10 shows an example schematic representation of a service management entity used in the system shown in figures 1 to 5.

Figure 1 1 shows an example schematic representation of a locator unit used in the system shown in figures 3 and 4.

Figure 12 shows another example schematic representation of a mobile entity used in the system shown in Fig. 1 to 5.

Figure 13 shows another example schematic representation of a service management entity used in the system shown in Fig. 1 to 5.

Figure 14 shows another example schematic representation of a locator unit used the system and shown in Fig. 3 and 4.

Figure 15 shows an example schematic representation of an area in which an information providing entity provides information about a service at an entrance to an area and wherein another information providing entity is located at exit of the area where the service is provided.

Detailed Description of Embodiments

In the following, embodiments of the invention will be described in detail with reference to the accompanying drawings. It is to be understood that the following description of embodiments is not to be taken in a limiting sense. The scope of the invention is not intended to be limited by the embodiments described hereinafter or by the drawings, which are to be illustrative only.

The drawings are to be regarded as being schematic representations, and elements illustrated in the drawings are not necessarily shown to scale. Rather, the various elements are represented such that their function and general purpose becomes apparent to a person skilled in the art. Any connection or coupling between functional blocks, devices, components of physical or functional units shown in the drawings and described hereinafter may also be implemented by an indirect connection or coupling. A coupling between components may be established over a wired or wireless connection. Functional blocks may be implemented in hardware, software, firmware, or a combination thereof.

Within the context of the present application, the term "mobile entity" or "user equipment" (UE) refers to a device for instance used by a person (i.e. a user) for his or her personal communication. It can be a telephone type of device, for example a telephone or a Session Initiating Protocol (SIP) or Voice over Internet Protocol (VoIP) phone, cellular telephone, a mobile station, cordless phone, or a personal digital assistant type of device like laptop, notebook, notepad, tablet equipped with a wireless data connection and preferably a camera. The UE may also be associated with non- humans like animals, plants, or machines. A UE may be equipped with a SIM (Subscriber Identity Module) or electronic-SIM comprising unique identities such as IMSI (International Mobile Subscriber Identity), TMSI (Temporary Mobile Subscriber Identity), or GUTI (Globally Unique Temporary UE Identity) associated with the user using the UE. The presence of a SIM within a UE customizes the UE uniquely with a subscription of the user.

For the sake of clarity, it is noted that there is a difference but also a tight connection between a user and a subscriber. A user gets access to a network by acquiring a subscription to the network and by that becomes a subscriber within the network. The network then recognizes the subscriber (e.g. by IMSI, TMSI or GUTI or the like) and uses the associated subscription to identify related subscriber data. A user is the actual user of the UE, and the user may also be the one owning the subscription, but the user and the owner of the subscription may also be different. E.g. the subscription owner may be the parent, and the actual user of the UE could be a child of that parent.

The solution discussed below describes a new mechanism that allows a full immersion of a mobile entity, also called UE hereinafter, in a complete new area of services. In the solution discussed below information providing entities are provided which are able to describe the area they are marking and which provide some basic information to the mobile entity that can be used by the mobile entity for automatic connection to a service providing entity that is relevant for the area. The information providing entities also function as "area identification beacons" (AIB) and are thus also called AIBs in the following. With reference to Fig. 1 the architecture of a system and network is explained in more detail in which a mobile entity 100 is informed by an information providing entity 50 that access to a service providing entity 60 is possible. As explained below before accessing the service providing entity 60 it is checked with a service management entity 200 whether the system including the service providing entity 60 and the information providing entity 50 is a trusted system.

The information providing entity 50 can be an active information providing entity which performs a short range broadcast of the relevant information, namely which provides a service identifier including an identity of the information providing entity. The information providing entity can also be a passive information providing entity where the relevant information such as the service identifier is provided on a passive medium, e.g. a special marker attached to a surface, e.g. an entrance ticket or in any other place around the marked area. The relevant information will include in an encoded manner the same information that could be broadcast by the active information providing entity.

In the first section of the following description the marking technology of the information providing entities 50 and the interaction with the mobile entity 100, the service management entity 200 and a locator unit (300A and 360A/B as shown in Fig. 3 and 4) is disclosed whereas later on some examples of the newly provided services are explained in more detail. The solution discussed below allows the apparition of a completely different type of service providers:

- Cultural or Entertainment establishments can offer a new range of services available for people on site,

- Road authorities can offer road related information correlated with the information provided by a vehicle navigation service. The offered information could be for use of the vehicle (in a self driving car) or for the use of the driver or passengers.

-A city, county, or government could offer local information for the use by locals or visitors.

In the same time, communication will be enabled also from the opposite direction, from the people having new mobile entities 100 or autonomous entities 100 enabled for the new technology that would be, for example, able to exchange information, participate to ad-hoc social groups, say their meaning, find friends or acquaintances roaming in the same area. Figure 1 shows a high-level example architecture of a system in which the mobile entity 100 receives information from the information providing entity 50. The access to the new services are facilitated by the information providing entities 50 deployed in the area that should be marked. There is no need for a communication between different information providing entities. Additionally, the mobile entities 100 not have to include additional mobility mechanisms for a possible handover or transfer from one information providing entity 50 to another information providing entity.

In the system shown in Fig. 1 the information providing entity 50 broadcasts information which allows the mobile entity 100 to identify the information providing entity. Accordingly, the information providing entity 50 broadcasts a service identifier which comprises the identity of the information providing entity 50. The mobile entity receiving the information has to determine whether it can trust the information providing entity. To this end it can add location information of its present location to the received service identifier, for example if the received service identifier does not already contain location information via which the location of the information providing entity 50 can be determined. Alternatively, the mobile entity 100 can always add location information of its present location to the received service identifier and either overwrite location already present in the service identifier or add additional location information. The mobile entity 100 can then transmit a verification request towards the service management entity 200. This service management entity 200 managers a plurality of the information providing entities 50 and comprises a register 235 in which identity information of the plurality of information providing entities of the network is stored. The service management entity 200 determines whether the identity of the information providing entity received with the verification request corresponds to the identity information stored in the register. If this is the case, address information may be determined for a service providing entity 60, also named application server in Fig. 1 , and the address information is transmitted together with the confirmation response to the mobile entity 100 wherein the confirmation response informs the mobile entity that the information providing entity 50 is a trusted information providing entity so that the mobile entity 100 can then access the providing entity 60 using the address information received from the service management entity 200. The mobile entity 100 can then access the service providing entity 60 via for example a mobile communications network 70, a corresponding service Gateway 30 and the Internet 80. Alternatively, a Wireless Local Area Network (WLAN), or any other available network, may be used by the mobile entity 100 to access the service providing entity. The service providing entity 60 can be managed and controlled via a terminal 20 connected to the service providing entity 60 via an intranet 40 or a local management connection (not shown). Information about the service providing entity 60 may be additionally provided to the information providing entity 50 and the service management entity 200.

The information providing entity (AIB) 50 can be an active information providing entity or passive information providing entity.

An active information providing entity or AIB 50 is characterized by sending or broadcasting on very short range such as a couple of meters up to a couple of ten meters some specific information that would allow the mobile entity 100 to identify the AIB 50 and optionally other useful information like for example: the name of the offered service and of the marked area, the validity of the information, if the offered services are free of charge or request some payment (and the type of payment) or other related information. In order to be able to receive this information, the mobile entity 100 shall be adapted for the new technology or run special applications that would allow detection of the AIBs 50 (in case the AIBs would use for broadcasting one or more of the common existing technologies.)

The information providing entities 50 may transmit/broadcast in a new frequency band or will use an existing communication band (GSM (Global System for Mobile Communications) 3,5 G WCDMA (Wideband Code Division Multiple Access)/HSPA (High Speed Packet Access), 4G LTE (Long Term Evolution) 5G, WiFi etc) to broadcast the information described on high level in the previous paragraph. Since it is wanted that the mobile entity 100 immediately reads and accepts the broadcast information without any additional user interaction, it might be possible to avoid the use of the WiFi spectrum. However, the WiFi spectrum may be used when the WiFi standards and the ways the mobile entities are accessing this technology are changed.

AIBs 50 may broadcast with a very low power - to allow the mobile entities 100 to detect a AIB 50 only in the moment when it is located within its close proximity (the information could be received for example at maximum at a couple of meters and in one or more certain direction from the AIB 50) to avoid any interferences with other AIBs 50 that might exist in the same area. That also means that the AIBs 50 may be preferably placed in a place that the user will certainly approach with his mobile entity 100 (e.g. next to the ticket counter or at the point where the entrance tickets are checked, with the antenna embedded inside in or around the entrance doors etc). The information providing entities can be of multiple types, for example:

a. "in-access" entities used to broadcast information about a new service

b. "exit" entities that are used to reset the access to the service advertised by the "in- access" entities

c. sub-entities that are used to delimit certain smaller areas (or rooms) within the larger area delimited by the In-access information providing entity.

In-Access information providing entities (in_access AIBs)

Each in-access AIB 50 will broadcast its unique identity, an AIB ID, - due to nature and the way of triggering of the new services, in order to avoid presence of fake or unregistered AIBs that can lure the mobile entities to fake malicious or fraudulent services. The AIB ID will represent a unique string of characters that will be in the same time controlled by a central authority and verified in the service management entity 200. Furthermore, the AIB 50 may provide information about a name of the provided service. Additionally, the AIBs may offer a text message describing the area it marks (e.g. the name of the street, the name of the museum, zoo or attraction park, shopping center etc) that could be considered in the same time as the alphanumeric identifier of the group/service and optionally information about the validity of the information for the user who will register to the service providing entity 60 and the nature of the service (paid, free etc.).

When a mobile entity 100 detects a new AIB ID, it will contact the service management entity 200 and request the validation of the received ID and indication about the address of the nature of the offered services and the address of the hosting server of the service providing entity 60. For a valid AIB ID, the service management entity 200 will validate it and send back the confirmation to the mobile entity 100 which might be accompanied by additional information about the type/class of the offered services, address of the server that hosts these, validity of the service etc. As an additional security measures, the mobile entity 100 can also compare the additional information received from the service management entity 200 with the information received from the AIB and accept the information only in case of a full match.

When the mobile entity 100 accesses the service providing entity 60, the following steps may be carried out:

Step S11 : The AIB or information providing entity 50 broadcasts at least one of the following pieces of information (or the mobile entity 100 scans a passive AIB):

o AIB Id (AIB ID)

o Service name (SName)

o Service class (SCIass)

The mobile entity 100 decodes the information, adds its geographical location information and prepares the verification request message. Some of the provided pieces of information may be mandatory such as the AIB Id, and some parameters may be optional, and the mandatory parameters can be used for AIB authentication. However, it can depend on the use case which of the provided pieces of information is mandatory and which is optional.

Step S12:

The mobile entity 100 communicates with the service management entity 200 in order to validate/authenticate the AIB 50. The mobile entity 100 shall send the data as it had been received from the AIB 50 and add to it also the information about its geographical location, for example if location information is not already present in the received data. Alternatively, the mobile entity 100 may overwrite location information which is already present in the received data or may add in addition to the already present location information also information about its own geographical location The service management entity 200 checks the geographical location information and since the data received is generated from the area it controls, will continue with the validation/authentication of the AIB data and, in case the authentication is successful, returns back to the mobile entity 100 at least one of the following information: o AIB Id (AIB ID)

o Service Name (SName)

o Service address (SAddr)

o Service class (SCIass)

o Service type (SType)

o Service validity (SVal)

o Inactivity Timer (InacT) ln case of unsuccessful verification, the service management entity 200 will reject the request for authentication and inform the mobile entity 100 accordingly.

Step S13

The mobile entity 100 will receive the information from the service management entity 200 and based on the Service address will try to contact service providing entity 60 (for example through the AIB Service Gateway 30). The AIB Service Gateway 30 may act as a firewall that will allow passing only the information between the mobile entities 100 and the service providing entity 60. The same node could be also used to protect the mobile network from unwanted external access and to allow, from the opposite direction only AIB configuration data streams towards the AIBs. After connecting to the service providing entity 60, the AIB-specific service is triggered and information can be exchanged between the service providing entity 60 and the mobile entity 100.

Furthermore, steps S 7, S 8 and S9 symbolize that the service and/or network provider can provide the configuration data to the information providing entity 50, the service management entity 200 and the service providing entity 60 using terminal 20.

Also making reference to figure 2 there is shown an example of a separation of the network into different provider areas. The information providing entity 50 is located in the area of the provider of the information providing entities. The entities shown in the middle section of Figure 2 can be managed by a network provider whereas the other entities shown in the right part of Figure 2 may be managed by the service provider.

The AIBs 50 can work in transmit-only mode - there is no information sent back from the mobile entities 100 to the AIB 50. After the validity of a new AIB 50 is verified, the mobile entity 100 is using the information received from the service management entity 200 to connect to the service providing entity 60 where the corresponding AIB-specific services are enabled. The mobile entity 100 may use any of the available data transport technologies: 3.5G WCDMA/HSPA, 4G LTE, 5G, WiFi etc. The application on the mobile entity 100 handling the AIB identification and verification will also ensure automatic connection of the mobile entity 100 to the new services: depending of the nature and type of the offered services, the user might or not need to provide additional credential data (e.g. the user might have to provide the information related to an access voucher or its billing information or authorize a certain form of payment if required or simply access the service).

Exit AIBs

The "exit" AIBs 50 can identify themselves by the same AIB ID but without any other additional information. These may be also short-range (cover for example only the exit doors) and unidirectional (or half-circle) transmitters. When the mobile entity 100 detects such exit AIB 50, it will deregister automatically from the service and may erase all the related information it had stored. Alternatively, the "exit" AIBs 50 can have their own AIB ID that would need then to the verified by the mobile entity 100 with the help of the service management entity 200. Subsequently, the service management entity 200 would need to have a special AIB profile only for the exit AIBs 50 (e.g. containing only the AIB ID and the Service Name).

In case the mobile entity 100 "misses" an exit AIB 50, information related to the service may be automatically erased from the mobile entity after an activity time-out timer expires in the mobile entity 100. The same time expires in the service (e.g. the service detects that for certain time the mobile entity 100 has not actively accessed any information on the service providing entity 60 or when the mobile entity 100 is switched off - if it has been switched off intentionally or unintentionally) and the user is automatically deregistered.

Sub-AIBs

The Sub-AIBs are active or passive AIBs that are not having their own AIB ID and are used in larger areas to offer additional information to the end-user specifically related to the area where the user is located or to help the service and the user to track its path along the facility. The sub- AIBs will provide the same AIB ID and Service Name as the main in-access AIB and may comprise additional optional sub fields that could allow the user or the service to follow his path or to access in a better way the information offered by the service. Such sub-fields could be:

Name of the room/section/area

- Subject specific to the room/section/area

Location in the marked area etc.

The sub fields could be both digital information or normal alphanumeric fields. When the mobile entity 100 detects such sub-AIB, it will find out that it uses the same AIB ID and Service Name as the main in-access AIB 50 and will not go through the authentication process (no communication with the service management entity 200). The information present in the sub- field(s) could be displayed on a screen of the mobile entity, or forwarded to the service in order to trigger extra sub-services related to the smaller area marked by the sub-AIB.

Passive information providing entities, Passive AIBs

Passive AIBs may comprise similar information as the one broadcast by an active AIB but coded on a passive medium (paper, sticker, plastic tabs, posters, display image etc.). In order to prevent unauthorized access of the data, the passive AIB information can be spread on separate items, e.g. an entrance ticket would include the access-related information - the AIB ID and the validity information (e.g. on the visiting day, service can be accessed until closing time - provided that the inactivity timer does not expire), while passive markers spread around in the area may comprise the information about the identity of the service and would help the user to access information and reset the inactivity timer. The AIB validation application or program on the mobile entity 100 may be triggered if the validity information on the entrance ticket is still in force and both, the entrance ticked and the additional passive marker are scanned within a very short period of time.

The mobile entity's camera may be adapted to automatically recognize a passive AIB's coded information, it can read and decode it and contact the service management entity 200 to confirm the authenticity of the AIB 50 and continue the connection to the service as described above.

In the following the communication of the information providing entity 50 with the mobile entity 100 is discussed in more detail.

The information providing entities 50 themselves transmit no critical/classified data. They transmit service identifiers and it is the application or program in the mobile entity 100 that makes use of this information. For example, the mobile entity 100 detects an information provided by an AIB 50, triggers the verification of its authenticity and then connects to the service providing entity 60 that hosts the advertised service. In short, the AIBs 50 are "dummy" devices that advertise a series (one or more) of service identifiers. The specialized application of the mobile entity that is then responsible for the whole setup of the communication with the new services.

As mentioned in the previous section, AIBs 50 send a small stream of data containing unique AIB ID and optionally an additional small set of customizable data.

The detection of the AIB ID is what can trigger the specialized application on the mobile entity 100 to detect the rest of the information.

In conclusion, it can be said that an AIB 50 will broadcast some data that comprises the three main parts:

• a "AIB ID" which is the unique ID of the AIB and

• optinally, a set of further parameters

• optionally, a set of informational parameters.

Used also to facilitate easy routing through the network, the AIB ID may comprise a set of identifiers related to the country where the AIB 50 is operating and to the serving operator.

The AIB ID and the further parameters are the one that can be used for the AIB authentication. One example of such field is the Service Name (SName).

The informational parameters are parameters that are providing additional information, that could help the end-user to understand better what kind of service is offered. These parameters play no role in the authentication and can be for example overwritten by the equivalent information provided from the register 235 of the service management entity 200. Examples of such parameters are Service class (SCIass) - e.g. "Public interest", "Cultural", "Tourist", "Road", "Shopping", "Attractions" etc or the Service type (SType) - e.g. "Free-of-Charge (FoC)", "FoC & Paid components", "Paid service", "Subscription service" etc.

Since the information is validated by the check performed between the mobile entity 100 and the service management entity 200, it can all be transmitted unencrypted in a widely publicized format. It will be the mobile entity 100, for example its specialized application, that will ensure that the received information is verified and it is secure to proceed with further actions. ln the following the service management entity 200 is discussed in more detail. The service management entity could lie in the network provider's or belong to a central regulator authority. Its interaction with the other entities is schematically shown in Fig. 1. The functions provided by the service management entity are the following main categories:

1. traffic-related functions and/or

2. management-related functions.

The service management entity 200 may be used in traffic-related functions for the following cases:

ln-access AIB validation.

Exit AIB validation - for the case the Exit AIB will have its own AIBJD.

• AIB-service identification.

Locator function carried out by a locator unit that can be hosted in a separate node or collocated with a service management entity 200. As will be explained in more detail in connection with Fig. 3 and 4 the locator unit has the following functions:

Hide the topology and number of service management entities 200 in the home network

access gateway of service management entity 200

Mapping of AIBJD to a specific service management entity 200

Identification of a foreign locator unit

• Access Authorization (roaming agreements between the PLMNs)

The service management entity 200 may be used for the following management functions:

Central management point for:

provisioning and authorization of service management entity based systems, definition & record management of the information providing entities remote management of the information providing entities

service management of the information providing entities

Service parameters handling of the information providing entities

record owner of the information providing entities Remote administration of data of the service management entities in the HPLMN

(Home Public Land Mobile Network)

The locator unit has specific management functions:

Foreign partners service management entity Proxy management

Management of the national and roaming identifications

Fault management - Performance management - Security management.

In the following the function of the locator unit and of the service management entities will be discussed in more detail. As discussed above the locator unit can be collocated with the service management entity 250A, 250B as shown in Fig. 4 by locator units 360A and 360B, or the locator unit is provided as a separate node as shown by locator units 300A, 300B 300C or 300D in Fig. 3.

The locator units 360A and 360B of Fig. 4 or the locator units 300A -300D of Fig. 3 can be used to hide network topology of the service management entities 200, 250A, 250B and the number of the service management entities in one national network or to facilitate connection to foreign AIB- specific infrastructures and services. The locator units 300A - 300D or 360A, 360B, may analyze the AIBJD and based on its structure, or on the included location information, determine if the request is related to a home network AIB or to a foreign network one. For the home network AIBs, based on the AIBJD elements, it will identify the correct service management entity 200, 260A, 2060B and relay the validation requests.

The structure of the AIBJD can allow also the coexistence of multiple operators of service management entities in a network and also migration of AIBs between different operators. For example, two alternatives of routing will be described based on the AIBJD handling in the locator unit node:

Full AIBJD analysis and mapping - for this method all AIBJDs located in the home network are defined in a database that maps them to their corresponding service management entity 200. This method can allow easy change/move of an AIB record from a service management entity to a different one (e.g. for maintenance or transfer of ownership reasons) without performing any changes in the AIB or the AIBJD. Partial AIBJD analysis and mapping - this method requires that in the AIBJD there is a component that is tied to a specific service management entity 200. In this case, there is no need for a larger database in the locator unit but a change/move of an AIB record from one service management entity to a different one will require a new AIBJD.

From global perspective, the locator units from different countries are able to communicate to each other and facilitate access of the roamers to foreign AIBs.

Fig. 3 shows an example of such global structure and the three main encountered traffic cases:

Case 1 : UE 100A access to the home located AIB-specific services

Case 2: First UE 100D access to a foreign AIB-specific service when roaming abroad

Case 3: Roaming UE 100D access to foreign AIB-specific services after the first access was successful.

Casel

A UE 100A located in its home network detects an information providing entity such as entity 50A. As discussed above the information entity 50A broadcasts a service identifier (step S31 ) and the mobile entity 100 proceeds with the validation of the information providing entity 50A and its service identifier. The address of the locator unit 300A of the home network is pre-stored in the UE and it allows the UE to forward the verification request to the node of the locator unit 300A in the home network (step S32), in the example shown in Fig. 3 to one of the locator units 300A shown in Figure 3. Based on the identity of the information providing entity, the locator unit 300A detects the correct service management entity, here one of the service management entities 200- 1A, 200-2A or 200-3A. The locator node 300A then relays the request identified service management entity for validation (step S33).

Case2

When a UE 100D is roaming in a foreign network such as the foreign network D, it has no prior knowledge of the local address of the locator entity 300D. Information entity 50D broadcasts a service identifier (step S34). The address or identity of the home locator unit 300A is prestored in the UE 100 and it allows the UE to forward the validation request generated in response to the detected service identifier to the home locator unit 300 A (step S35). The home locator unit 300A will identify in the identifier of the information providing entity 50D the country and network identification and it will relay the request to the foreign locator entity, here entity 300D (step S36). The latter entity will relay the request to the correct foreign service management entity 200-1 D or 200-2D which contains the record of the transmitting information providing entity 50D (step S37). In the answer towards the UE 100, the home locator entity 300A includes the address of the foreign locator unit, here the address of the locator unit 300D (step S38) and the UE stores it for further use. The same situation would occur if the UE 100D were located in the foreign network C or the foreign network B. In the embodiment shown the network C does not have its own service management entities, so that the locator unit 300 C may forward the verification request one of the other networks, e.g. the network B with the locator unit 300 B and the service management entities 200-2B and 200-1 B.

Case 3

For any subsequent detection of an information providing entity such as in step S34 and as long as the UE 100D remains in the same country, the UE 100D will use the stored foreign locator unit for the verification request in step S39 that will relay the verification request to the corresponding service management entities from that network (step S 40). If the UE 100 detects an information providing entity that is registered in a different network in the same country, the already stored locator unit will facilitate the connection to the locator unit of the other network in the same way the home locator unit assisted the first foreign verification request, if no common locator unit is used for all networks.

In Fig. 4 an embodiment is shown in which a locator unit is co-located with the function of the service management entity, which was discussed above. Here the service management units 260A is belonging to network A and service management unit 260B is located in network B. Network A comprises the service management entity 250A which includes the locator unit 360A and the service management unit 260A. The service management units 260, A, B carry out the functions of the service management entities 200 discussed above in connection with Fig. 1 and 2. Network B includes the service management entity 250B which includes the locator unit 360B and the service management unit 260B. When the mobile entity 100 is located in network B and receives a service identifier from information providing entity 50B, it contacts service management entity 250A of the home network. The verification request transmitted by mobile entity 100 in step S42 includes the identity of information providing entity 50B transmitted in step S 41. The locator unit 360A in the home network comprises a register 334A where the information providing entities of the home network are stored and where the addresses of the foreign locator units are stored. The locator unit 360A determines that the service identifier was received from a foreign network, here network B. Thus, the locator unit 360A relays the verification request to the locator unit 360B of the service management entity 250B (S43). The locator unit 360B forwards the request to the service management unit 260B in step 44. The service management unit 260B checks with the register 235B whether the information providing entity is a trusted information providing entity and information is sent back to locator unit 360B (step S45) from where is forwarded in steps S46 and S47 to the mobile entity 100.

The example shown in Fig. 5 summarizes the steps when a mobile entity located in a foreign network accesses a service providing entity 60 for the first time.

In step S 51 the AIB 50 broadcasts at least one of the following information (or the mobile entity 100 scans a passive AIB):

o AIB Id (AIB ID)

o Service name (SName)

o Service class (SCIass)

The mobile entity 100 decodes the information, adds its geographical location information, for example if location information is not already present in the broadcast information, and prepares the verification request message.

In step S52 the mobile entity 100 communicates with the service management entity 200A in order to validate/authenticate the AIB. The mobile entity 100 shall send the data as it had been received from the AIB optionally with the added information about its geographical location. The service management entity 200A checks the geographical location information, and since the data received is generated from an area outside the area it controls, it checks in its register 235A the Visitor address of the service management entity 200B responsible for the area indicated in the request and it forwards the request to the service management entity 200B (Step S53). The forwarded request includes the complete information as received from the mobile entity. Here the service management entity 200A is a kind of transit node and the service management entity 200B receives the full list of parameters from the service management entity 200A. The service management entity 200B in the visited network B checks the geographical location information, and since the data received is generated from the area it controls, will continue with the validation/authentication of the AIB data and, in case the authentication is successful, returns back in step S54 to the service management entity 200A in the home network A at least one of the following information:

o AIB Id (AIB ID)

o Service name (Sname)

o Service address (SAddr)

o Service class (SCIass)

o Service type (SType)

o Service validity (SVal)

o Inactivity Timer (InacT)

In case of unsuccessful verification, the service management entity 200B will reject the request for authentication.

In case of a successful response, the service management entity 200A sends the received information and the connection address of service management entity 200B to the mobile entity 100 in step S55 including at least one of the following:

o AIB Id (AIB ID)

o Service Name (SName)

o Service address (SAddr)

o Service class (SCIass)

o Service type (SType)

o Service validity (SVal)

o Inactivity Timer (InacT)

o Address of service management entity 200B(VAIB_VRAddr)

The mobile devices store the received address of the service management entity 200B and for as long as it stays in the same network it can use that address for all subsequent queries.

In case of unsuccessful verification, the service management entity 200A of the home network will reject the request for authentication. ln step S56 the mobile entity 100 receiving the information from the service management entity 200A will, based on the Service address try to contact service providing entity 60 (for example through the AIB Service Gateway 30). The Service Gateway 30 may act as a firewall that will allow passing only the information between the mobile devices and the service providing entity 60. After connecting to the Service address/service providing entity 60, the AIB-specific service is triggered and information can be exchanged between service providing entity 60 and the mobile entity 100.

Summarizing, the locator unit as discussed in more detail in connection with Fig. 3 and 4 can:

assists the roaming users to identify the foreign locator unit,

offers flexible routing to the home network validation register(s) (VR) knows how the network of home VRs looks - how many are they, what AIB id ranges they host

handles AIB-related roaming agreements and it keep tracks of its foreign counterparts without any need to have any knowledge of the foreign VRs

can assist the network in case of AIB migration, ensure easy rerouting in case of maintenance actions on the VRs and even allow VR redundancy to be implemented.

The service management entities 200 or 250 A, B can store at least one of the following information for each registered information providing entity:

a. AIB Id (AIB ID) - e.g. a unique string of characters that are identifying the information providing entity,

b. Service name (SName) - e.g. a string of alphanumeric characters describing the service, location etc.,

c. Service address (SAddr) - e.g. the IP or other type of address the mobile entity might use to connected to the server where the service runs,

d. Service class (SCIass) - e.g. "Public interest", "Cultural", "Tourist", "Road", "Shopping", "Attractions" etc

e. Service type (SType) - e.g. "Free-of-Charge (FoC)", "FoC & Paid components", "Paid service", "Subscription service" etc

f. Service validity (SVal) - this is the period of time the user is allowed to access the service - it could be overwritten by the information sent directly by the server hosting the service. g. Inactivity Timer (InacT) - this is the period of time the user is kept logged on the service even if the service does not interact with the user at all. When this timer expires, the user's mobile entity 100 is instructed to erase the locally stored service related information and the user is logged out automatically from the service.

h. Visitor Network address of the service management entity (VAIB_VRAddr) - used in case the entity 100 is roaming in a foreign network and it need to know the address of the service management entity responsible with the AIBs present in the visited network.

For security reasons, the full management of the records of the service management entities may be performed only by the service providers. Alternatively, the AIB owners could have access to a limited configuration interface that would allow them to change non-critical information for already defined AIBs. The AIB owners shall not be able to interrogate the service management entity in order to get information about currently defined AIB's IDs or Service addresses - in other words, a AIB owner would be allowed to only change information related to known AIB IDs and SAddrs.

The AIB Service Gateway 30 (AIB_SGw) shown in Fig. 1 and Fig. 5 can act as a border gateway between the mobile network and the network hosting the Application Servers/service providing entities 60 (e.g. Internet, but not necessarily - for example it could be also a private network infrastructure belonging to a AIB Service provider).

The AIB Gateway 30 is supposed to separate the public mobile network domain from the external world or from other network domains. It will act as a firewall that will allow passing from the mobile network only traffic dedicated to service providing entities connected to the AIB infrastructure. The same node could be also used to protect the mobile network from unwanted external access and to allow, from the opposite direction only AIB configuration data streams towards the AIBs 50.

In the following, the administration of the information providing entities in the register 235A, 235B is discussed in more detail. When a service provider wants to introduce a new information providing entity in a new area, it also needs to define this specific information providing entity in the Home service management entity 200, 250 A,B which shall be able to include all the information that is needed for secure validation of the information providing entity and of the service is represents.

The service management entity 200, 250 A,B should be able to support the following activities:

1. Defining of a new AIB in the database of the service management entity 2. Removal of an existing AIB from the service management entity database

3. Change of the settings/parameters or service specific parameters related to a specific AIB.

4. Fetch the common (or sensitive, depending on the access rights of the requestor) data of a defined AIB

Due to the sensitivity of the handled information, the administration of the database of the service management entity 200 might be done by using encrypted secure channels and the database and the service management entity should be protected against malicious, illegal or aggressive actions.

When introducing a new AIB, the service management entity should be able to manage at least the following information:

a. AIB Id (AIB ID)

b. Service name (SName)

c. Service address (SAddr)

d. Service class (SCIass)

e. Service type (SType)

f. Service validity (SVal)

g. Inactivity Timer (InacT)

The a, b (optionally also d and e) are representing also information that may be originally transmitted from the information providing entity 50 and sent from the mobile entity 100 to the service management entity. The service management entity 200 will analyze the information and in case of a match will send back to the UE 100 the other related information. The check can require full match for at least the AIB ID and SName, while if the received SCIass is different than the stored one, the service management entity 200 can send back to the mobile entity 100 the stored SCIass (and mark that the service management entity is the origin of the information) that will overwrite the one received by the UE 100 from the AIB 50.

The information received from the service management entity 200 can be removed from the UE when the UE is switched off, validity or inactivity timers are expired or overwritten by a new set of information received from the same service management entity 200. ln order to prevent any possibility of fraud, the service management entity can be configured such that the sensitive information (AIB ID, Sname, SAddr, SType and SVal) cannot be changed locally on the service management entity; these parameters could be changed only by the service owner via secured links. The same is valid also for the definition of a new AIB.

In case a AIB's ownership is transferred to a different provider, the AIB may not be connected to a different service (SAddr) without having a new AIB ID allocated. In order to avoid any risks of fraud, the old AIB owner should remove the old AIB configuration from the service management entity.

The administration of the AIB could be done manually by connecting to the AIB locally or could be done remotely from the service management entity automatically when the parameters are changed in the service management entity. A new interface may be used for transferring the data from the service management entity to the AIB.

In the following a registration /deregistration to/from an information providing entity 50 is discussed. AIBs 50 can be introduced in a demarcated area or they can be installed in different locations. There should be at least two AIBs 50 for each case or a dual AIB. The two AIBs (or the dual AIB) may be used for the entry or for the exit of the user from the marked area.

The situation of using two different information providing entities is shown for example in figure 15. In the embodiment shown the information providing entity 50 is used by the mobile entity 100 when entering the area 90, whereas the information providing entity 51 is used when the UE 100 leaves the marked area 90.

Sub-AIBs can be used to mark smaller areas within the same facility. For example, in a zoo (or a Museum) it can be possible that in each room or certain section there is a sub-AIB when entry the room/section to assist the user to register and, optionally another sub-AIB at the exit from the room/section for resetting the user and remove/erase whatever information may be stored in the mobile entity 100 related to that room/section. Other options are to remove the specific information at the moment a new sub-AIB is registered, or at the moment when the mobile entity 100 detects the exit AIB 51 , or when the validity or inactivity timer expires, or when the mobile entity 100 loses its power or is switched off while being inside the marked area 90. When a user is entering the marked area 90, the mobile entity 100 will receive (or scan) the AIB's information specific to that area. That means that the mobile entity has the capability to receive, analyze and act automatically on the received information.

The AIB 50 may broadcast at least one of the following information:

1. AIB Id (AIB ID)

2. Service name (SName)

3. Service class (SCIass) - e.g. "Public interest", "Cultural", "Tourist", "Road", "Shopping", "Attractions" etc and some other information elements or minor/temporary importance.

The mobile entity 100 decodes the information and may add information about its geographical location (for example in order to let his home network understand if it is in his home country/network or it is roaming abroad) and contact via the local mobile service provider (using the applicable mobile technology -e.g. the 5G/4G/3G/2G, WiFi network) the service management entity 200, 250 A,B and authenticate the AIB 50 by using the received information.

On its turn, the service management entity 200, 250 A,B processes the information and validates or invalidates the AIB (if is safe for use or a fake one). The service management entity 200, 250 A,B can reply back to the mobile entity 100 proving at least one of the following information:

In case of a valid AIB:

o AIB Id (AIB ID)

o Service Name (SName)

o Service address (SAddr)

o Service class (SCIass)

o Service type (SType)

o Service validity (SVal)

o Inactivity Timer (InacT)

o (Visited Network address of the service management entity - VAIB_VRAddr - optional element included only in the answer to the first query when the user is roaming a foreign network)

In case of an invalid AIB:

o The request for information will be rejected The user access to the service can be terminated in few cases:

User passes an Exit AIB

The Service validity timer expires

The Inactivity timer expires

The mobile entity is switched off

An Exit AIB 51 may broadcast the same AIB ID as the ln-access AIB but no other information (the mobile entity will interpret that the SName field as empty) will be sent by the AIB. In the moment the mobile entity 100 detects such AIB, it may de-registers automatically from the service and removes the related locally stored data.

When one of the Service validity or the Inactivity timers are expiring, the mobile entity 100 may perform the same activities like in the case where it detects an Exit AIB 51.

The same activities may be performed also when the mobile entity 100 is powered down in a normal way: the UE deregisters from the service and it erases the related locally stored data before the detach is sent to the mobile network.

In case the mobile entity's battery runs empty while the user is still in the AIB-marked area, the activity timer can take care that the user is deregistered from the service. The relevant locally stored data is removed when the power is lost (data stored in the volatile memory) or it is automatically deleted when the phone is powered on again (for example when the mobile entity detects that memory area allocated for AIB-triggered services is still in use while the mobile entity is not registered to any such service).

In the following the service providing entities 60 shown for example in Fig. 1 providing the required service are discussed in more detail. The service providing entity 60 is used to manage the AIBs related to the running service(s) - i.e. add/remove/change the information related to AIBs or the information that the AIB is supposed to broadcast. As mentioned already, for security reasons, the AIB owner can have access only to the sections that is applicable with the change of data for already deployed AIBs. The service providing entity 60 will have a secure provisioning interface connected to the service management entity 200 and also a (secure) configuration interface to the related AIBs. In the same time, the service providing entity 60 can be accessed over an open interface (e.g. via Internet) by the mobile entities 100 that are registering to the hosted service.

In the following examples of services available with the above discussed technology are discussed in more detail.

On- site museum experience

In the new digital era, a museum can advertise its presence and content on Internet but visiting a Museum's Internet site does not replace the experience of an actual visit.

On the other end, the kind of information a visitor can receive when being inside a museum is limited to the information presented next to the exposed items or in the audio-visual equipment that might be present on the site (the visitors can get headsets that they can connect to special audio ports next to the most famous items or read the information listed on a digital screen placed also next to such famous items.) The problem is that such facilities are requiring additional investments in high tech equipment from the museum and the access to such information is limited - only few visitors can access the screens or the audio ports related to really famous items since people tend to stay longer in such area. Additionally, the museum or the visitors have no possibility to offer real-time information about how crowded a certain area around items of interest is. On the other hand, when a guide is used a group of visitors have to stay together around the guide in order to hear and see the items presented by the guide or to be sure that they do not get lost from the main group.

The new enriched on-site museum experience can offer a museum visitor the freedom and instant access to the information he or she is interested in is available. Personalized digital guided tours can be programmed that could lead an individual to certain popular items based on information it can receive about how crowded the areas are. Augmented reality applications directly connected to the service can offer to the visitor the additional multimedia information he or she wants (e.g. the history of the item, about the author, about the era it has been created etc.). A member of a group of visitors can walk around and have his or her own digitally guided tour without fearing of getting lost from the rest of the group - the members of the visiting group will become part of the same community that the application server can track around the museum and raise flags to the "lost" members when the majority is approaching the exit area. Each member of the group could create their own digitally guided tour or select one of the predefined ones.

In the same time, the museum can offer additionally paid services: e.g. a visitor can download a "story" or his/her tour to the mobile entity 100 and review it at home or show it to the friends. Furthermore, it can offer a visitor the opportunity to download high resolution images of the interesting items or stories related to certain items. Otherwise, in a moment a visitor exits the museum - it passes the Exit AIB - or if the membership to the service becomes void due to timeout, is it is automatically unsubscribed from the service and all the data he/she was using in the mobile entity 100 is removed.

Zoo park

A zoo park can be visited to watch animals: how they behave in their area, how they are feed, if they got new cubs or how are they interacting with the visitors. The visitor read some information about their natural habitat and their normal way of life.

The Enhanced life zoo park service will offer the visitors much more information: the service will launch multimedia files about the animals selects by the visitor with the mobile entity's camera and visitors can see how an animal haunts its pray in its natural habitat or how it takes care of its cubs or about many other aspects of its normal life. Pointing the camera towards a specimen will offer the user to download high definition images of that animal (e.g. this could be an additionally paid service). It will be possible for the visitor to access information about the history of each specimen present in the zoo: its age, how it got to the zoo, area of origin and so on.

In the same time a family coming together to the zoo is registered together as a group. Special tracking devices could be used that are paired with the group and that can be tracked through the area of the zoo: the parents will never lose they kids around a zoo and a kid will be able to find his/her parents - homing function activated locally or remotely on the device will instruct the device to offer the kid audio information about the position of the parents or will give the parents information about the location of the kid.

In a big place like a zoo park (but could be also in an attraction park, a shopping mall or any other places) additional services could be also offered, e.g. finding your friends around (with the accept of the other party) - the service can offer information where your friends can be found and what the optimum path to meet them - the friend might be asked to point their camera to the closest identifiable subject (an item, a shop, an animal, a park attraction or towards a standard marker - standard markers could be for example QR (Quick Response) Code stickers placed at regular distances within the premises of the AIB-marked area).

Attraction park in a pocket

In the same way as in a zoo, when a visitor is in an attraction park it is difficult to know how long the visitor has to wait to ride an attraction or in a queue to get a quick lunch.

With the "Attraction park in a pocket" service, the visitor could get real time information related to the waiting time to his favorite rides, the user could mark his main favorite attraction points and the new service might offer information about the best path through the park, it can reserve quick passes to these rides or let the visitor know when the current queue is below a certain preset threshold. Additionally, the service could offer additional information about a ride: the story behind, the technical and historical facts or any other useful information. It can also offer the visitor information about other attractions that were not selected among the favorites.

The visitor can "tell" the new service when he or she want to have a quick lunch and the service could offer information about the restaurants or the fast food places around the park, mark the closest ones and add information about the waiting queues, reservation options and the offered menu.

In the same way as in case of the "Zoo Park", tracking/homing mobile entities 100 can be offered on demand for the small visitors or the option to track a family or group (e.g for group visiting the park or teenagers with different interests than younger siblings) or find out if friends are also present in the park and where. Shoppinq experience

Shopping can be a difficult and time consuming task. The alternative of on-line shopping works for some people but it is not the key of the success in all occasions and the only time saved is the one related to a trip to a shopping mall.

The proposed solution can simplify the real life shopping experience: when the user enters a shopping mall or a main shopping street, the in-access information providing entities 50 could register the mobile entity 100 to a new service that will offer the user an overview of all shops present in the marked area, it will request a list of the searched items and some additional information that could help it to target the most suitable shops for the user (e.g. user's clothing sizes). The service can offer a list of alternatives and then lead the users to the most optimal path to these shops.

Additionally, in order to attract customers, shops could use the service to advertise their current offers or new items. The user can also look for the closest restaurants in the area and the service can offer him or her information about the menu and day offers.

As in the case of the previously described service, finding a friend could be also a possible option.

On top of these, the user can have the freedom to provide feedback about his or her experience and the quality of the received services.

Enhanced road trip

With the (semi-)autonomous cars coming or for the passengers in a normal vehicle, driving long or sometimes the same distances can be a boring experience. On top of that, finding information about the points of interest along the road it is most of the time a problem and even after finding them, most of the time the available information is not actual or complete.

A Digitally enhanced road trip service will automatically subscribe the intelligent car (if applicable) and its passengers and driver to a service that would be able to offer information about any points of interest along the road, updated road and traffic information or other news related to that specific road (e.g. weather warnings, road works, cars driving on the opposite lane etc). An intelligent vehicle can query the service for the closest tank or service station or one with attractive prices. The same kind of information could be also offered to the driver in the moment he or she signals (voice activated command) to the service that the vehicle needs fuel or other service. Traffic or roadworks related information could be sent directly to a paired navigation system and warnings could be sent to the multimedia display of the car.

In the same way the driver signals the vehicle needs fuel, he or she (or another passenger) could inform the service it wants to make a break (or alternatively, the service could warn the driver that is already driving too long and it needs a break) and visit something or have something to eat - the service would present possible point of interest alternatives within short driving range, restaurants on the road or not so far from the road (including their rating, type of menu and options for online reservation).

As in the previously presented services, the driver and the passengers could rate the quality of the services or share their impressions (those would become available to other people that will drive (or currently driving) on the same road.

Such service is an example of a possible service that would be free for the participants on the road but that could get a constant revenue from the companies that want their presence advertised on that road.

Participation to sport events

When participating at a big sport event in a large stadium, that takes place simultaneously on many locations or a race that takes over a long distance (e.g. marathon, car race, decathlon, heptathlon or other similar contests), a spectator cannot always follow the action all the way through, all the games, probes or races he/she is interested in or his or her favorite sportive(s) all the way through the event.

An in-access information providing entity 50 placed at the main access point would automatically register a mobile entity 100 to a service that would allow the end user to request instant action replays, info about other ongoing events, follow his or her favorite players through a game or a race or other similar actions so that the user remain informed about the latest status independent of his place on the course of the competition (e.g. follow your favorite car or runner even if it is acting kilometers far away from his present location).

In the same time, a service would allow the end-user to find facilities around the competition, receive information about other "hot" events that that place at the same competition or help the end-user to find his friends or relatives that are attending the same event in the same time.

For instant action-replays and live pursuit of the players, the information could be feed real-time to the service through flying drones that are automatically following the players or the game/race.

4 My's": My street, My Neighborhood, My City, My Life

Sometimes it is difficult to stay informed about the life of the community you are living in, independently if this is about the street where one lives, the neighborhood or the city. One hears people talking about cultural or charity events, street or neighborhood parties, one wants to stay in contact with the other parents from kids' school or know when the school or neighborhood is organizing local events. Normally one hears about all those things after they are gone.

In the same time, a community wants to attract new members, people that can maybe play some active role in the life of the community, contribute to the value of the community, making the area more attractive and please to live in. Generally, people like to be together, to stay in contact and socialize (not only online) and everyone wants to integrate as quick as possible in an area he or she just moved, find new potential friends or ways how to spend the time not far from home.

A service like "4 My's" could facilitate all this: people living in a certain area subscribe to it and get information about the life of the city, or the street or of the neighborhood. Organizations located in the same area (schools, clubs, shops, authorities like police, fire department and municipality) could offer information of common interest or advertise new events. People connected to a certain organization like clubs or schools could form easily subgroups and start sharing information among themselves or for the other interested members of the community. This is another service that could be also offered free to the users and it might get revenues from the organizations registered in the service, or it may be subsidized by the local authorities in order to promote a better quality of life in the selected area.

Upon the secure validation, the user shall be able to receive an information about this information providing entity 50 and from this point the user shall be able in real time to transmit/request/receive or transmit any information that is connected to the user group of the identity of the information providing entity 50.

Figure 6 summarizes some of the main steps carried out by the mobile entity 100 when the service running entity is accessed. In step S61 the service identifier is determined from the information providing entity 50. As discussed above the service providing entity can be an active or passive entity. When the service providing entity broadcasts the information, the service identifier is received in step S61 by the mobile entity 100. When the information providing entity is a passive entity the mobile entity actively determines the service identifier e.g. scans the corresponding marker. In step S62 it is checked whether location information of the information providing entity is present in the received service identifier. If this is not the case the location of the mobile entity 100 is added in step S63.

If the location is already present or was added in step S63, the data as received from the information providing entity may be included in the generated verification request which is transmitted to the service management entity 200 in step S64. Alternatively, the location information may be added, overwritten or supplemented with location information of the mobile entity 100. In this request the mobile entity 100 requests whether the information providing entity is a trusted information providing entity. In step S65 the mobile entity receives the confirmation response from the service management entity 200 and if the confirmation response is positive, meaning that the information providing entity is a trusted entity, the mobile entity can access the service providing entity in step S66.

Figure 7 summarizes the steps as seen from the service management entity 200. The service management entity receives the verification request which was transmitted by the mobile entity 100 in step S64 (S71 ). In step S72 the service management entity 200 accesses the register 235 where the identities of the different information providing entities is stored. The register 235 may be part of the service management entity 200 or may be a separate element (not shown). It is checked in step S73 whether there is a match between the identity information stored in the register with the identity present and optionally the service name in the verification request. If this is not the case the mobile entity 100 can be informed accordingly in step S74. In this embodiment of figure 7 it is assumed that the information providing entity 50 is an information providing entity that would be managed by the service management entity 200 to which the verification request is transmitted. The case that the information providing entity is an entity located in a foreign network was discussed above in further detail in connection with figures 4 and 5. Returning back to figure 7, if there is a match between the identity and optionally the service name present in the verification request and the identity stored in the register 235, the address information of the service providing entity is determined in step S75 and the address information is transmitted to the mobile entity in step S76.

Figure 8 summarizes some of the steps carried out by the locator unit such as the locator units 300A to 300D or 360A 360B disclosed in figure 3 and 4 respectively. In step S81 the locator unit receives a verification request from a mobile entity 100. In step S82 it is determined to which network the information providing entity 50 contained in the verification request belongs. This may be done based on location information comprised in the received verification request or based on the service identifier of the information providing entity comprised in the verification request. If the information providing entity and its service identifier belongs to the home network, the service management entity responsible for managing the different information providing entities is determined in step S84 and the verification request is relayed to the service management entity identified in step S84 (optionally the location information may be removed from the relayed verification request since it was needed to identify the service management entity in step S84 and is not used by the identified service management entity anymore). If it is determined in step S83 that the information providing entity does not belong to the home network, the foreign network to which the information providing entity is determined in step S86 and the verification request is relayed to the locator unit in the foreign network in step S87.

Figure 9 shows a schematic architecture view of a mobile entity 100 which is involved in the different embodiments as discussed above. The mobile entity 100 comprises an interface/tranceiver 1 10 which is provided for transmitting user data or control messages to other entities and for receiving user data or control messages from other entities. The interface/tranceiver is especially qualified to receive the service identifier from the information providing entities 50 and to transmit verification requests towards the service management entity 200. The interface/tranceiver is furthermore used for accessing the service providing entity 60. The mobile entity furthermore comprises a processor 120 which is responsible for the operation of the mobile entity 100. The processor 120 comprises one or more processing units and can carry out instructions stored on a memory 130, wherein the memory include a read-only memory, a random access memory, a mass storage, a hard disk, or the like. The memory can furthermore include suitable program code to be executed by the processor 120 so as to implement the above described functionalities in which the mobile entity 100 is involved.

Figure 10 shows a schematic architecture view of a service management entity 200 which checks whether the information providing entities are trusted information providing entities. The service management entity 200 comprises an interface/tranceiver 210 provided for transmitting user data or control messages to other entities and for receiving user data or control messages from other entities such as the entities shown in Figures 1 to 5. The interface/tranceiver is especially qualified to receive the verification request from the mobile entity or the requests relayed from locator units as discussed above. The service management entity comprises a processor 220 which is responsible for the operation of the entity 200. The processor 220 comprises one or more processing units and can carry out instructions stored on a memory 230 wherein the memory may include a read-only memory, a random access memory, a mass storage, a hard disk or the like. The memory 230 furthermore comprises the register 235 where the identity information of the plurality of information providing entities of the local network are stored. The memory can furthermore include suitable program code to be executed by the processor 120 so as to implement the above described functionalities in which the service management entity is involved.

Figure 1 1 shows a schematic architecture view of a locator unit 300 which assists the users to identify the correct service management entity or the correct locator unit. The locator units 300 comprises an interface/tranceiver 310 which is provided for transmitting user data or control messages to other entities and for receiving user data or control messages from other entities. The interface/tranceiver is especially qualified to receive the verification request from the mobile entity or forwarded from other foreign locator units. The locator unit 300 furthermore comprises a processor 320 which is responsible for the operation of the locator unit 300. The processor 320 comprises one or more processing units and can carry out instructions stored on a memory 330, wherein the memory may include a read-only memory, a random access memory, a mass storage, a hard disk or the like. The memory can furthermore include suitable program code to be executed by the processing unit 320 so as to implement the above described functionalities where the locator unit is involved. The memory furthermore comprises the register 335 where the information providing entities of the home network are stored and where the addresses of the foreign locator units are stored. The register furthermore includes information of the different service management entities in case several service management entities are provided in a single network.

Figure 12 shows a further example of a mobile entity which can carry out the functionalities of the mobile entity 100 discussed above. The mobile entity 400 comprises a module 410 for determining the service identifier. The module 410 may receive the service identifier as a broadcast message or in case of a passive information providing entity the module is able to determine the service identifier, e.g. by decoding it from a code encoded onto a ticket or any other place. Furthermore, a module 420 is provided which is configured to add location information of the location of the mobile entity where the information providing entity was detected. This module may add, or overwrite, or supplement location information, for example if location information is not already present in the received service identifier. A module 430 is provided for transmitting the verification request to the service management entity and for receiving the response. Furthermore, a module is provided for accessing the service providing entity based on the address information contained in the received confirmation response.

Figure 13 shows a further embodiment of a service management entity 500 which can operate as the service management entity 200 or 250 discussed above. The service management entity 500 comprises a module 510 for receiving the verification request from the mobile entity. A module 520 is provided for accessing the register in order to check whether the information providing entity for which the information is received is a trusted information providing entity. A module 530 is provided for matching the identity stored in the service management entity 500 with the identity contained in the verification request. A module 540 is provided which determines address information of the service providing entity when there is a match between the data stored in entity 500 and the received data. Furthermore, a module 550 is provided for transmitting the confirmation response with the determined address information to the mobile entity. Figure 14 shows a further example of a locator unit 600 which can operate as the locator units 300 discussed above. The locator unit 600 comprises a module 610 for receiving the verification request from the mobile entity. In module 620 it is determined to which network the information providing entity and the corresponding service management entity belongs for which the verification request is received. A module 630 then relays the verification request to the foreign locator unit in case that the service management entity and the information providing entity belong to a foreign network. If they belong to the home network, the module 630 for relaying the verification request relays the verification request (with or without location information) to the service management entity of the home network.

From the above said some general conclusions can be drawn.

As far as the mobile entity 100 or 400 is concerned, the mobile entity determines whether the location information is present in the service identifier received from the information providing entity by which a position of the information providing entity can be determined. If this is not the case the location information is added to the service identifier.

However, when the location information is present in the service identifier, the verification request is transmitted to the service management entity with the location information as received from the information providing entity.

It is possible that the received confirmation response comprises additional service information data and the service identifier determined from the service providing entity comprises further identification data. The mobile entity then only accesses the service providing entity 60 when there is a match between the additional service information data and the further identification data.

The accessing of the service providing entity 60 can be terminated when a further service identifier is received and when the information providing entity identified from the further service identifier is the same as the information providing entity identified in the service identifier. Furthermore, it is possible that the access to the service providing entity is terminated when a validity of the service provided by the service providing entity has expired or when an inactivity timer has expired. Furthermore, it is possible that a second service identifier is received from a second information providing entity from which the mobile entity deduces that it will stop using the service from the service providing entity 60. The mobile entity 100 then terminates to access the service providing entity 60 in response to receiving the second service identifier. To this end it can be checked whether the second service identifier corresponds to the first service identifier, which is the service identifier received before the service providing entity is accessed. When there is no correspondence between the two service identifiers the verification procedures is started again and a second verification request is transmitted to the service management entity 200 in which it is requested whether the second information providing entity from which the termination request is received is a trusted information providing entity. The second verification request comprises the identity of the second information providing entity. The mobile entity 100 receives a second confirmation response from the service management entity 200 in response to the second verification request and the second confirmation response informs the mobile entity that the second information providing entity can be trusted. The access to the service providing entity is then only terminated when the second confirmation response is received. Such a situation was discussed in connection with Figure 15 where different information providing entities 50, 51 are used at the entrance and exit of the marked area.

The verification request transmitted to the service management entity can be triggered when the service identifier is detected by the mobile entity.

When a second service information comprising a second service identifier is received from a second information providing entity and the second service identifier corresponds to the service identifier received from the information providing entity, no verification request is transmitted towards the service management entity and it is possible that parts of the second service information is displayed on the mobile entity.

The mobile entity 100 can furthermore store the address information of the locator unit which forwards the verification request to the service management entity and the verification request can then be transmitted to the locator unit based on the stored address.

When the mobile entity 100 belongs to home network and when an address of a locator unit of a foreign network is received, the address is stored in a mobile entity and as long as the mobile entity is located in the foreign network, the verification request is transmitted to the locator unit of the foreign network.

As far as the service management entity 200 is concerned, the service management entity may receive a second verification request which requests whether a second information providing entity from which a termination request is received is a trusted information providing entity, wherein the verification request comprises the identity of the second information providing entity. The service management entity 200 then accesses a register 235 where the identity information of the plurality of information providing entities is stored and it determines whether the identity of the second information providing entity present in the second verification request matches with the identity information stored in the register 235 for the second information providing entity. If this is the case the service management entity 200 transmits a second confirmation response to the mobile entity 100 and the confirmation response informs the mobile entity 100 that the information providing entity is a trusted information providing entity.

When the service management entity 200 manages the information providing entities of a home network it determines whether the verification request received from the mobile entity 100 is a verification request received for one of the information providing entities of the home network. If this is not the case, it determines a foreign network to which the information providing entity for which the verification request is received, belongs and an address of a foreign service managing entity is determined which manages the information providing entities of the foreign network. The received verification request is then transmitted to the service management entity of the determined foreign network and the address of the foreign service management entity is transmitted to the mobile entity. In the example mentioned above the functionality of the locator unit is incorporated into the service management entity as discussed in connection with figure 4.

It may be determined whether the verification request is received for one of the information providing entities of the home network by deducing it from the identity of the information providing entity or from the location information.

The received verification request from the mobile entity 100 can additionally comprise a name information of the provided service and a service class information informing about the service class of the provided service. It is then determined whether the name information and the service class information present in the verification request matches the name information and the service class Information stored in the register 235 for the information providing entity. The confirmation response may only be transmitted to the mobile entity 100 when at least the name information and the confirmation response matches the information stored the register. When the service class Information stored in the register 235 does not match with the service class information sent in a verification request, the service class Information stored in the register is transmitted to the mobile entity together with the confirmation response.

It is possible that two service management entities are used in one network. The identity comprises a verification request can comprise a section allowing the service management entity in the network to be determined. The service management entity is then determined based on the section of the entity and the verification request is transmitted to the service management entity determined based on the section of the identity.

The changing of information provided in the register for one of the service management entities 200 may only be allowed when the service management entity is accessed via a secured link.

Furthermore, the service management entity may add a new information providing entity with identity to the register. Furthermore, it may remove an existing information providing entity from the register or it may change the identity for one of the information providing entities of the register.

As far as to locator unit 300 is concerned the locator unit can additionally transmit the address of a foreign locator unit to the mobile entity and when it is determined that the verification request is received for the service management entity of the home network, the verification request is relayed to the service management entity of the home network. Furthermore, it is possible that at least two service management entities exist for the home network. The identity comprised in the received verification request then comprises a section allowing the service management entity in the home network to determined and the service management entity is identified using the section of the identity in received verification request and the verification request is relayed to the service management entity determined based on the section of the identity.

As discussed above the present application describes a new mechanism that allows a full immersion of the mobile entity 100 in a completely new area of digital services independent of the fact whether it is roaming in the home network or abroad. The information providing entity 50 marks a specific area and provides basic information to the user's mobile entity 100 that allows the mobile entity to securely connect to a service that is relevant for the marked area. A mechanism is provided that can map securely the information provided by the information entity to any kind of service and that can provide all kind of information to the end-user. The service and the information providing entities are administrated and managed centrally so that the owner of the service providing entity can change and enhanced the content at any moment. The application provides a global new world of digital services where the owner of an AIB could administer different address information without the need for affecting the user. When an address of a service providing entity has to be changed, it is only necessary to change the address in the service management entity. Furthermore, a higher security is provided as the user of the mobile entity can determine whether the information provided by the information providing entity can be trusted or not

The mechanisms described above opens and a new source of possible revenues as the new range of services could be both free of charge paid through admission fees and triggered only by the information providing entity, entity access of the area. A service provider can define the area in which the service is provided and access to the information and service is provided as long as the mobile entity stays within the designated area. When the mobile entity passes and exit information providing entity, the mobile entity will be automatically deregistered from all the services and access to the information be denied. By doing so it is awarded that the services are overloaded and in the same time people are triggered to return to the location.