FR 2929474 A1 20091002 FR 0852067 A 20080328 La présente invention a pour objet une architecture informatique hiérarchisée à couches multiples pour un système de communication entre terminaux informatiques. Au sens de l'invention, on désigne par � terminal informatique � des terminaux choisis par exemple parmi les ordinateurs, les ordinateurs portables, les micro ordinateurs, les assistants personnels numériques, les téléphones portables, les véhicules équipés d'une interface communicante, les moyens de paiements électroniques, les appareils de positionnement par satellite, par exemple de type GPS. De nos jours, le développement des télécommunications repose sur deux notions : la mobilité et la convergence. La mobilité est associée à l'idée de permettre aux utilisateurs de pouvoir passer des communications en tout endroit et à tout moment. La convergence permet aux utilisateurs d'accéder à une large gamme de services depuis n'importe quel terminal et/ou n'importe quel réseau informatique. Néanmoins, l'introduction de la convergence et de la mobilité dans les télécommunications peut avoir des aspects négatifs, comme la faculté pour un utilisateur de pouvoir être joint alors qu'il n'est pas disposé à passer des communications, par exemple lors d'une réunion de travail. Pour remédier à cet inconvénient, la publication B. El Saghir et N. Crespi "An Intelligent Assistant for Context-Aware Adaptation of Persona/ Communications" propose un assistant intelligent adaptant selon le contexte les communications personnelles. Pour réaliser un tel assistant intelligent, il est souhaitable de se fonder sur un modèle représentatif du monde réel dans lequel les communications ont lieu. Selon la demanderesse, on peut décomposer le modèle réel en trois niveaux : un niveau de session impliquant des sessions pour échanger des médias et pour transmettre des signaux, un niveau de communication mettant en jeu un environnement de communication représentant différents concepts tels que l'identité de l'utilisateur, la localisation de l'utilisateur et les terminaux et réseaux auxquels il a accès et, un niveau utilisateur focalisé sur des informations spécifiques à l'utilisateur telle que son statut, son profil et ses préférences. Pour implémenter un assistant intelligent, il peut par conséquent s'avérer souhaitable de mettre en jeu une architecture hiérarchisée multicouche dans laquelle chaque couche interagit avec l'un des niveaux du modèle réel ci-dessus. Il existe par conséquent un besoin pour bénéficier d'une architecture informatique permettant de réaliser un assistant intelligent pour concilier les exigences de convergence et de mobilité dans les télécommunications avec l'aptitude d'un utilisateur à passer des communications. L'invention vise à répondre à ce besoin et y parvient grâce à une architecture informatique hiérarchisée à couches multiples pour système de communication entre au moins deux terminaux informatiques, l'architecture comportant au moins deux couches comportant chacune: un modèle de l'objet de la couche, ce modèle comportant plusieurs états de l'objet, un module d'événement, pour recevoir et/ou envoyer au moins un 10 événement à une autre couche de l'architecture et, - un module d'action pour envoyer et/ou recevoir une action depuis une autre couche de l'architecture. L'invention permet d'obtenir une structure multicouche hiérarchisée. Le choix d'une architecture multicouche pour réaliser l'architecture peut permettre d'optimiser la 15 performance globale de l'architecture en délégant des tâches simples qui nécessitent un traitement rapide à des couches inférieures de l'architecture et en laissant les tâches plus complexes et plus coûteuses en terme de ressources, notamment de temps de calcul, aux couches supérieures de l'architecture. Contrairement au modèle de référence OSI défini par exemple dans la 20 publication J.Day et H. Zimmermann "the OSI référence model", dans lequel chaque couche de l'architecture est spécifique aux tâches qui lui incombent, dans des exemples de mise en oeuvre de l'architecture selon l'invention, les couches peuvent être implémentées selon un modèle standard qui peut être réutilisé à chaque niveau de l'architecture en ne modifiant que l'objet sur lequel la couche opère. 25 L'invention peut par ailleurs permettre de bénéficier d'une architecture intuitive et facile à implémenter. Le module d'événement de la couche est par exemple agencé pour, à la réception d'un évènement depuis une autre couche, provoquer le passage de l'état du modèle de l'objet de la couche d'un état passé à un état actuel. 30 On désigne par � état passé � l'état du modèle de l'objet de la couche avant la réception d'un événement depuis l'autre couche par le module d'événement de la couche et par � état actuel � l'état du modèle de l'objet de la couche après réception depuis l'autre couche de l'événement par le module d'événement de la couche. Le module d'action de la couche est par exemple agencé pour, à la réception d'une action du module d'action d'une autre couche, ajouter un ou plusieurs états futurs au 5 modèle de l'objet de la couche. On désigne par � état futur � l'état vers lequel le modèle de l'objet de la couche est supposé évoluer lorsque le module d'événement de la couche reçoit un événement correspondant. Les états du modèle de l'objet de la couche comportent par exemple l'un au 10 moins d'un état référençant (en anglais mapping state), d'un état référencé (mapped state) et d'un état autonome. On désigne par � état référençant � un état du modèle de l'objet d'une couche de l'architecture qui est associé à un état du modèle de l'objet d'une couche supérieure à ladite couche dans l'architecture, cet état du modèle de l'objet de la couche supérieure 15 étant un état référencé. On désigne par � état autonome � un état n'étant ni un état référençant, ni un état référencé. Le module d'évènement d'une couche dans laquelle un état référençant du modèle de l'objet est atteint est par exemple agencé pour détecter le passage du modèle de 20 l'objet de la couche dans cet état référençant et pour envoyer au moins un évènement au module d'évènement d'une couche supérieure de l'architecture. La couche supérieure est par exemple la couche directement supérieure dans l'architecture, c' est-à-dire que pour une couche N, la couche directement supérieure dans l'architecture est la couche N+1. 25 Le module d'évènement de la couche supérieure de l'architecture peut être agencé pour recevoir l'événement et pour provoquer le passage du modèle de l'objet de la couche supérieure à un état référencé. L'invention peut permettre de mettre à jour les informations dans l'architecture en faisant, par l'envoi d'événements, remonter les informations d'une couche vers la 30 couche lui étant supérieure pour actualiser pour chaque couche de l'architecture l'état du modèle de l'objet de celle-ci. Le module d'action d'une couche peut être agencé pour envoyer une action au module d'action d'une couche inférieure de l'architecture pour permettre le passage du modèle de l'objet de ladite couche à un autre état. La couche inférieure est par exemple la couche directement inférieure dans l'architecture, c'est-à-dire que pour une couche N, la couche directement inférieure est la couche N-1. Le module d'action de la couche inférieure est par exemple agencé pour déterminer, en réponse à l'action reçue, un plan consistant en une séquence d'au moins un état futur du modèle de l'objet de la couche inférieure, notamment une pluralité d'états futurs du modèle de l'objet. Le module d'action de la couche inférieure est par exemple agencé pour provoquer le passage d'un état futur à l'autre de la séquence d'états du modèle de l'objet de la couche inférieure en réponse à la réception d'un événement correspondant par le module d'événement de la couche inférieure ou à l'envoi d'une action correspondante par le module d'action de la couche inférieure à une couche encore inférieure. La séquence d'états futurs du modèle de l'objet de la couche inférieure déterminée en réponse à une action reçue par le module d'action de la couche inférieure se termine par exemple par un état référençant, ce qui peut permettre de prévenir la couche dont le module d'action a émis l'action responsable de la détermination du plan de l'exécution du plan et de mettre à jour son modèle de l'objet. Une architecture hiérarchisée selon l'invention comporte par exemple trois couches telles que définies ci-dessus et une quatrième couche comportant un module d'événement, un module d'action et dépourvue de modèle de l'objet. Au moins une couche peut mettre en oeuvre le protocole SIP (session initiation protocole). L'invention a encore pour objet, selon un autre de ses aspects, un procédé de modification de l'état du modèle de l'objet d'une couche d'une architecture à couches multiples hiérarchisées pour réaliser un système de communication entre au moins deux terminaux informatiques, procédé dans lequel on modifie l'état du modèle de l'objet de la couche en réponse à au moins une information reçue depuis au moins une couche adjacente à ladite couche ou envoyée à au moins une couche adjacente par ladite couche. On désigne par � couche adjacente � une couche directement supérieure ou directement inférieure à ladite couche dans l'architecture. Le modèle de l'objet de la couche peut passer d'un état actuel à un état futur lors de la réception d'un événement par le module d'événement et/ou lors de l'envoi d'une action par le module d'action, l'état actuel du modèle de l'objet avant ce passage devenant un état passé et l'état futur atteint devenant l'état actuel. Le procédé comporte par exemple une étape dans laquelle on modifie l'état du modèle de l'objet de ladite couche en réponse à au moins une information reçue depuis au moins une couche adjacente à ladite couche. L'information reçue par ladite couche résulte par exemple du passage de l'état du modèle de l'objet d'une couche adjacente d'un état à un autre état. La couche adjacente est par exemple une couche directement supérieure à ladite couche selon l'architecture hiérarchisée et l'au moins une information reçue par ladite couche correspond par exemple à la réception par le module d'action de ladite couche d'une action depuis le module d'action de la couche directement supérieure. La réception de l'action par le module d'action de ladite couche peut générer dans le modèle de l'objet de ladite couche un plan comportant une séquence d'au moins un état futur, le passage d'un état futur à un autre état futur de la séquence étant conditionné par la réception par le module d'événement de ladite couche d'un événement ou par l'envoi par le module d'action de ladite couche d'une action. La séquence se termine par exemple par un état référençant. La couche adjacente est par exemple une couche directement inférieure à ladite couche dans l'architecture hiérarchisée et l'au moins une information reçue par ladite couche correspond par exemple à la réception d'un évènement par le module d'évènement de ladite couche depuis le module d'événement de la couche directement inférieure dans l'architecture hiérarchisée, la réception de l'événement par le module d'évènement de ladite couche provoquant le passage de l'état du modèle de l'objet de ladite couche à un état référencé. Le procédé peut comporter l'étape selon laquelle on modifie l'état du modèle de 30 l'objet de ladite couche en réponse à une information envoyée à au moins une couche adjacente à ladite couche. La couche adjacente est par exemple une couche directement inférieure à ladite couche dans l'architecture hiérarchisée et l'information envoyée à la couche directement inférieure est par exemple la transmission d'une action par le module d'action de ladite couche au module d'action de la couche directement inférieure. La couche adjacente est par exemple dépourvue de modèle de l'objet et l'information reçue par ladite couche depuis la couche adjacente peut ne pas résulter du passage d'un état à un autre du modèle de l'objet de la couche adjacente. L'invention a encore pour objet, selon un autre de ses aspects, une architecture de couches hiérarchisées pour réaliser un système de communication entre au moins deux terminaux informatiques comportant au moins deux couches, chaque couche comportant : - un modèle de l'objet de la couche comportant une pluralité d'états, et - des moyens pour modifier l'état du modèle de l'objet de la couche en fonction d'au moins une l'information envoyée à au moins une couche adjacente et/ou reçue depuis au moins une couche adjacente. L'invention pourra être mieux comprise au vu de la description qui va suivre d'exemples non limitatifs de mise en oeuvre de celle-ci, et à l'examen du dessin annexé, sur lequel : - la figure 1 représente de façon schématique deux couches d'une architecture selon l'invention, - les figures 2a à 2f représentent des modèles de l'objet d'une couche session selon l'invention, - la figure 3 représente de façon schématique une représentation générique d'un état du modèle de l'objet de la couche dimension, et - la figure 4 représente de façon schématique un modèle de l'objet de la 25 couche utilisateur. On a représenté à la figure 1 deux couches adjacentes 2a et 2b d'une architecture hiérarchisée 1 selon l'invention. Comme on peut le voir à la figure 1, chaque couche 2a ou 2b peut comporter un modèle 3a ou 3b de l'objet de la couche, ce modèle comportant plusieurs états 5 de 30 l'objet. Chaque couche 2a ou 2b comporte encore un module d'événement 6a ou 6b et un module d'action 8a ou 8b. Comme on peut le voir à la figure 1, le modèle de l'objet comporte différents états. Le modèle de l'objet 3a de la couche 2a comporte par exemple un état passé 5a1, un état actuel 5a2 et des états futurs 5a3 et 5a4. Le modèle d'état 3b de l'objet de la couche 2b comporte dans l'exemple décrit un état passé 5b1, un état actuel 5b2 et des états futurs 5b3, 5b4 et 5b5. Dans l'exemple décrit, les états 5b1, 5b3 et 5b5 sont des états référençants et sont respectivement associés aux états 5a2, 5a3 et 5a4 qui sont des états référencés. Le module d'évènement 6a ou 6b de chaque couche 2a ou 2b est agencé pour, à la réception d'un évènement d'une couche directement inférieure dans l'architecture, provoquer le passage du modèle de l'objet de la couche 2a ou 2b de l'état actuel à un état futur, ce dernier état étant l'état que le modèle de l'objet 3a ou 3b est supposé avoir après réception de l'évènement. Dans l'exemple décrit, le passage du modèle de l'objet 3b à l'état référençant 5b3 est détecté par le module d'événement 6b qui envoie un événement au module d'événement 6a de la couche 2a. Ce module d'événement 6a peut alors provoquer le passage du modèle de l'objet 3a de l'état passé 5a2 à l'état actuel 5a4 qui est l'état référencé associé à l'état 5b3 de la couche 2b. De la même manière, le passage du modèle d'état de l'objet 3b de l'état 5b2 20 vers l'état 5b4 puis vers l'état 5b5provoque le passage du modèle de l'état de l'objet 3a de l'état 5a2 à l'état 5a3. Le module d'action 8a ou 8b est agencé pour provoquer le passage de l'état présent à l'état futur du modèle de l'objet 3a ou 3b après émission d'une action par le module d'action 8a ou 8b. 25 Lorsque le modèle de l'objet 3a de la couche 2a veut évoluer vers un état futur particulier, résultant par exemple d'une règle prédéfinie dans la couche 2a, le module d'action 8a est agencé pour élaborer l'action associée à cette évolution d'état et envoyer cette action au module d'action 8b de la couche 2b. L'envoi de l'action au module d'action 8b provoque dans l'exemple décrit 30 l'addition d'un état futur au modèle de l'objet 3a de la couche 2a et le passage de ce modèle de l'objet 3a d'un état actuel à un état futur. Le module d'action 8b détermine à partir de cette action reçue un plan comportant une séquence d'états futurs qui sont ajoutés aux états du modèle de l'objet 3b, le passage d'un état futur à l'autre étant conditionné à la réception d'un événement par le module d'événement 6b ou par l'envoi d'une action par le module d'action 8b à une couche encore inférieure dans l'architecture. Une telle séquence d'états futurs comporte au moins un état référençant, permettant de signaler à la couche 2a l'exécution de la séquence afin de mettre à jour l'état du modèle d'état de l'objet 3a. La séquence d'états futurs peut par ailleurs comporter des états autonomes, ces derniers n'étant ni des états référencés ni des états référençants. L'invention permet de mettre en oeuvre une communication entre les différentes couches pour mettre à jour les modèles de l'objet de chaque couche en fonction de l'évolution des modèles de l'objet des autres couches. On va maintenant décrire un exemple d'application d'une architecture selon l'invention à l'implémentation d'assistants intelligents tels que décrits dans la publication B.El Seghir, N. Crespi "An Intelligent Assistant for Contex- Aware Adaptaion of Persona/ Communications". Dans cet exemple, l'assistant intelligent est implémenté selon une architecture comportant quatre couches ordonnées en ordre croissant de complexité : la couche message, la couche session, la couche dimension et la couche utilisateur. Chacune de ces couches est implémentée en utilisant le modèle de couche décrit en référence à la figure 1. La couche message correspond à la couche la plus basse de l'architecture de l'assistant intelligent. Cette couche message est dépourvue de modèle d'état de l'objet mais comporte un module d'événement 6 et un module d'action 8 pour communiquer avec la couche directement supérieure qui est dans l'exemple décrit la couche session. La couche message traite par exemple des interactions au niveau des messages, également appelées interactions réactives car ces interactions ne nécessitent qu'un traitement simple et rapide. Un tel exemple d'interactions correspond à la détection des messages qui nécessitent un accusé de réception et l'envoi de tels accusés de réception. Dans cette couche message, la reconnaissance des évènements consiste à effectuer une analyse syntaxique des messages reçus et à en extraire les en-têtes de section et les valeurs. Cette couche a également pour tâche de déterminer les valeurs des en-têtes de section d'éventuels nouveaux messages à envoyer. Cette couche a encore pour tâche de structurer ces valeurs dans des messages qui sont ensuite émis. Cette couche message interagit avec la couche lui étant directement supérieure dans l'architecture qui est dans l'exemple décrit la couche session. La couche session est responsable de la gestion des sessions de communication et maintient des informations relatives aux états de session de terminaux informatiques communiquant avec l'assistant intelligent. Cette couche session met en oeuvre dans l'exemple décrit le protocole SIP qui est défini par le RFC 3261 auquel on se référera utilement. Cependant, l'invention n'est pas 10 limitée à l'implémentation selon le protocole SIP. On a représenté aux figures 2a à 2f des exemples de modèles de l'objet 3 de la couche session lors d'une session entre l'agent SIP local de l'assistant intelligent et l'agent SIP éloigné associé au terminal informatique de l'utilisateur avec lequel la session de communication a lieu. 15 Comme on peut le voir, le modèle de l'objet 3 comporte dans cet exemple une pluralité d'états 500 à 507. Dans les exemples des figures 2a et 2b, on n'a représenté que le modèle de l'objet de l'agent SIP local de l'assistant intelligent. Dans l'exemple de la figure 2a, la session se déroule entre l'assistant 20 intelligent et un utilisateur et est initiée à l'initiative de l'assistant intelligent. Dans l'exemple de la figure 2b, la session se déroule entre l'assistant intelligent et un utilisateur et est initiée à l'initiative de l'utilisateur. Dans l'exemple des figures 2c à 2f, on a représenté le modèle de l'objet de la couche session de l'agent SIP local de l'assistant intelligent, et de l'agent SIP éloigné 25 associé au terminal informatique de l'utilisateur avec lequel la session a lieu. Les figures 2c et 2d représentent des exemples d'échanges d'informations entre l'assistant intelligent et un utilisateur lors d'une session. Les figures 2e et 2f représentent des exemples de terminaison de session entre l'assistant intelligent et un utilisateur, respectivement à l'initiative de l'utilisateur et de 30 l'assistant intelligent. L'invention peut permettre, en cas de session entre l'assistant intelligent et un utilisateur, l'emploi d'un seul état de dialogue pour représenter les états de dialogue de l'agent SIP local de l'assistant intelligent et de l'agent SIP éloigné associé au terminal informatique d'un l'utilisateur avec lequel la communication a lieu Le modèle de l'objet d'une telle couche session comporte dans l'exemple décrit trois états référençants 501, 505 et 507 qui sont respectivement des états correspondant à l'initialisation d'une session, à l'établissement de la session et à l'arrêt de la session. Le modèle de l'objet comporte encore des états autonomes 500, 502, 503, 504 et 506 qui correspondent respectivement à la non session, au traitement de l'initialisation de la session, à une alerte transmise, à la confirmation de la réception de l'alerte ou à la confirmation des opérations d'initialisation de la session et, aux opérations de terminaison de la session. Cette couche session comporte encore un module d'évènement, agencé pour recevoir de la couche message des évènements correspondants à l'analyse syntaxique des messages et à des couples en-tête de section/valeurs. Chaque évènement reçu est traité par le module d'évènement de la couche session afin de déterminer l'état que le modèle de l'objet de la couche session de l'agent SIP éloigné est supposé avoir lorsque le message reçu par la couche message a été envoyé. Le module d'événement de la couche session est également agencé pour envoyer un événement au module d'événement de la couche de l'architecture directement supérieure à la couche session, à savoir la couche dimension. De tels événements sont transmis lorsque le modèle de l'objet de la couche session atteint l'un des états référançants 501, 505 et 507, de tels événements indiquant respectivement à la couche dimension que la session est initialisée, établie et terminée. La couche session comporte également un module d'action agencé pour envoyer des couples en-tête de section/valeurs au module d'action de la couche message. Avant l'émission de chaque action, le module d'action détermine l'état supposé du modèle de l'objet de l'agent SIP éloigné lorsque le message émis par la couche message aura été reçu par l'agent SIP éloigné. Le module d'action reçoit également les actions envoyées par le module d'action de la couche dimension et les analyse afin de déterminer le plan comportant la séquence d'états futurs associés à cette action et afin d'ajouter ces états futurs au modèle de l'objet. Dans le cadre du protocole SIP, cette séquence d'états futurs correspond à une séquence d'états de dialogue et à la séquence correspondante d'actions et d'événements qui servent à la réalisation de la séquence. Dans l'exemple décrit, les événements reçus par le module d'événement de la couche session correspondent aux messages reçus depuis la couche message et les actions envoyées par le module d'action de la couche session correspondent aux messages envoyés à la couche message. Dans l'exemple de la figure 2a, le passage de l'état 500 à l'état 501 s'effectue en réponse à l'envoi d'une action 100 par le module d'action de la couche session, cette action consistant dans cet exemple en l'envoi d'un message d'invitation à entrer en communication à l'agent SIP éloigné. L'envoi de cette action laisse présumer que l'état du modèle de l'objet de la couche session de l'agent SIP éloigné va passer à l'état d'initialisation 501 lorsqu'il reçoit cette action. Le passage de l'état 501 à l'un des états 502, 503 et 504, de l'état 502 à l'un des états 503 et 504 et de l'état 503 à l'état 504 s'effectue en réponse à la réception par le module d'événement de la couche session d'événements 101, 102, 103 ou 104. Par exemple, la réception par l'agent SIP local d'un message d'accord depuis l'agent SIP éloigné est traitée de façon à établir l'hypothèse que l'état du modèle de l'objet de la couche session de l'agent SIP éloigné a atteint l'état 504. La réception du message d'accord provoque l'émission par le module d'événement de la couche message d'un événement 103 qui est reçu par le module d'événement de la couche session, ce qui provoque le passage du modèle de l'objet de la couche session de l'agent SIP local à l'état 504 depuis l'un quelconque des états 501, 502 et 503. Le passage de l'état 504 à l'état 505 s'effectue en réponse à l'envoi par le module d'action de la couche d'une action 107, qui correspond par exemple à l'envoi par le module d'action d'une action correspondant à l'envoi d'un accusé réception par la couche message. Dans l'exemple de la figure 2b, le passage de l'état 500 à l'état 501 se fait en réponse à la réception par le module d'événement de la couche session d'un événement 108, ce dernier correspondant par exemple à la réception par la couche message d'un message d'invitation à entrer en communication. Le modèle de l'objet peut, depuis l'état 501 qui est l'état d'initialisation de la session, passer directement à l'état 504 de confirmation des opérations d'initialisation de la session si une action 110 correspondant à l'envoi d'un message de succès est transmise par le module d'action. En variante, le module d'action peut envoyer une action 109 correspondant à des tentatives d'établissement de la session, provoquant le passage de l'état 501 à l'état 502 5 qui est l'état de traitement de l'initialisation de la session. Ensuite, une action 111 correspondant à un succès est par exemple transmise par le module d'action de la couche session, provoquant le passage de l'état 502 à l'état 504. La réception par le module d'événement de la couche session d'un événement 112 correspondant par exemple à un accusé réception provoque le passage de l'état 504 à 10 l'état 505 qui est l'état d'établissement de la session. Dans les exemples des figures 2c à 2f on a représenté en vis-à-vis des modèles de l'objet de couches sessions d'un agent SIP local et d'un agent SIP éloigné tels que définis ci-dessus. Comme on peut le voir, les agents SIP local et éloigné peuvent interagir selon 15 des relations 120. L'architecture comporte encore une couche dimension agencée pour intégrer des informations relatives à différentes sessions ainsi qu'au contexte dans lequel les sessions se déroulent en un seul modèle de l'objet reposant sur deux concepts : la dimension et la communication. 20 On désigne par dimension une variable décrivant un aspect particulier du monde de l'utilisateur, comme par exemple son identité, sa localisation ou le terminal qu'il utilise. Chaque dimension possède une propre liste de valeurs possibles qui ne peuvent pas être partagées avec une autre dimension. On distingue deux types de dimensions, les dimensions de communication et les dimensions de contexte. 25 Les dimensions de communication permettent de caractériser la communication et sont au nombre de six : - � qui ? � : à savoir quelles sont les personnes impliquées dans la communication ?, - � quel terminal ? � : à savoir quels sont les terminaux utilisés pour la 30 communication ?, - � où ? � : c'est-à-dire quel est le réseau informatique disponible pour la communication ?, � quoi ? � : à savoir quel est le type de communication ?, � quand ? � : c'est-à-dire quels sont les paramètres temporels ? et, � pourquoi ? � : c'est-à-dire quel est le sujet et le but de la communication ? Les dimensions de contexte ne décrivent pas directement la communication mais identifient des facteurs qui peuvent influencer la communication comme la largeur de bande de la connexion ou la localisation de l'utilisateur. Le concept de communication est une relation abstraite entre deux ou plusieurs interlocuteurs, impliquant un échange d'informations unidirectionnel ou bidirectionnel dans un réseau informatique. Au sens de l'invention, la communication est identifiée par deux jeux de valeurs de dimensions de communication, le premier jeu décrivant l'appelant et le deuxième jeu décrivant l'appelé. L'objet de la couche dimension est l'environnement dans lequel les communications ont lieu. Cet environnement est décrit par le jeu de toutes les valeurs possibles que les dimensions peuvent avoir. Un état de l'environnement et, par conséquent du modèle de l'objet, est déterminé à un instant donné par deux facteurs, les communications établies et le contexte. Les communications établies sont représentées par des associations temporaires entre les valeurs de dimensions qui décrivent ces communications. Par exemple, une communication impliquant l'ordinateur d'un utilisateur pourrait être représentée par : - un lien entre le nom de l'utilisateur et l'ordinateur de l'utilisateur et, - une valeur de dimension temporaire correspondant à la communication. Pour ce qui est du contexte, ce dernier est dans l'exemple décrit représenté par des relations entre les dimensions, par exemple un terminal localisé à un endroit particulier ou un utilisateur possédant un terminal spécifique On a représenté à la figure 4 un exemple de représentation générique de l'état du modèle de l'objet de la couche dimension Une représentation particulière de l'état de l'objet de cette couche dimension consiste en un ensemble de liens entre des valeurs particulières de dimensions. Ces liens sont insérés et mis à jour par des modules et des informations de 30 contexte non représentés. Le modèle de l'objet de la couche dimension peut comporter des états référençants, qui correspondent à un ensemble de liens satisfaisant à une préférence prédéfinie par l'utilisateur de l'assistant intelligent. Le modèle de l'objet de la couche dimension peut également comporter des états référencés, qui correspondent à un ensemble de liens décrivant la session établie dans la couche session. Dans cet exemple, un état du modèle de l'objet de la couche dimension est représenté par quatre dimensions de communication 301, 302, 303 et 304 parmi les six dimensions de communication mentionnées précédemment, à savoir � qui ?, � � quel terminal ? �, � où ? � et � quand ? � et deux dimensions de contexte 305 et 306, à savoir la localisation de l'utilisateur et la largeur de bande. Un lien entre deux dimensions de communication implique que pour n'importe lesquelles de deux valeurs choisies parmi ces dimensions, ces valeurs ne puissent être des paramètres de la même communication à moins qu'il n'y ait un lien véritable entre celles-ci. Un lien entre deux dimensions de communication et une dimension de situation implique également que pour n'importe lesquelles de deux valeurs choisies parmi ces deux dimensions de communication, ces valeurs ne puissent être des paramètres de la même communication à moins qu'elles ne soient associées à la même valeur de la dimension de situation. Des informations relatives à l'utilisateur et au contexte de l'environnement telles que la présence de l'utilisateur, le profil du terminal de l'utilisateur et l'emplacement de ce terminal ainsi que les capacités du réseau sont reçues par des modules du contexte qui interprète les informations reçues comme des changements dans les liens et les intègre dans le diagramme de dimension. La couche dimension comporte également un module d'évènement selon l'invention qui reçoit des évènements relatifs à des changements d'états du modèle de l'objet de la couche session. Pour chaque évènement reçu, le module d'évènement traduit la session reçue en une communication en convertissant les paramètres de session dans des valeurs de dimension de communication, en utilisant par exemple des informations relatives à des abonnements d'utilisateurs. Puis, le module d'évènement peut analyser quel est l'état de la session en fonction de l'événement reçu depuis la couche session. Si l'événement reçu par le module d'événement de la couche dimension correspond au passage du modèle de l'objet de la couche session à l'état référançant d'initialisation de la session, le module d'évènement de la couche dimension ajoute un état futur à son modèle de l'objet indiquant que la communication sera établie. Si l'événement reçu par le module d'événement de la couche dimension correspond au passage du modèle de l'objet de la couche session à l'état référançant d'établissement de la session, l'état futur mentionné au paragraphe précédent devient un état actuel puisque la session est établie. Si l'événement reçu par le module d'événement de la couche dimension correspond au passage du modèle de l'objet de la couche session à l'état référençant d'arrêt de la session, la communication est supposée terminée et les liens temporaires entre les valeurs de dimensions correspondantes sont défaits. Les actions émises par le module d'action de la couche dimension correspondent à des opérations de contrôle de la communication permettant d'initialiser, de transmettre, de modifier et de terminer les communications. Pour une action destinée à une communication particulière par exemple, le module d'action de la couche dimension peut convertir les valeurs de dimension de la communication concernée dans des paramètres de session avant d' envoyer cette action au module d'action de la couche session. La couche dimension interagit également dans l'exemple décrit avec la couche de l'architecture lui étant directement supérieure, à savoir la couche utilisateur par l'intermédiaire d'événements envoyés et d'actions reçues. Un évènement est envoyé par le module d'évènement de la couche dimension au module d'évènement de la couche utilisateur lorsque le modèle de l'objet de la couche dimension atteint un état référençant. A la différence de la couche session, les états référençants du modèle de l'objet de la couche dimension ne sont pas prédéfinis mais dépendent des préférences de l'utilisateur, ces préférences étant définies au niveau de la couche utilisateur. On va maintenant décrire la couche utilisateur qui est dans l'exemple considéré la couche supérieure de l'architecture. Cette couche utilisateur est agencée pour implémenter les préférences de l'utilisateur, ces dernières consistant essentiellement à surveiller les changements pertinents en terme d'environnement de communication et à déclencher des actions manipulant les communications, tel que l'envoi, la modification de paramètres, la terminaison et l'initialisation de nouvelles communications. Une préférence implémentée dans cette couche utilisateur correspond à l'association de deux parties: une partie de condition et une partie d'action. La partie de condition d'une préférence est représentée dans le modèle de l'objet de la couche utilisateur par un état de vérification de la condition et la partie d'action de la préférence est représentée dans le modèle de l'objet de la couche utilisateur par un état d'exécution de l'action. On a représenté à la figure 4 un exemple de modèle de l'objet de la couche utilisateur. Comme on peut le voir, ce modèle correspond à quatre préférences 1l, 12, 13 et 14 et comporte des états de vérification de condition 51, 52 et 53, des états d'exécution d'action 54, 55 et 56 et des états autonomes 50 et 57. Dans l'exemple décrit, les états 51, 52, 53, 54, 55 et 56 sont tous des états 15 référencés, chacun d'eux correspondant à une configuration particulière de liens dans le modèle de l'objet de la couche dimension. Comme on peut le voir sur cette figure 4, des préférences distinctes peuvent partager la même partie de condition ou peuvent partager la même partie d'action. Ainsi, les préférences 12 et 13 partagent la même partie de condition à laquelle 20 est associé l'état 52 et les préférences 13 et 14 partagent la même partie d'action à laquelle est associé l'état 56. Chaque préférence est exécutée à la réception par le module d'événement de la couche utilisateur d'un événement prédéfini et chaque préférence provoque l'envoi par le module d'action de la couche utilisateur d'une action prédéfinie. 25 Dans l'exemple décrit, les préférences 12 et 13 partageant la même partie de condition, elles sont exécutées lorsqu'un même événement prédéfini est reçu par le module d'événement de la couche utilisateur. Toujours selon cet exemple, les préférences 13 et 14 partageant la même partie d'action, elles provoquent l'envoi d'une même action par le module d'action. 30 La partie de condition de chaque préférence définit les liens du modèle de l'objet de la couche dimension qui doivent être surveillés afin d'exécuter cette préférence. Lorsque les liens du diagramme de la couche dimension correspondent à la condition de la partie de condition d'une préférence, le modèle de l'objet de la couche dimension atteint un état référençant qui est détecté par le module d'événement de la couche dimension, ce dernier envoyant alors un évènement au module d'évènement de la couche utilisateur. Le module d'évènement de la couche utilisateur associe l'événement reçu à la préférence adaptée, ce qui entraîne le passage à un état actuel de l'état de vérification de la condition 51, 52 ou 53 selon la préférence. Puis, la partie d'action correspondante est exécutée par le module d'action de la couche utilisateur, l'état correspondant à l'exécution de l'action 54, 55 et 56 devient alors un état futur. Une fois que le module d'événement de la couche utilisateur reçoit un évènement depuis la couche dimension confirmant l'exécution de l'action, l'état futur 54, 55 ou 56 devient un état actuel, signifiant que la préférence correspondante a été correctement appliquée. L'invention n'est pas limitée aux exemples qui viennent d'être décrits. Dans les revendications, l'expression "comportant un" est comprise comme étant synonyme de l'expression "comportant au moins un" sauf si le contraire est spécifié.20 REVENDICATIONS1. Architecture informatique (1) hiérarchisée à couches multiples pour système de communication entre terminaux informatiques, l'architecture comportant au 5 moins deux couches (2a ; 2b) comportant chacune : un modèle de l'objet de la couche (3a ; 3b), ce modèle comportant plusieurs états (5a, 5b) de l'objet, un module d'événement (6a ; 6b), pour recevoir et/ou envoyer au moins un événement à une autre couche de l'architecture et, 10 - un module d'action (8a ; 8b) pour envoyer et/ou recevoir une action depuis une autre couche de l'architecture. 2. Architecture hiérarchisée selon la revendication 1, dans laquelle le module d'événement de la couche est agencé pour, à la réception d'un événement depuis une autre couche, provoquer le passage de l'état du modèle de l'objet de la couche d'un état passé à 15 un état actuel. 3. Architecture hiérarchisée selon la revendication précédente, dans laquelle le module d'action de la couche est agencé pour, à la réception d'une action depuis une autre couche, ajouter un ou plusieurs états futurs au modèle de l'objet de la couche. 4. Architecture hiérarchisée selon la revendication précédente, les états de 20 l'objet de la couche comportant l'un au moins d'un état référençant (5b1, 5b3, 5b5), d'un état référencé (5a2, 5a3) et d'un état autonome (5b4). 5. Architecture hiérarchisée selon la revendication précédente, dans laquelle le module d'événement de la couche dans laquelle un état référençant du modèle de l'objet est atteint est agencé pour détecter le passage du modèle de l'objet de la couche inférieure 25 à cet état référençant et pour envoyer au moins un événement au module d'événement d'une couche supérieure de l'architecture. 6. Architecture hiérarchisée selon la revendication 5, dans laquelle le module d'événement de la couche supérieure est agencé pour recevoir l'événement et pour provoquer le passage du modèle de l'objet de la couche supérieure à un état référencé. 30 7. Architecture hiérarchisée selon l'une quelconque des revendications précédentes, dans laquelle le module d'action d'une couche est agencé pour envoyer uneaction au module d'action d'une couche inférieure de l'architecture pour permettre le passage du modèle de l'objet de ladite couche à un autre état. 8. Architecture hiérarchisée selon la revendication 7, dans laquelle le module d'action de la couche inférieure est agencé pour déterminer, en réponse à l'action reçue, un plan consistant en une séquence d'au moins un état futur du modèle de l'objet de la couche inférieure, notamment une pluralité d'états futurs du modèle de l'objet. 9. Architecture hiérarchisée selon la revendication 8, dans laquelle le module d'action de la couche inférieure est agencé pour provoquer le passage d'un état futur à l'autre de la séquence d'états du modèle de l'objet de la couche inférieure en réponse à la réception d'un événement correspondant par le module d'événement de la couche inférieure ou à l'envoi d'une action correspondante par le module d'action de la couche inférieure à une couche encore inférieure. 10. Architecture hiérarchisée selon l'une des deux revendications précédentes, la séquence d'états futurs se terminant par un état référençant. 11. Architecture hiérarchisée selon l'une quelconque des revendications précédentes, comportant trois couches et une quatrième couche comportant un module d'événement (6), un module d'action (3) et étant dépourvue de modèle de l'objet. 12. Architecture hiérarchisée selon la revendication précédente, dans laquelle au moins une couche est implémentée selon le protocole SIP. 13. Procédé de modification de l'état du modèle de l'objet d'une couche d'une architecture de couches hiérarchisées pour réaliser un système de communication entre deux terminaux informatiques, procédé dans lequel on modifie l'état du modèle de l'objet en réponse à au moins une information reçue depuis au moins une couche adjacente à ladite couche ou envoyée à au moins une couche adjacente par ladite couche. 14. Procédé selon la revendication précédente, dans lequel on modifie l'état du modèle de l'objet de ladite couche en réponse à une information reçue depuis au moins une couche adjacente à ladite couche. 15. Procédé selon la revendication 14, dans lequel l'information reçue par ladite couche résulte du passage de l'état du modèle de l'objet de l'au moins une couche 30 adjacente d'un état à un autre état. 16. Procédé selon la revendication précédente, dans lequel la couche adjacente est une couche directement supérieure à ladite couche dans l'architecture hiérarchisée etdans lequel l'information reçue par ladite couche correspond à la réception par le module d'action de ladite couche d'une action depuis le module d'action de la couche directement supérieure. 17. Procédé selon la revendication précédente, dans lequel la réception de l'action par le module d'action de ladite couche génère dans le modèle de l'état de ladite couche un plan comportant une séquence d'au moins un état futur, le passage d'un état futur à un autre état futur de la séquence étant conditionné par la réception par un module d'événement de ladite couche d'un événement ou par l'envoi par le module d'action de ladite couche d'une action. 18. Procédé selon la revendication précédente, dans lequel la séquence d'états futurs se termine par un état référençant. 19. Procédé selon l'une quelconque des revendications 13 à 18, dans lequel la couche adjacente est une couche directement inférieure à ladite couche dans l'architecture hiérarchisée et dans lequel l'information reçue par la dite couche est la réception d'un événement par le module d'événement de ladite couche depuis la couche directement inférieure dans l'architecture hiérarchisée. 20. Procédé selon la revendication précédente, dans lequel la réception de l'événement par le module d'événement de ladite couche provoque le passage de l'état du modèle de l'objet de ladite couche à un état référencé. 21. Procédé selon l'une quelconque des revendications 13 à 20, dans lequel on modifie l'état du modèle de l'objet de ladite couche en réponse à une information envoyée à au moins une couche adjacente à ladite couche. 22. Procédé selon la revendication 21, dans lequel la couche adjacente est une couche directement inférieure à ladite couche dans l'architecture hiérarchisée et dans lequel l'information envoyée à la couche directement inférieure est l'envoi d'une action par le module d'action de ladite couche à un module d'action de la couche directement inférieure. 23. Procédé selon la revendication 14, dans lequel la couche adjacente est dépourvue de modèle de l'objet et dans lequel l'information reçue par ladite couche depuis la couche adjacente ne résulte pas du passage d'un état à un autre du modèle de l'objet de la couche adjacente. 5 24. Architecture de couches hiérarchisées pour réaliser un système de communications entre terminaux informatiques comportant au moins deux couches comportant chacune : un modèle de l'objet de la couche comportant une pluralité d'états, des moyens pour modifier l'état du modèle de l'objet de la couche en fonction d'au moins une information envoyée à au moins une couche adjacente et/ou reçue depuis au moins une couche adjacente. 10