Method for automatic generation of telecommunication terminal active profiles

The invention relates to telecommunications terminals and more particularly to mobile terminals, in particular when they are equipped with access interfaces to multiple networks (for example Ethernet, wifi, GPRS, blue tooth, etc.).

The invention relates more specifically to the creation and management of profiles or preferences for use of the terminal, adapted to the capacities of the latter, consisting in the adoption of parameters which are best suited to the environment of the terminal as well as to the different wishes of users and the system administrator associated with the terminal.

A number of configuration means or choice of profiles have been proposed for different types of telecommunications terminals.

Thus, the Cisco ACU makes it possible to configure several profiles for access to networks through a wireless card. It does not support the selection of the card, if several cards are present the system tries to associate them all, since the profiles defined in the ACU are specific to a card. Automatic selection of profiles is possible (this is an option) knowing that the rules governing the selection of a profile are as follows.

By default, it tries to join the last known network. It listens to the network and if an SSID is announced, it chooses the profile that corresponds to it. If several profiles have the same SSID, no rules are given for choosing a particular WLAN. Finally, it tests the different profiles one after the other.

For storage and processing associated with user and application profiles, Windows systems (Windows XP) use a proprietary mechanism: the registry.

The Windows registry is a set of keys organized in a tree structure. There are several main branches, the main describing: the configurations of the local machine and the user configurations organized in profiles.

Each branch of the tree and each key use a list of access rights to manage the modification and reading rights of each sub-branch. Thus it is possible to authorize or prohibit a user or a group of users write access to a branch or to a specific key. A mechanism of inheritance of authorizations makes it possible not to maintain a list for each element of the tree.

A key can be defined in several places of the tree. In this case, the application that uses the key will choose the location of the tree it consults. If it consults several places in the tree, it is the user's branch or the last consulted branch which gives its final value to the key.

In the mechanism of the registry, it is therefore the access rights mechanism (ACL) which will determine the active value of a key and it is the applications which must implement a complex interface to manage them. In addition, each application having its own registry access policy, it is very difficult for an administrator to configure a fleet of machines with key values ​​which can be either default values ​​or values ​​imposed on the users. Indeed, one cannot impose on an application a mode of consultation of the registry, each application has its own mode of operation.

Unix systems do not have a registry, however the file system used to describe preferences and configurations is more complete than that of Windows systems. Thus, it is common to provide configuration files at the system level which give default values ​​that the user can modify by placing a configuration file within his directory. Only the values ​​actually entered in the user configuration file will be modified compared to the system default values.

The administrator can optionally configure an application so that it only accepts certain modifications from the user, but this depends on the application. On the other hand, it can prohibit any modification on the part of the user by playing on the access rights to the files.

This mechanism corresponds to the filtering rules that we use for the proposed parameters, the fixed parameters working for their part differently.

In the specifications TS 222.240 and TS 23.241 of 3GPP the notion of Generic User Profile (PGU) is treated. This PGU is a collection of data stored and managed by different entities such as User Equipment (EU), the mother network and the visited network. It affects the way users use the different services offered (circuit switching, packet switching, etc.). The 3GPP PGU is composed of a number of "User Profile Components" (CPU). An individual service may use a subset of CPUs from a PGU.

A PGU can contain several pieces of information such as general information on the user (name, postal code, etc.), the services to which the user has subscribed, private data, terminal characteristics, etc.

The specifications of the WAP user Agent Profile (UAProf) deal with the terminal identification classes and information preferences. These classes generally contain the hardware and software characteristics of the terminal as well as information on the network to which it is connected. The User Agent profile (PAU) contains information used for formatting content.

A PAU is different from a User Preference Profile (PPU). The latter contains information relating to applications. For example, a PPU can indicate whether the user is interested in receiving cinema programs, and if so, information for each film. The UPP specifications go beyond the UAProf.

