FR 2895636 A1 20070629 FR 0554098 A 20051227 Procédé de traitement d'une demande d'un utilisateur d'un terminal numérique L'invention a pour objet un procédé de traitement d'une demande d'un utilisateur d'un terminal numérique. Le domaine de l'invention est celui des réseaux et plus particulièrement celui des réseaux de télécommunication accessibles depuis des terminaux mobiles. Un terminal mobile (any time, any where) est, d'une manière générale, un terminal transportable dans une poche d'un vêtement et apte à se connecter à un réseau de télécommunication , par exemple d'un opérateur de téléphonie mobile. Dans l'état de la technique il existe différentes technologies d'accès qui permettent potentiellement à un utilisateur de choisir la technologie la plus adaptée à son besoin. Cependant la coexistence de technologies hétérogènes rend l'environnement d'exécution d'un service sur un terminal donné, via ces technologies, extrêmement complexe. L'exécution optimale, ou tout du moins adéquate dépend alors de différents facteurs parmi lesquels la localisation de l'utilisateur (spatiale et temporelle), l'environnement réseau, le contexte d'exécution, les capacités du terminal de l'utilisateur, etc. Avec la convergence des télécommunications classiques et du monde moderne de l'Internet, une nouvelle génération de services est apparue. Ces nouveaux services (services multimédia, services de données, services Internet) peuvent être utilisés différemment par les utilisateurs selon leurs préférences et/ou selon leurs capacités. Par conséquent, dans cette nouvelle configuration, le facteur humain devient le plus important dans la conception et la réalisation d'un service. Les utilisateurs devraient pouvoir définir leurs préférences et personnaliser leurs services. La personnalisation et les préférences varient selon différents facteurs statiques et dynamiques. La personnalisation est une des clés de la viabilité d'un service. Les données de personnalisation devraient pouvoir être stockées et exploitées de manière interopérable et dynamique pour chaque acteur. Cela n'est pas le cas dans l'état de la technique. Il est à noter que les systèmes de télécommunications actuels sont limités en termes de portabilité de services et de déploiement rapide de services. Pour répondre à ce dernier point quelques initiatives ont vu le jour pour ouvrir les réseaux et les rendre accessibles à des fournisseurs de services tiers. Ces initiatives sont, par exemple, la méthode OSA (Open Service Access, pour accès ouvert au service) dont les spécifications sont livrées par le 3GPP sous la référence 22.127 et en particulier la version 5.3.0 de ce document. Une autre initiative est connue sous le nom de JAIN (Interface de programme d'accès au réseau pour JAVA). Ces initiatives sont regroupées sous les appellations EAI (Enterprise Application Integration, pour intégration d'application d'entreprise) et Web Services pour services web. Pour le cas des services web, des EAIs, tous les composants d'un système sont des services qui formatent des comportements/données et communiquent avec d'autres composants à travers une interface d'une application de communication à laquelle lesdits composants accèdent via des fonctions standardisées. De telles fonctions sont appelées des APIs (Application Program Interface, pour interface de programmes d'application). Les protocoles utilisés pour ces communications sont, par exemple, SOAP (Simple Object Access Protocol, pour protocole simple d'accès à un objet) et ou WSDL (Web Services Description Language, pour langage de description d'un service web). Ces technologies, dans leurs spécificités, illustrent le fait que la préoccupation principale de ces systèmes est de multiplier le nombre d'interfaces pour accroître l'interopérabilité entre les applications. En d'autres termes l'objectif de ces systèmes est de rendre l'accès aux données transparent pour les applications. Dans cette approche la gestion de la qualité de service n'est pas faite, et encore moins la gestion de la qualité de service entre un utilisateur et le service demandé par l'utilisateur, ce que l'on appellera ici la qualité de service d'extrémité à extrémité ou de bout en bout. Un autre problème de l'état de la technique est sa nature centralisée et sa mise en place sous une forme client serveur qui impose une infrastructure de gestion des serveurs eux-mêmes via d'autres serveurs. Cela crée, entre le client et le serveur une chaîne dont chaque maillon est susceptible de tomber en panne. Chaque maillon est capital dans la relation client serveur. Cela a pour 35 conséquence une possible dégradation des performances générales. Ces inconvénients sont dus à la multiplicité des équipements traversés lors des communications entre le serveur et le client. L'invention résout ces problèmes par la mise en place d'un logiciel de couche intermédiaire aussi appelé un "middleware". Ce logiciel de couche intermédiaire procède d'une part à une mise à jour continue de l'infosphère de l'utilisateur et d'autre part à un filtrage des informations collectées qui sont associées à des préférences exprimées par l'utilisateur du dispositif. On appelle ici infosphère de l'utilisateur l'ensemble de toutes les données relatives à l'utilisateur et des moyens d'utiliser ces données. De cette association il résulte un profil actif qui est utilisé pour produire des réponses à des requêtes exprimées par l'utilisateur précédemment mentionné. Les préférences de l'utilisateur intègrent des données personnelles, aussi bien que des données de type présentation, qualité de service et/ou moyens à mettre en oeuvre pour satisfaire une requête exprimée par ledit utilisateur. Une troisième étape du procédé permet de calculer toutes les possibilités de mise en oeuvre en fonction des contraintes de chaque élément de la chaîne, en anticipant les pannes éventuelles afin de répondre à la demande de l'utilisateur. L'invention a donc pour objet un procédé de traitement d'une demande d'un utilisateur d'un terminal mobile par ledit terminal mobile caractérisé en ce qu'il comporte les étapes suivantes mises en oeuvre par le terminal mobile: - collecte de l'ensemble des données relatives à un utilisateur identifié par un code utilisateur et des moyens d'utiliser ces données, les données collectées étant d'au moins quatre natures : personnelle, ressources de traitements disponibles, ressources de communications disponibles et caractéristiques du terminal, - production d'un profil correspondant à l'utilisateur et enregistrement dudit profil dans une mémoire, - expression de la demande par l'utilisateur du terminal, -confrontation de la demande exprimée au profil produit pour construire un réseau utilisateur privé d'éléments du profil permettant la satisfaction de la demande, - mise en oeuvre du réseau utilisateur privé construit. Avantageusement l'invention est aussi caractérisée en ce que la collecte des données et la production du profil sont réalisées en permanence pour tenir compte de l'évolution de l'environnement du terminal. Avantageusement l'invention est aussi caractérisée en ce que la production du profil est réalisée selon un agenda. Avantageusement l'invention est aussi caractérisée en ce que une information de qualité de service est associé dynamiquement à chaque élément du profil de nature ressource de traitement et ressource de communication. Avantageusement l'invention est aussi caractérisée en ce que le réseau utilisateur privé d'éléments, permettant la satisfaction de la demande, est construit en fonction d'une qualité minimale à atteindre pour la satisfaction de la demande. Avantageusement l'invention est aussi caractérisée en ce que la défaillance d'un élément dans le réseau utilisateur privé construit pour la satisfaction de la demande entraîne la substitution de cet élément par un autre élément équivalent dans le profil. Avantageusement l'invention est aussi caractérisée en ce qu'une tâche de production du profil maintient, quand c'est possible et ce pour chaque élément du profil, une liste d'éléments équivalents. Avantageusement l'invention est aussi caractérisée en ce qu'une demande, pour être confrontée aux ressources disponibles, est décomposée en une séquence de ressources à mettre en oeuvre pour satisfaire la demande. L'invention sera mieux comprise à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. Celles-ci sont présentées à titre indicatif et nullement limitatif de l'invention. Les figures montrent: - figure 1 : une illustration d'étapes du procédé selon l'invention; - figure 2: une illustration de l'évolution d'un profil actif au cours du 30 temps, - figure 3: une illustration d'un réseau comportant une pluralité de terminaux et serveurs, - figure 4: une illustration d'étapes de l'abonnement à un service, - figure 5: une illustration générique du traitement d'une demande. 35 La figure 1 montre une étape 101 préliminaire de démarrage d'un terminal, par exemple le terminal 301 montré par la figure 3. Le terminal 301 est, par exemple, un appareil de téléphonie mobile. Dans la pratique un tel terminal peut être n'importe quel dispositif apte à se connecter à un réseau de télécommunication. En particulier un tel dispositif peut être un assistant personnel ou un ordinateur personnel. Le terminal 301 est connecté, via un réseau 306 à d'autres terminaux et / ou serveurs. Lors de son démarrage 101 le terminal 301 lance une séquence d'initialisation ou "boot" classique puis, selon l'invention, lance au moins un processus 102 de production d'un profil. Le processus 102 collecte et enregistre des informations en vue d'une utilisation ultérieure pour satisfaire une requête d'un utilisateur du terminal 301. Une particularité de l'invention est que ce processus de production d'un profil est permanent une fois le terminal démarré. Par permanent il faut ici comprendre que soit le terminal exécute le processus 102 dans un environnement multitâche, la tâche correspondant au processus ne s'arrêtant alors jamais, soit le processus 102 est lancé à intervalles réguliers. On note ici que le processus 102 peut être lancé à intervalles réguliers dans un environnement multitâche. Dans une mise en oeuvre de l'invention, la production du profil est réalisée par deux processus simultanés. Un premier processus dit d'ambiance qui collecte en permanence les informations relatives à l'utilisateur créant ainsi son infoshpère. Un processus de filtrage qui produit un profil actif qui correspond aux informations de l'infosphère filtrées et / ou triées par les préférences de l'utilisateur. Il faut bien ici comprendre ce qu'est l'infosphère de l'utilisateur. Il s'agit en fait de toutes les informations que le terminal 301 est capable de collecter sur son utilisateur. Ces informations concernent donc des données de type identifiant, mot de passe, préférences, personnalisations, mais aussi les capacités de l'appareil utilisé par l'utilisateur ainsi que des appareils auxquels ledit appareil utilisé par l'utilisateur est capable de se connecter. Ces capacités s'expriment en terme d'aptitude de restitution sonore, d'aptitude de restitution graphique, de capacité de traitement, de capacité d'émission réception, ... la liste n'étant pas exhaustive. La figure 1 montre que le traitement des informations par le processus 102 porte sur des informations : - personnelles, comme le nom, l'adresse, des identifiants électroniques par exemple de type messagerie électronique et ou instantanée, des préférences dans le mode de réalisation d'un service, etc., - matérielles comme la puissance du microprocesseur du terminal, les capacités d'affichages du terminal, les capacités de rendu sonore du terminal, etc., - de communications et plus généralement de services que le terminal est apte à mettre en oeuvre. Parmi les ressources de communication on connaît au moins les différents réseaux des opérateurs de téléphonie mobile, les moyens de connexion locaux tels que les réseaux locaux sans fil (de type Wifi, Bluetooth ou DECT) et filaires (de type Ethernet). Ces informations une fois collectées sont enregistrées dans une mémoire 302 de profil du terminal 301. La mémoire 302 est elle-même divisée en deux zones, une zone pour enregistrer l'infosphère et une zone pour enregistrer le profil dit actif qui est le filtrage de l'infosphère par les préférences de l'utilisateur. Dans une variante préférée, le profil actif dépend de la localisation de l'utilisateur. Cette localisation est aussi bien spatiale que temporelle. Cela est réalisé grâce à un agenda qui permet de dater l'application des préférences. Cela est aussi réalisé par l'association de chaque préférence à une localisation de type, voiture, France, nom de ville, etc.. La figure 3 montre une entrée 307 d'un agenda selon l'invention. Une telle entrée 307 comporte au moins un champ idP identifiant la préférence, par exemple un réseau de télécommunication ou un service, un champ [] spécifiant une fenêtre temporelle, et un champ loc. spécifiant une localisation. Dans une variante de l'invention le profil de l'utilisateur n'est pas enregistré dans le terminal lui-même, mais dans une mémoire accessible au terminal via une connexion réseau par exemple. Cela revient à enregistrer le profil de l'utilisateur sur un serveur de profil. Dans cet optique le profil lui-même devient une ressource dont il faut prendre en compte la disponibilité pour la satisfaction d'une requête. Ce mode de réalisation permet la mise en oeuvre de l'invention sur des terminaux de faibles capacités mémoire et/ou de traitement. Cette variante peut encore être déclinée en enregistrant le profil de l'utilisateur pour une partie sur le terminal et pour la partie complémentaire sur un serveur. La partie enregistrée sur le terminal correspond dans ce cas à un filtrage du profil relatif à la localisation géographique du terminal. En d'autres termes seuls les informations les plus immédiatement pertinentes sont enregistrées sur le terminal. Dans ces variantes on peut aussi envisager que le traitement d'une requête, décrit plus avant dans la description, soit déportée sur le serveur de profil au lieu d'être effectuée par le terminal, la réponse à la requête étant alors transmise au terminal. Le processus 102 est donc capable pour toute localisation temporelle et spatiale de produire le profil actif souhaité par l'utilisateur. Ce fonctionnement par agenda permet aussi de devancer les demandes de l'utilisateur. En effet l'agenda permet de faire entrer dans le profil actif des ressources dont l'utilisateur est susceptible d'avoir besoin en fonction d'une localisation. D'une manière générale le terminal 301 est un dispositif comportant un microprocesseur 303 commandé par des codes instructions enregistrés dans une mémoire 304 de programmes, les éléments 302 à 304 étant interconnectés par un bus 305. Le terminal 301 comporte aussi d'autres composants non représentés en particulier des composants d'entrées / sorties lui permettant de communiquer avec son utilisateur et le ou les réseaux de télécommunications environnants. Lorsque l'on prête une action à un dispositif, cette action est en fait réalisée par un microprocesseur du dispositif commandé par des codes instructions enregistrés dans une mémoire de programme du dispositif. La mémoire 302 est par exemple structurée en une grille comportant plusieurs zones, une zone pour les données personnelles, une zone pour les données matérielles et une zone pour les données de communications et de services. Dans la pratique, chaque ressource de communication ou de service est identifiée par un identifiant unique et est décrite par une nature et une localisation de service. Une nature est le type de service correspondant à la ressource, par exemple service SMS, connexion haut débit, service de localisation, service de restauration à domicile, service de renseignement, service de paiement, etc.. Une localisation de service correspond à des informations techniques permettant de se connecter à la ressource. Une telle information est, par exemple, un identifiant permettant de se connecter à la ressource à travers un réseau. Parmi ces identifiants, les plus connus sont les URL et les adresses IP. Dans l'invention la mémoire 304 comporte donc au moins une zone 304a correspondant à des codes instructions pour la mise à jour des informations d'état des ressources, et une zone 304b qui correspond à des applications dites "écouteur" qui scrute leur environnement et donc celui du terminal 301 pour y découvrir des ressources. Des exemples d'écouteurs sont, par exemple, un écouteur Bluetooth, un écouteur de service SMS, un écouteur de localisation de type GPS, un écouteur de mobilité déterminant le mode de déplacement de l'utilisateur, etc.. La mémoire 304 comporte aussi une zone 304c pour la production et la mise en oeuvre de réseaux virtuels. La figure 2 illustre l'évolution d'un profil au cours du temps. A un instant tO un utilisateur met le terminal 301 sous tension. Le terminal 301 lance alors le processus 102 d'exploration. A l'instant tO le terminal 301 détecte qu'une connexion 201 GPRS (c'est-à-dire une connexion via un réseau de téléphonie mobile de deuxième génération) est possible, que l'utilisateur est piéton 202, qu'il a accès à des services 1.1, 1.2, 2.1 et 3.1. Les services 1 sont, par exemple, des services de délivrance de SMS, le service 2 est, par exemple, un service de transformation vocale d'un texte, le service 3 est, par exemple, un service de localisation. Comme précédemment décrit, il existe de nombreux autres services. Le terminal 301 effectue, selon sa programmation, le processus d'exploration à intervalles réguliers ml, m2,..., tant qu'il est sous tension. A un instant tvl , le terminal détecte que l'utilisateur se déplace maintenant en voiture. A un instant t3G1 > tvl le terminal détecte une possibilité de connexion via un réseau de téléphonie mobile de troisième génération. A un instant tvxl > t3G1 le terminal détecte que le service 2.1 n'est plus disponible. A un instant tGPRS1 > tvxl le terminal détecte que le réseau GPRS n'est plus disponible. A un instant tv2 > tGPRS1 le terminal détecte que l'utilisateur est de nouveau piéton. Le processus d'exploration continue ainsi tant que le terminal est sous tension. Il est ici intéressant de constater que le terminal 301 recense dans le profil 302 actif toutes les ressources disponibles dans l'environnement du terminal, même si cela est redondant d'un point de vue fonctionnalité. Cette caractéristique présente au moins deux avantages : -une meilleure prise en compte d'une qualité de service demandée par l'utilisateur via ses préférences - une grande adaptabilité en cas de défaillance d'un service, le terminal étant alors apte à le substituer par un service équivalent. La figure 1 montre aussi qu'au démarrage le terminal 301 lance un processus 103 de traitement des requêtes de l'utilisateur dudit terminal. Les processus 102 et 103 s'exécutent en parallèle. Le processus 103 comporte une étape 104 préliminaire d'écoute des requêtes de l'utilisateur. Tant que l'utilisateur n'exprime pas une requête, le processus 103 reste dans l'étape 104. L'utilisateur exprime une requête, par exemple, via un clavier du terminal 301, en sélectionnant un lien sur une page hypertexte, en sélectionnant une option dans un menu ou de toute autre manière. Par exemple, à une date t1 Une fois le réseau constitué il est mis en oeuvre. Dans notre exemple le terminal 301 utilise donc le réseau GPRS pour se connecter au serveur 1.1 de distribution de SMS et ainsi récupérer les messages de l'utilisateur. L'ensemble des informations nécessaires à cette connexion, à savoir identifiant et mot de passe par exemple, est aussi enregistré dans le profil de l'utilisateur dans la zone correspondant aux informations personnelles. Dans un autre exemple l'utilisateur souhaite toujours récupérer ses SMS mais à un instant t2 tel que t3G1 Dans le dernier exemple l'invention prévoit une autre solution en cas d'indisponibilité d'un service. Il se peut qu'un service soit disponible moyennant finance. La figure 4 montre une étape 401 de test de la disponibilité d'une ressource lors de la production d'un réseau virtuel. Si la ressource est disponible mais pas activable, le terminal 301 passe à une étape 402 qui consiste à tester si la ressource est activable via un abonnement à souscrire. Dans ce cas la ressource a été enregistrée comme telle dans le profil 302. Si ce n'est pas le cas le terminal passe à une étape 403 de fin, il est alors impossible de satisfaire la requête de l'utilisateur. Si c'est le cas le terminal vérifie alors qu'une ressource de paiement est disponible, via une connexion à un service bancaire par exemple. Si un tel service bancaire est disponible alors le terminal passe à une étape 404 d'abonnement. L'étape 404 consiste à inclure dans le réseau final le service bancaire et le service auquel on souhaite souscrire un abonnement. Il devient dès lors possible de répondre à la requête ,, la souscription acceptée et initialisée fait passer alors la ressource à l'état activé. Dans ce mode de fonctionnement, l'utilisateur précise dans son profil jusqu'à quelle somme le terminal est autorisé à négocier automatiquement par exemple. Si la somme est dépassée, l'accord de l'utilisateur est sollicité pour continuer à produire le réseau virtuel. La figure 5 illustre de manière générale le traitement d'une demande. La figure 5 montre une ligne 501 correspondant à une décomposition d'une demande en une séquence de ressources à mettre en oeuvre. L'exemple choisi illustre une demande correspondant à la mise en oeuvre de quatre ressources R1 à R4. Grâce à l'étape 102 le terminal 301 est capable d'associer à chaque ressource R1 à R4 une liste de services. Ces listes sont issues du profil actif de l'utilisateur produit à l'étape 102. A la ressource R1 correspond la liste L1 comportant les services S1. 1 à S1.3. A la ressource R2 correspond la liste L2 comportant les services S2.1 à S2.4. A la ressource R3 correspond la liste L3 comportant le service S3.1. A la ressource R4 correspond la liste L4 comportant les services S4.1 à S4.3. Dans l'invention chaque service à un statut parmi au moins, non disponible, disponible, activable et activé. Pour la satisfaction de la demande, le terminal 301 sélectionne un service par liste pour produire le réseau de services permettant la satisfaction de la demande. Dans notre exemple ce réseau comporte les services S1.1, S2.3, S3.1 et S 4.1. Dans la pratique, dans une liste, les services présents correspondent aux préférences de l'utilisateur. Le terminal 301 sélectionne alors, le premier service activé de la liste. Si aucun service n'est activé, alors il sélectionne le premier service activable et il l'active. Si aucun service n'est activable alors le terminal sélectionne le premier service disponible et il l'active. Si aucun service n'est disponible alors le terminal lance une procédure de découverte ou d'abonnement décrite avec la figure 4. Un service est activé si le terminal peut s'en servir, c'est-à-dire, par exemple, émettre des données via une connexion ouverte à un réseau. Un service est activable si le terminal dispose de toutes les informations et droits pour l'activer. Un service est disponible si le terminal le détecte, c'est-à-dire si le terminal capte un réseau de télécommunication mais ne dispose pas des 10 informations nécessaires pour le rendre activable. Un service est non disponible si aucune activité ne correspondant à ce service n'est détectée. Dans cette description de gestion d'états d'un service, il faut comprendre service dans un sens large. Un service est donc ici soit une 15 ressource de traitement, de distribution d'information (base de données par exemple), de communication (réseau), ou de restitution (périphérique d'entrée sortie). Dans l'invention le profil actif est donc une structure enregistrée dans la mémoire 302. Une façon de voir cette structure est de l'imaginer comme 20 une liste de ressources, à chaque ressource correspondant une liste d'offreurs aptes à rendre le service lié à la ressource. Un offreur est ici un dispositif avec lequel le terminal 301 est apte à établir une communication. Dans une variante de l'invention, la précédente structure associe à chaque offreur une note de qualité de service qui est déterminée lors des 25 mises à jour de l'infosphère de l'utilisateur. Il est ainsi possible de construire un réseau de ressources pour répondre à une requête selon une exigence de qualité de service. Dans une variante de l'invention le profil 302 est mis à jour en fonction d'un agenda. Un tel agenda fait alors partie des données personnelles de 30 l'utilisateur. Un tel agenda précise par exemple quelles informations doivent être recherchées en fonction de la date. Une date peut alors être précisée à la minute, à l'heure, au jour, ou en considération de toute autre précision. Dans un exemple un tel agenda précise que le samedi et le dimanche, entre 11h et 13h, le terminal doit inclure dans le profil des informations 35 relatives aux restaurants situés à proximité du terminal. Le terminalconstitue alors un réseau virtuel permettant d'obtenir ces informations. Ainsi, lorsque que l'utilisateur exprime une requête pour trouver un restaurant, la réponse est déjà disponible dans le profil 302. Avec l'invention il devient possible d'exprimer une QoS (qualité de service) au niveau du service. En effet l'invention rend possible la prise en compte d'une préférence telle que : "message SMS quelles que soient les circonstances." Un réseau virtuel sera construit dans ce but ainsi qu'illustré par la mise en oeuvre de la réception de SMS. D'autre part, chaque composant recensé dans le profil est associé à des notes de disponibilité, fiabilité, délai et capacité de manière à pouvoir déterminer une QoS traditionnelle pour un réseau virtuel et ainsi adapté ce réseau virtuel à une QoS requise par l'utilisateur. Cela est rendu possible grâce à l'invention qui envisage chaque ressource comme un composant connectable à un réseau. L'invention propose donc la mise en oeuvre d'un processus permanent d'exploration prospective de l'environnement en vue de précéder l'expression d'une requête par un utilisateur. L'invention est particulièrement intéressante car elle amène l'environnement à être tout ce avec quoi le terminal est capable de se connecter, c'est à dire l'infosphère de l'utilisateur. Cela inclut des serveurs, mais aussi des terminaux d'autres utilisateurs. L'invention transforme donc un réseau client serveur traditionnel en un réseau d'utilisateurs opérant tous au même niveau et échangeant des services. Chaque terminal peut être à la fois demandeur (client) et offreur (serveur). REVENDICATIONS 1 - Procédé de traitement d'une demande d'un utilisateur d'un terminal (301) mobile par ledit terminal mobile caractérisé en ce qu'il comporte les étapes suivantes mises en oeuvre par le terminal mobile: - collecte (102) de l'ensemble des données relatives à un utilisateur identifié par un code utilisateur et des moyens d'utiliser ces données, les données collectées étant d'au moins quatre natures : personnelle, ressources de traitements disponibles, ressources de communications disponibles et caractéristiques du terminal, - production (102) d'un profil correspondant à l'utilisateur et enregistrement dudit profil dans une mémoire, -expression (104) de la demande par l'utilisateur du terminal, -confrontation de la demande exprimée au profil produit pour construire (105) un réseau utilisateur privé d'éléments du profil permettant la satisfaction de la demande, - mise en oeuvre (106) du réseau utilisateur privé construit. 2 - Procédé selon la revendication 1, caractérisé en ce que la collecte des données et la production du profil sont réalisées en permanence pour tenir compte de l'évolution de l'environnement du terminal. 3 - Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que la production du profil est réalisée selon un agenda (302, 307). 4 - Procédé selon l'une des revendications 1 à 3, caractérisé en ce que une information de qualité de service est associée dynamiquement à chaque élément du profil de nature ressource de traitement et ressource de communication. 5 - Procédé selon la revendication 4, caractérisé en ce que le réseau utilisateur privé d'éléments permettant la satisfaction de la demande est construit en fonction d'une qualité minimale à atteindre pour la satisfaction de la demande. 6 - Procédé selon l'une des revendications 1 à 5, caractérisé en ce que la défaillance d'un élément dans le réseau utilisateur privé construit pour la satisfaction de la demande entraîne la substitution de cet élément par un autre élément équivalent dans le profil. 7 - Procédé selon la revendication 6, caractérisé en ce qu'une tâchede production du profil maintient, quand c'est possible et ce pour chaque élément du profil, une liste d'éléments équivalents. 8 - Procédé selon l'une des revendications 1 à 7, caractérisé en ce qu'une demande, pour être confrontée aux ressources disponibles, est décomposée en une séquence de ressources à mettre en oeuvre pour satisfaire la demande.