The CC / PP framework is another mechanism for describing the capabilities and preferences associated with users and user agents who access websites. In this case too, the information may contain software and hardware characteristics, but it also includes, preferably for applications and users. The CC / PP framework tries to provide the terminal with the information necessary to best adapt the content and delivery mechanisms, taking into account the capacities and preferences of the user and agents.

The SOC 2003 publication presents in a very general way a framework which assumes that administrators, users and applications can have preferences and it proposes to take these preferences into account for the selection of interface. However, it remains silent on how to represent them (the precise content of the preference profiles) and combine them to make them usable by the system.

Windows XP, like other systems on the market, supports automatic detection of interfaces, which allows the system to react when connections (network cards) become available, or on the contrary, unavailable. In other words, when the link state changes, when several interfaces are active simultaneously, Windows WP sets up several default routes in the routing table. User intervention is required to obtain a mobile terminal in communication state. There is no automatic profile selection depending on the environment, the system only applies.

In the case of Linux, and more precisely with the Mobile IP for Linux (MIPL) implementation of mobile IP, it is possible to associate priorities with the different interfaces of the terminal. These properties are stored in a configuration file and cannot be modified without user intervention.

Nokia PCMCIA D211 cards which support both 802.11, GPRS and GSM-HSCSD, do not automatically change the connection type. On the contrary, Nokia prefers to leave the initiative of connection change to the user: the latter choosing the type of connection using personal network profiles.

The object of the invention is to propose a system which makes it possible to automatically and dynamically create a profile of use preference, optimal for the given configuration of a mobile terminal, without intervention to be carried out by the user so that the terminal is configured in the best operating mode corresponding to the environment.

For this, we propose, in accordance with the invention, a set for setting up an active profile of a telecommunications terminal consisting of a series of operating parameters of the terminal, the set comprising means for storing a plurality of profiles among which profiles desired by one or more users, profiles desired by a terminal administrator, as well as the profiles desired by one or more applications capable of being implemented on the terminal, characterized in that the module comprises means for extracting, among these different profiles, a part of them as a function of the user (s) present and of the application (s) implemented, and of the means for selecting, from among the parameters of the different profiles thus extracted, a series of parameters and build an active profile of the terminal from these parameters.

Other characteristics, objects and advantages of the invention will appear on reading the detailed description which follows, made with reference to the appended figures in which:<ul id="ul0001" list-style="dash" compact="compact"><li>Figure 1 is a block diagram representative of a first embodiment of the invention;</li><li>FIG. 2 schematically represents a profile request sent following an alert;</li><li>FIG. 3 schematically represents a process for identifying the battery level;</li><li>Figure 4 schematically shows a user notification process in progress;</li><li>FIG. 5 schematically represents a sequence for processing a profile retrieval request (RRP).</li><li>FIG. 6 represents an organization of selectable parameters for an active profile.</li></ul>

In Figure 1, three types of actors are shown relating to the system.

We find first the administrator of the system 10, then the users 23 of the latter, and finally the applications 30.

They intervene at different levels for the creation of profiles. In fact, an application has predefined profiles, which are stored in a database 40 when the latter is installed. They may be modified by updates to the application in question.

The administrator predefines preferences for using the system.

The user 20 also predefines rights of use, but it is he who can change these preferences most often because he is the user of the system.

The profile database 40 stores all of the profiles in the system. We therefore see that it is appropriate to identify each of these profiles in order to use them wisely. A profile is, in the case described here, an XML file composed of a header and a body.

It is the header that will identify the profile in the profiles database.

This part ensures the uniqueness of the profile. In fact, there cannot be two profiles with the same header in this system. The identification is composed as follows.

It first includes a type of profile. This indicates the nature of the profile (for example preference profile, flow profile). It also includes a context. This field provides information on the battery context for which this profile is defined. There are four possibilities: sector, 100%, 50%, 25%.

Finally, it includes an author part. It allows to designate the author of the profile, as well as the scope of this profile.

We will now detail the scope of the profiles according to the authors, including the administrator 10, the users 20, the applications 530.

An administrator 10 can create different profiles according to the scope he wants to give to the latter. It will be able to refine these choices for certain users 20 and / or certain applications 30.

The profile can target any user and any application: this profile allows the administrator 40 to create a set of parameters general to the system. This profile will apply to all users and all applications.

The profile can target any user and an application. This profile allows the administrator 10 to create a set of parameters dedicated to an application 30 but valid for all the users 30 of the system. In this case, we will find the name of the application 30 concerned by these criteria.

This profile can target a user and all applications: this profile allows the administrator 10 to create a set of parameters dedicated to a user 20 but valid for all the applications that he will use. In this case, we will find the user ID of the user 20 concerned by these criteria. The identifier will be its login name to the system.

This profile can target a user and an application: this profile allows the administrator 10 to create a set of parameters dedicated to an application 20 valid for a user 20 of the system. In this case, we will find out the name of the application 30 as well as the identifier of the user 20 concerned by these criteria. The identifier will be its login name to the system.

Each user of the system is able to create their own Resource and Preferences Profiles (PRP). He may therefore have different wishes from the administrator 10. The user 20 is referenced by his login name to the system.

The user profile can target all applications. This profile allows the user to create a set of parameters dedicated to all of the system's applications.

The user profile can target an application. This profile allows the user to create a set of parameters dedicated to an application. In this case, we will find the name of the application concerned by these criteria.

In the case of a so-called intelligent application, the latter may have a profile formed by a set of criteria defining its operating mode. In this case, the parameters are stored in an XML file called application PRP. The illustration may be the level of security required for an application for consulting bank accounts on the Internet. This level is high. The application 30 is referenced by its name.

There is also a default profile here. The three system actors capable of creating specific PRPs, may not fill in all the fields in the XML file. There is a default file, defined by the system itself, which contains all the default values ​​for the PRP parameters. In this way, the administrator, the user, or the application may not fulfill all the criteria. This profile is populated by the header "system for any user and any application".

We call preferences the set of parameters stored in the body of the XML file making up the profile. Each parameter has a mandatory attribute, which indicates its status: "proposed or fixed". This attribute is essential for the creation of an active profile.

In addition to a profile manager, the function of which will be detailed below, the device in FIG. 1 also includes a battery alert system 60. This battery alert system 60 makes it possible to indicate to the profile manager 50 the battery status. This system notifies the manager 50 each time a threshold is reached. There are four thresholds:<ul id="ul0002" list-style="dash" compact="compact"><li>sector: the terminal is connected to the sector;</li><li>100%: the terminal is not on the mains and the battery is full;</li><li>50%: the battery is half empty;</li><li>25%: the battery is weak.</li></ul>

In addition, a user notification system 70 makes it possible to indicate to the profile manager which user 20 is currently connected to the terminal.

The profile manager 50 is the component which will generate, for each application 20, the profile containing the optimum parameters in relation to the different wishes of the actors of the system, but also in relation to the state of the battery, as well as to the applications 30 running. The generated profile is then the active profile.

We have just seen that the actors of the system can create a certain number of profiles which are stored in a database of profiles 40.

It should be possible to extract the value of a parameter which will be retained, among this set of values. We will now describe the active profile selection mechanism, which takes place here on the basis of a preliminary selection of the profiles to be filtered, followed by an establishment of the hierarchy of parameters, then the implementation of filtering rules in order to proceed with the creation of each active parameter, in order to generate the active profile.

For this, the system (and the process) needs to know the best criteria for creating the active profile.

The manager 50 will request the profiles corresponding to the following criteria: the connected user, the state of the battery, as well as the applications running. Then, for each application, it will create the active profile.

The alert systems allow the active profile manager 50 to be informed of the state of the battery (alert system 60) of the person currently connected to the terminal (alarm system 70), as well as of the applications in running (alert system 80). The profile manager 50 is informed by XML messages, such as that shown in FIG. 2.

These messages or notifications by daemons are independent of the active profile selection mechanism. They can intervene at any time.

In accordance with the representation of FIG. 3, the daemon, constituted by the battery alert system 60, will regularly read the battery level system file (/ proc under linux), and will send an alert message to the manager profiles 50 as soon as a threshold is reached.

In accordance with FIG. 4, the daemon is constituted by the notification system of the current user 70, will regularly read the file of the connected users and then sends an alert message to the profile manager as soon as the user changes. Here is the notification sequence for a new user.

When an application is launched, it notifies the profile manager 50 of its launch so that it updates its list of "applications in progress". When an application 30 ends, it also notifies the profile manager 50.

The XML database 40 stores the different profiles defined by the various actors in the system. It does not classify between the different contexts. It is therefore necessary to retrieve the desired profiles according to the connected user, the battery level, and the applications running.

The database 40 is therefore composed here of a storage part 40 and a Profiles Extraction Module 45 (MEP).

MEP 44 receives a Profile Recovery Request (RRP) sent by GP 50. As soon as this request is received, MEP 44 analyzes it (Figure 5). First, it retrieves all of the profiles whose context is given in the RRP. Then it filters and retrieves only the profiles belonging to the following categories: default profiles, administrator profiles for all users and all applications, administrator profiles for the user given in the RRP and all applications, user profiles given in the RRP and all applications, profiles of each application running.

As we have expressed above, the profile manager 50 is notified of changes in the environment by the user alert systems 70, battery 60, and launched applications 80. It therefore knows the user 20 connected, as well as the battery level available in the terminal.

In this way, the profile manager 50 will retrieve all of the profiles having for context the indicated battery level, including among these, the profiles for all the users 20, those of the user being connected, as well as those of applications 30.

The profile manager 50 will therefore not retrieve the profiles dedicated to the “Athéo” user if it is the “trum” user who is connected.

The profile retrieval request (RRP) is analyzed by the profile extraction module 45 from the database 40. Once this request has been analyzed, the database 40 provides the requested profiles to the GP 50.

An active profile is a profile (PRP), the parameters of which are applicable to a user for a given application. These parameters are the result of a filtering, which will be described below, carried out between all the parameters of the profiles relating to the user 20 considered and the application 30 considered.

An active profile here has an identification identical to the other profiles, but with an author part "created by the system", for "a user and an application". the name of the application and the identifier of the user concerned by these criteria are filled in by the system at the time of creation.

The system will therefore create as many active profiles as there are applications 30 running.

The hierarchy of parameters that will be used can be represented by the following table:<tables id="tabl0001" num="0001"><img file="EP1569489A1_D0001.tif" /></tables>

We can state the following rule: the value of a parameter is that of the first fixed or the last proposed.

Consider a parameter named β. We recover the various values ​​of this parameter and store them as shown in the table. Then we start browsing the table, doing it column after column, which corresponds, thanks to the classification adopted, to a filtering of the parameter according to a level of constraint going from the most general to the most specific. For the first column, we get the default value. For the second column, the value of the parameter desired by the administrator is determined. Filtering is carried out in the "most general to most specific" direction. The third column will make it possible to determine which value is chosen by the user. The fourth column will retrieve the value of the application.

We are left with a set of preselected β parameters on one line. It only remains to apply the filtering rule on this line of parameters, and we obtain an active β parameter. The operation is repeated for each parameter. These values ​​are then stored in the parameters section of the active profile.

As there is one active profile per application, it will be necessary to create as many active profiles as there are applications running on the terminal.

Note that only the default profile is mandatory, other profiles can be omitted.

The filtering rules, illustrated by the horizontal and vertical arrows on this table, can be expressed as follows:<ul id="ul0003" list-style="dash" compact="compact"><li>all parameters have a priority ("proposed" or "fixed)</li><li>we go through all the parameters</li><li>the value selected is the value of the first priority parameter "fixed" by a profile;</li><li>however, there are no parameters whose priority is "fixed", the value selected will be that of the last parameter "proposed".</li></ul>

The criteria on which the different actors of the system can influence to constitute active parameters are, in this example, the following (graphical representation of preferences in Figure 6).

The “selection mode” parameter indicates the degree of intervention expected from the user 20 by the system when the operating mode of the terminal changes. It allows you to determine whether the flows of an application have been redirected automatically or not. There are three possible values: manual selection, semi-automatic selection, automatic selection.

By default, the selection mode is automatic.

The “cost” parameter indicates the dominant factor between the monetary cost and the desired quality of service. There are five possible choices: cost is more important than quality of service, cost is more important than quality of service, cost is as important as quality of service, cost is less important than quality of service , the cost is much less important than the quality of service.

By default, cost is as important as QoS.

The parameter constituted by the list of prohibited access networks contains all the prohibited access networks. By default, no access network is prohibited.

The parameter constituted by the list of preferred access networks contains a list sorted in descending order on the preferred access networks. By default, there is none.

The criterion consisting of application preferences allows you to enter three parameters, which are as follows:<ul id="ul0004" list-style="none" compact="compact"><li>The priority level parameter for a given application entered by an administrator and / or a user indicates the priority level between 1 and 10 desired for a given application. By default, this parameter is worth 5.</li><li>The security level setting for a given application entered by an administrator, a user, and / or the application concerned if it has the capacity, indicates the security level required for the given application. By default, this parameter is worth 5.</li><li>The standby mode support parameter indicates, for a given application, its ability to function when the network access interface is in standby mode. This setting will be used to prevent a network interface from entering standby mode when the applications communicating on it do not function properly in active standby mode. By default, this parameter is true.</li></ul>

We will now describe a detailed example of practical implementation, in which a system is defined with an administrator, a user, as well as two applications, one of which is said to be intelligent, that is to say capable of producing a list of preferences (PRP ).

We will therefore proceed to create an active usable profile, reflecting a consensus between the choices of the different protagonists of the system, in order to be used here by a decision algorithm directing the flows of each application on one of the network interfaces.

As previously expressed, an alert system makes it possible to indicate to the profile manager 50 the state of the battery. We will describe the following scenario.

A user whose login name is "sathéo" logs into the terminal. It uses two applications: one for videoconferencing (VIC), the other for electronic mail (Outlook). The system is in a 100% battery state.

Selecting an active profile will ultimately result in a 100% profile.

We will first describe the profiles created by the various actors in the system. Then we will describe the creation of active profiles for the user "sathéo" and the battery level 100%, and finally the active profile for the user "sathéo" and the battery level 50%.

Administrator profiles for 100% battery:

The administrator 10 decides to create a profile which will cover the set of cases so that all of the users 20 and applications 30 have the same parameters. However, it specializes in the use of the Outlook application, which requires special security conditions.

Administrator profile, for 100% battery, for any user and any application:

The administrator proposes certain parameters which will be common to any use:<ul id="ul0005" list-style="dash" compact="compact"><li>selection mode: manual</li><li>cost: cost equal to QOS</li><li>priority: 5</li><li>security level: 5</li><li>energy saving management: false</li></ul>

Administrator profile, for 100% battery, for any user and for the Outlook application

:

Using Outlook requires more security, given the company charter. Administrator 10 will therefore increase the security level of this application and set this value.

Security level: 9.

Administrator profile, for 50% battery, for any user and for any application:

The administrator decides to propose a significant cost index. He also advises against using the energy-intensive 802.11A network:<ul id="ul0006" list-style="dash" compact="compact"><li>cost: significant cost (fixed)</li><li>network prohibited: 802.11A (fixed)</li></ul>

Administrator profile, for 50% battery, for any user and for the Outlook application:

The Outlook application is still just as critical, so you need a high level of security.<ul id="ul0007" list-style="dash" compact="compact"><li>security level: 9 (fixed)</li></ul>

User profiles:

User profile, for 100% battery and for any application

The user defines his own values. He is very manic and wants a high level of security, as well as validating the selection mode chosen:<ul id="ul0008" list-style="dash" compact="compact"><li>selection mode: manual</li><li>cost: significant QOS</li><li>network prohibited: Bluetooth</li><li>Preferred RA: 802.11 G, 802.11A, 802.11 b, GPRS</li><li>Security level: 9</li></ul>

User profile, for 100% battery for the VIC application (video conference)

:

For the VIC application, user 10 wishes different parameters in order to make the application as available as possible:<ul id="ul0009" list-style="dash" compact="compact"><li>selection mode: automatic</li><li>network prohibited: GSM</li><li>security level: 9</li><li>Energy saving: true</li></ul>

User profile for 50% battery and for any application:

The preferences remain the same:<ul id="ul0010" list-style="dash" compact="compact"><li>selection mode: manual</li><li>cost: significant QOS</li><li>network prohibited: Bluetooth</li><li>Preferred RA: 802.11 G, 802.11 A, 802.11 b, GPRS</li><li>security level: 9</li></ul>

User profile for 50% battery and for the VIC application:

The parameters remain the same:<ul id="ul0011" list-style="dash" compact="compact"><li>selection mode: automatic</li><li>network prohibited: GSM</li><li>security level: 9</li><li>energy saving: true</li></ul>

Application profiles

:

Application profile for 100% battery

Outlook application profiles

The Outlook application is said to be intelligent and can define its own operating preferences.<ul id="ul0012" list-style="dash" compact="compact"><li>selection mode: semi-automatic</li><li>priority: 7</li><li>security: 7</li><li>energy saving: true</li></ul>

Outlook application profile, for 50% battery:

Here are the Outlook application settings when the battery level is 50%:<ul id="ul0013" list-style="dash" compact="compact"><li>RA prohibited: 802.11 a, GSM</li><li>priority: 7</li><li>security level: 7</li><li>energy saving: true</li></ul>

The default profile

This profile represents the system default settings.

For a 100% battery, as for a 50% battery, we will refer to the content of the tables below, in the box at the top left each time.

To generate the active profile for the user "sathéo", for the VIC application with 100% battery, you must recover the default profile, the administrator profile for any user and any application, the administrator profile for any user and the 'VIC application, the user profile "sathéo" for all applications, the user profile "sathéo" for the VIC application.

The filtering table for the selection mode of the "selection mode" parameter is as follows:<tables id="tabl0002" num="0002"><img file="EP1569489A1_D0002.tif" /></tables>

The active parameter for the selection mode is therefore automatic.

The cost filtering table is as follows:<tables id="tabl0003" num="0003"><img file="EP1569489A1_D0003.tif" /></tables>

The active cost parameter is therefore "important".

Here is the filtering table for the "RA prohibited" parameter.<tables id="tabl0004" num="0004"><img file="EP1569489A1_D0004.tif" /></tables>

The active prohibited network parameter is therefore GSM.

Here is the filter table for the "Preferred RA" parameter<tables id="tabl0005" num="0005"><img file="EP1569489A1_D0005.tif" /></tables>

The list of preferred networks, as an active parameter, is therefore: 802.11G, 802.11A, 802.11 b, GPRS.

Here is the filter table for the priority parameter:<tables id="tabl0006" num="0006"><img file="EP1569489A1_D0006.tif" /></tables>

The active priority parameter is therefore 5.

Here is the filtering table for the security level:<tables id="tabl0007" num="0007"><img file="EP1569489A1_D0007.tif" /></tables>

The active security level parameter is therefore 9.

Here is the filtering table for energy saving:<tables id="tabl0008" num="0008"><img file="EP1569489A1_D0008.tif" /></tables>

The active energy saving setting is therefore "true".

Thanks to these filtering rules, the active profile created is therefore:<ul id="ul0014" list-style="dash" compact="compact"><li>selection mode: automatic</li><li>cost: significant QOS</li><li>RA prohibited: GSM</li><li>Preferred RAs: 802.11g, 802.11A, 802.11b, GPRS.</li><li>priority: 5</li><li>security level: 9</li><li>energy saving: true</li></ul>