Brevet FR2807544A1 — publié le 20011012

Architecture informatique pour la communication via un réseau de télécommunication. La présente invention concerne le domaine des échange de données à travers un réseau de télécommunication, notamment un réseau Internet, un Intranet ou un extranet. L'échange de données s'effectue à travers architecture informatique pour la communication via réseau télécommunication mettant en oeuvre un plusieurs serveurs et des postes clients. Les échanges de données se font selon protocoles normalisés. Ils peuvent prendre la forme de - Courriers électroniques (E-mail) - Forums de discussions (News group) - Diffusion d'informations (World Wide Web) Selon des protocoles diversifiés (SMTP, HTTP FTP, Gopher, NNTP, correspondant à des ports différents). Par ailleurs, l'utilisateur personnalise son équipement informatique client en fonction de ses accès, de ses données personnelles telles les sites préférés, carnet d'adresses. De ce fait, lorsque l'utilisateur change d'équipement client, par exemple lorsqu'il est déplacement, ou tout simplement ne dispose pas d' équipement qui lui est personnellement affecté, il rencontre des difficultés pour accéder aux fonctions habituelles. Pour remédier à cet inconvénient l'invention concerne selon son acception la plus générale une architecture informatique pour la communication via un réseau de télécommunication, composé de serveurs et de clients, chaque client comportant un navigateur propre à interpréter les protocoles Internet. L'architecture selon l'invention comporte une mémoire installée dans le serveur ou le client, dans laquelle est chargée application apte à recevoir des requêtes pour procéder à la distribution de profil utilisateur à travers le réseau de manière que l'utilisateur puisse à la fois retrouver ses données à chaque fois qu'il se connecte réseau de télécommunication, ainsi que la configuration personnelle de l'application. Avantageusement, ladite application est stockée dans une mémoire du serveur ou du client, et ce qu'elle comporte module Processeur dédié (Custom Process Manager) pour l'identification du type d'accès et l'appel à un gestionnaire du protocole ad hoc Gestionnaire de protocole dédié (Custom Protocol Handler), pour émettre les requêtes élémentaires en utilisant un des ports utilisés par les protocoles INTERNET ou autre port disponible pour accéder aux données personnelles sauvegardées sur le réseau. Selon une variante, le module Gestionnaire de protocole dédié (Custom Protocol Handler) peut également utiliser les requêtes plus évoluées pour transmettre les demandes complexes au serveur qui sauvegarde les données profil utilisateur. Selon un mode de réalisation particulier, l'application comporte un module User Interface (UI) constitué par une interface de communication avec des périphériques d'entrée, et au moins un périphérique de sortie, un module Process Manager pour le traitement des requêtes ou des données venant du module UI ledit module disposant d'une matrice de traitement des requêtes, un module Processeur de protocole natif (Native Process Manager) constituant le centre de traitement des requêtes normalisées Internet, un module Processeur de protocole natif (Native Process Manager ) constitue un gestionnaire d accès au réseau utilisant les standards Internet, un module Processeur dédié (Custom Process Manager) pour la gestion des requêtes de traitements spécifiques aux données profil utilisateur et un module Gestionnaire de protocole dédié (Custom Protocol Handler), gestionnaire d'accès à ces données via un protocole de transfert réseau spécifique. Le module Processeur dédié (Custom Process Manager) dispose d'une table de corrélation entre les types de requêtes et le module de traitement associés, le module Gestionnaire de protocole dédié (Custom Protocol Handler). L'invention concerne également un équipement de communication pour une architecture informatique selon l'une au moins des revendications précédentes comportant un calculateur et une mémoire informatique dans laquelle est chargée une application réseau caractérisé en ce ladite application comporte un module UI constitué une interface de communication avec des périphériques entrée, et au moins un périphérique de sortie, un module Processeur dédié (Process Manager) pour le traitement des requêtes ou données venant du module UI, ledit module disposant 'une matrice de traitement des requêtes, module Processeur de protocole natif (Native Process Manager ) constituant le centre de traitement des requêtes, un module Processeur de protocole natif (Native Process Manager ) pour un accès aux ressources réseau via un protocole de transfert Internet, un module Processeur dédie (Custom Process Manager) pour la gestion des requêtes demande d'accès aux ressources réseau via le module Gestionnaire de protocole dédié (Custom Protocol Handler), un gestionnaire de protocoles de transfert de réseau spécifiques. L'invention sera mieux comprise à la lecture de la description qui suit, se référant aux dessins annexés relatifs à des modes de mise en oeuvre non limitatifs où - la figure 1 représente une vue schématique d'une architecture de télécommunication selon l'invention ; - la figure 2 représente le schéma fonctionnel de la partie cliente de l'architecture. - la figure 3 représente le schéma fonctionnel de la partie serveur de l'architecture. L'architecture pour la mise en oeuvre de 'invention est une architecture client/serveur . 1. Description de la partie client La partie cliente représentée schématiquement figure 2 présente un système de navigation de l'INTERNET intégré constitué par l'application (200). L'application (200) peut fonctionner à partir 'un poste de l'utilisateur (101) ou à partir d'un autre de machine comme un serveur (102), (103) (104). Elle permet, à partir d'une interface unique, de naviguer à travers le réseau INTERNET, de participer aux forums de discussion (Newsgroup), d'accéder à une messagerie personnelle ou professionnelle de utilisateur et surtout d'accéder aux données personnelles de l'utilisateur: Sites Internet préférés, Carnet d'adresses, services auxquels il est abonné. Que ce soit dans le cas de navigation des sites Internet ou de l'utilisation de messagerie, application peut à tout moment alerter l'utilisateur changement d'état de sa messagerie, cela peut se manifester sous forme de signaux d'alerte, de messages de notification ou autres. Pour fournir plus d'interactivité avec l'utilisateur dans sa pratique de navigation Internet, l'application (200) est dotée d'un procédé de distribution de profil utilisateur à travers le réseau via le module Processeur dedié (Custom Process Manager) 205) puis Gestionnaire protocole dédié (Custom Protocol Handler) (206) de maniere qu'il puisse à la fois retrouver ses données à chaque fois qu'il se connecte au réseau INTERNET et la configuration personnelle de l'application. Le profil utilisateur contient deux types d'informations # Informations relatives aux configurations personnelles de l'application # Données personnelles informations relatives aux configurations personnell de l'application sont récupérées automatiquement par l'application (200) et ne demandent pas une interaction avec l'utilisateur sauf dans le cas de configuration. Dans la suite, on se réfère profil utilisateur quand on parle des données personnelles utilisateur. Lorsque l'utilisateur demande un acces à ses données personnelles sauvegardées sur un serveur 102) par exemple, à travers le réseau (100), le module Processeur dédié (Custom Process Manager) (205) identifie le type d'accès et fait appel à un gestionnaire du protocole ad hoc, le module Gestionnaire de protocole dédié (Custom Protocol Handler) (206), pour émettre les requêtes en utilisant un des ports utilisés par les protocoles INTERNET. Le gestionnaire Gestionnaire de protocole dédie (Custom Protocol Handler) (206) utilise un port bien spécifique aux standards INTERNET pour entrer en contact avec le serveur en question, puis il émet les requêtes supplémentaires pour transmettre les demandes plus complexes au serveur et termine l'opération soit récupérant les données demandées soit en retournant un signal de fin de traitement au module Processeur dédié (Custom Process Manager) (202). Et l'utilisateur retrouve par ce biais données. L invention concerne l'intégration des services INTERNET (navigation Internet, messagerie [e-mail], forum de discussion [Newsgroup] ) dans l'application (200) et surtout les procédés utilisés pour traiter les données personnell de l'utilisateur: le profil mobile utilisateur. L'application (200) peut être un navigateur INTERNET un bout de programme exécuté à l'intérieur d'un navigateur (un plug-in) ou autre type d'applications orientées WEB, permet à l'utilisateur d'avoir une plus grande interaction avec son profil personnel sauvegardé sur un des serveurs (102) à travers le réseau (100). Le réseau (100) peut être INTERNET, INTRANET ou EXTRANET. Le module UI (201) C'est une interface par laquelle l'utilisateur interagit avec le système, il comprend deux éléments: Périphériques d'entrée [Input] La souris Les dispositifs matériels: sphère de commande [Trackball], manette de commande (Joystick), ou autres dispositifs matériels qui peuvent envoyer signaux de contrôle à l'application J Les données en provenance d'autres applications Périphériques de sortie [Output] L'écran de Télévision L'écran d'ordinateurs L'écran d'une console de jeux L'écran de contrôle des bornes interactives Le module Process Manager (202) Le centre de traitement des requêtes ou des données venant du module UI (201) Il dispose d'une matrice de process toutes les requêtes traitées par l'application (2 ) sait différentier celles qui concernent la demande ressources réseau via les protocoles de transfert de réseau standardisé Internet, définis dans les RFCs respectifs, et celles qui relèvent de la demande spécifique relative au traitement des données du profil utilisateur. module Processeur de protocole natif (Native Process Manager ) (203) centre de traitement des requêtes Le module Processeur de protocole natif (Native Process Manager ) (204) Le module Processeur dédié (Custom Process Manager) (205) Ce module gère les requêtes de demande d'accès aux ressources réseau via les protocoles de transfert de réseau spécifiques, qui ne sont pas standardisés au niveau de l'INTERNET. I1 dispose d'une table de corrélation entre types de demande de ressources et le module de traitement associé, le module Gestionnaire de protocole dédié (Custom Protocol Handler) (206). I1 peut recevoir du module Process Manager (202) les types de requêtes suivantes: Requêtes de transaction de données r Requêtes de messagerie instantanée Requêtes de transfert de données simples Il traduit ensuite ces requêtes en types transfert de données élémentaires et qui sont traités niveau du module Gestionnaire de protocole dédié (Custom Protocol Handler) (206) Le module Gestionnaire de protocole dédié (Custom Protocol Handler) (206) Le module traite les transferts élémentaires de données à travers le réseau. Il peut utiliser un ou plusieurs standards suivants: # HTTP au port 80 TCP/UDP # FTP au port 23 TCP/UDP # SMTP au port 25 TCP/UDP # LDAP au port ? # Gopher au port ? # POP3 au port ? # IMAP4 au port ? Mais il peut aussi utiliser les protocoles ci- dessus: HTTP, FTP, SMTP, LDAP, Gopher, POP3, IMAP4 sur les ports différents Avec ajout des commandes traitements supplémentaires pour envoyer les requêtes traitements plus spécifiques Le principe de fonctionnement application (200) peut être une application orientée un navigateur WEB, un plug-in ou une application traite les pages WEB: HTML, XHTML ou XML et qui permet 1 interaction avec l'utilisateur. L'utilisateur utilise un dispositif matériel comme une souris pour interagir avec le système via le module UI (201). Séquence de démarrage Lorsque l'application (200) est lancee, une fenêtre de saisie s'affiche et demande à l'utilisateur d'entrer le nom du serveur d'hébergement de son profil suivi de son nom de session et le mot de passe. Ces informations sont arrivées au module Process Manager (202) qui lance une sequence d'authentification en faisant appel au module Processeur dédié (Custom Process Manager) (205), lequel va lancer un gestionnaire Gestionnaire de protocole dédié (Custom Protocol Handler) (206) spécifique pour authentifier l'utilisateur au près du serveur d'hébergement de son profil. On peut automatiser cette cédure d'authentification par une configuration de l'application (200). Lorsque la procédure d'authentification réussit, l'utilisateur peut utiliser l'application comme un navigateur Internet, comme un client de messagerie, comme un lecteur de nouvelles pour participer aux forums de discussion à la fois. Si l'authentification échoue, l'utilisateur peut ou non accéder à une fonctionnalité de navigation de l'application (200) suivant la configuration lors de son installation. Cas de messagerie [E-mail ou de Newsgroup] Considérons un cas où l'utilisateur utilise sa souris pour cliquer sur un drapeau [drapeau [tag]] HTML, exemple: Mailto:jacques.dupont@oxyalis.com, pour envoyer un message. requête est reçue par le module Process Manager (202). module intercepte toutes les requêtes venant du module (201), identifie la requête reçue comme requete de traitement normalisée par le standard HTML, XHTML et et décide 'appeler le module Processeur de protocole natif (Native Process Manager ) (203) qui est exclusivement conçu pour traiter ce type de requêtes. Le module Processeur de protocole natif (Native Process Manager ) (203) va examiner le type de traitement approprié pour ce drapeau [tag] à partir de sa table de process. se trouve que le drapeau [tag] Mailto, tout comme le drapeau [tag] News , est associé à un traitement spécifique. Au lieu de lancer un client de la messagerie du poste, le module Processeur de protocole natif (Native Process Manager ) (203) passe la main au module Processeur dédié (Custom Process Manager) (205). Le module Processeur dédié (Custom Process Manager) (205) est conçu pour effectuer un certain nombre de tâches spécifiques et qui ne sont pas standardisées au niveau de l'INTERNET. A la réception d'une demande de traitement pour le drapeau [tag] Mailto, le module examine table de process et effectue les tâches associées: Procédure d'authentification si l'utilisateur n'est pas connu de l'application lors de la phase de démarrage Composition de message Le module Gestionnaire de protocole dédié Custom Protocol Handler) (206) prend en charge ensuite de remise du message vers le serveur qui a authentifié 'utilisateur, lequel s'occupe de la livraison vers les boîtes aux lettres des destinataires. Cas d'accès aux données réseau: profil utilisateur Prenons le cas où l'utilisateur, ou une application, veut accéder aux données sauvegardées sur un des serveurs (102) à travers le réseau (100). Le module Process Manager (202) reçoit la requête et vérifie le type de demande d accès aux ressources réseau. Si la demande d'accès aux ressources réseau s'effectue via un des protocoles standards de l'INTERNET comme HTTP FTP, SMTP,..., il passe la main au module Processeur de protocole natif (Native Process manager ) (203) . Le module Processeur de protocole natif (Native Process Manager ) (203) va alors examiner de plus prés la requête pour savoir si il y a un traitement annexe à faire avant d'évoquer le gestionnaire Processeur de protocole natif (Native Process Manager ) (204) approprié. Le gestionnaire Processeur de protocole natif (Native Process Manager ) (204) prend en charge le téléchargement effectif de la ressource demandée selon les règles définies dans les protocoles INTERNET. Les données sont ensuite récupérées par le module Processeur de protocole natif (Native Process Manager ) (203) et ensuite au niveau module Process Manager (202) qui décide des traitements ultérieurs. la requête de demande de ressources 'est pas une requête reconnue comme standardisée au niveau de l'INTERNET, ce qui est le cas pour le traitement des données profil utilisateur, alors le module Process Manager (202) fait appel au module Processeur dédié (Custom Process Manager) (205). Le module Processeur dédié (Custom Process Manager) (205) va traiter la requête en conséquence et choisit dans sa table de process un gestionnaire approprié pour le transfert de données. Le gestionnaire approprié, le module Gestionnaire de protocole dédié (Custom Protocol Handler) (206), va ensuite entamer les différentes séquences de transfert de données pour récupérer les données. Les données sont ensuite reçues par le module Processeur dédié (Custom Process Manager) (205) et effectue le traitement supplémentaire le échéant ou les remettre au module Process Manager (202) pour terminer le traitement demandé par l'utilisateur. 2. Application serveur L'application (300) d'abord une application Internet dont le fonctionnement spécifié par les RFCs spécifiques et puis elle aussi dotée d'une fonctionnalité supplémentaire pour pouvoir traiter les requêtes venant du réseau (100 et communiquer avec les autres serveurs (102), (103) ou ) du réseau (100). Le réseau (100) peut être INTERNET, INTRANET ou EXTRANET. L'application (300) peut traiter un ou plusieurs standards INTERNET, c'est à dire qu'elle peut "écouter" les requêtes sur plusieurs ports à la fois. Selon l'invention, 'application (300) attend une requête venant du réseau ( ). Suivant type de requêtes reçues, l'application (300) comporte ou non comme une application Internet. Dans le de requêtes non normalisées Internet, celles-ci sont reçues à l'application (300) suivant une des deux procédés suivants: # La requete est encapsulée dans le protocole INTERNET # La requête est envoyée suivant une séquence spécifique qui s'ajoute au protocole INTERNET. Suivant la nature de la requête reçue, l'application (300) exécute une tâche dédiée et retourne le cas échéant le résultat ' l'application appelante, celle-ci peut être une application cliente de type (200) ou une application serveur, bien elle demande des informations supplémentaires sur d'autres serveurs du réseau (100) via le protocole normalisé Internet ou autre pour terminer l'opération Les requêtes utilisées dans le traitement des données profil utilisateur sont de trais types: # Requêtes transaction de données # Requêtes messagerie instantanée # Requêtes transfert de données simples Ces trois principaux types sont reçus et traités au niveau de l'application (300) via le module Processeur dédié (Custom Process Manager) (305) module Protocol Interceptor (301) module Processeur de protocole natif (Native Process Manager ) (302) Le module Processeur de protocole natif (Native Process Manager ) (303) Le module Gestionnaire de protocole dédié (Custom Protocol Handler) (304) Le module est un gestionnaire de protocole de communication en provenance du module Protocole Interceptor (301). Ce module dispose d'un ensemble de codes prédéfinis pour le transfert de données. Le module Processeur dédié (Custom Process Manager) (305) Le principe de fonctionnement Une application (300) orientée réseau reçoit une requête de traitement. Le module Protocole Interceptor (301) détermine le type de protocole concerné. S'il s'agit d'un protocole Internet standardisé: SMTP, HTTP, FTP, Gopher, POP3 ou IMAP4, il se la main au gestionnaire Processeur de protocole nati (Native Process Manager ) (302) ad hoc pour entamer le dialogue en conséquence. Le type de traitement dans ce cas est totalement spécifié dans les RFCs. le module Protocole Interceptor (301) reçoit un autre de protocole qui n'est pas spécifié dans les RFCs, il identifie le type de protocole et choisit dans la table de process un gestionnaire Custom Prototcol Handler (304) correspondant. Le module Gestionnaire de protocole dédie (Custom Protocol Handler) (304) est choisi et entame communication avec l'application appelante et récupère données. Le module Processeur dédié (Custom Process Manager) (305) est ensuite appelé pour traiter les données et décide actions en conséquence. Voici la liste des requêtes qu'il peut traiter: Requêtes de transaction de données Requêtes de messagerie instantanée Requêtes de transfert de données simples La résultante de ces actions sont de deux formes suivantes: # Formulation de requêtes de traitement ou d'accès aux ressources réseau en utilisant les protocoles standards ou les protocoles spécifiques. # Retour des données traitées à l'application appelante. REVENDICATIONS 1 - Architecture informatique pour la communication via un réseau de télécommunication, composé de serveurs et une pluralité de clients, chaque client comportant un navigateur propre à interpréter les protocoles Internet, caractérisée en ce que l'architecture comporte une mémoire installée dans le serveur ou client, dans laquelle est chargée une application (2 ) apte ' envoyer des requêtes sur une pluralité de ports procéder au traitement de profil utilisateur à travers réseau de manière que l'utilisateur puisse à la fois retrouver ses données à chaque fois qu'il se connecte réseau de télécommunication, ainsi que la configuration personnelle de l'application. 2 - Architecture informatique pour communication via un réseau de télécommunication, selon revendication 1 caractérisée en ce que ladite application (200) stockée dans une mémoire du serveur ou du client, et en qu'elle comporte un module Processeur dédié (Custom Process Manager) (205) pour l'identification type 'accès et l'appel à un gestionnaire du protocole hoc, module convertisseur Custom Process Handler (20 , pour émettre les requêtes en utilisant un des ports utilises par les protocoles Internet et pour traiter les demandes d'accès aux données personnelles sauvegardées sur réseau. 3 - Architecture informatique pour la communication via un réseau de télécommunication, selon la revendication 2 caractérisée en ce que le module Gestionnaire de protocole dédié (Custom Protocol Handler) peut utiliser un port spécifique ou non aux standards INTERNET pour entrer en contact avec serveur, et omporte des moyens pour émettre requêtes supplémentaires pour transmettre les demandes complexes au serveur et récupérer des données demandées retournant un signal de fin de traitement au module Processeur dédié (Custom Process Manager) (202). 4 - Architecture informatique pour la communication via un réseau de télécommunication, selon une au moins des revendications précédentes caractérisée ce que l'application comporte un module UI (201) constitué par une interface de communication avec des périphériques d'entrée, et au moins un périphérique de sortie, un module Process Manager (202) pour le traitement des requêtes ou des données venant du module UI (201), ledit module (202) disposant d'une matrice de traitement des requêtes, un module Processeur de protocole natif (Native Process Manager ) (203) constituant le centre de traitement des requêtes, un module Processeur de protocole natif (Native Process Manager ) (204) constitue un gestionnaire de transfert réseau via le protocole Internet, un module Processeur dédié (Custom Process Manager) (205) pour la gestion des requêtes de demande 'accès aux module ressources réseau via un gestionnaire ad Gestionnaire de protocole dédié (Custom Protocol Handler) (206) pour gérer les protocoles de transfert de réseau spécifiques. 5 - Architecture informatique pour la communication via un réseau de télécommunication, selon la revendication 2 caractérisée en ce que le module Processeur dédié (Custom Process Manager) (205) dispose une table de corrélation entre les types de demande de ressources et le module de traitement associés. 6 - Equipement de communication pour une architecture informatique selon l'une au moins des revendications précédentes comportant un calculateur et une mémoire informatique dans laquelle est chargée une application réseau caractérisé en ce que ladite application comporte un module UI (201) constitué par une interface de communication avec des périphériques d'entrée, et au moins un périphérique de sortie, un module Process Manager (202) pour traitement des requêtes ou des données venant du module (201), ledit module (202) disposant d'une matrice de traitement des requêtes, un module Processeur de protocole natif (Native Process Manager ) (203) constituant centre de traitement des requêtes, un module Processeur protocole natif (Native Process Manager ) (204) constitue un gestionnaire de transfert réseau via le protocole Internet, un module Processeur dédié (Custom Process Manager) (205) pour la gestion des requêtes de demande d'accès aux ressources réseau via un gestionnaire ad hoc , module Gestionnaire de protocole dédié (Custom Protocol Handler) (206), pour gérer les protocoles de transfert de réseau spécifiques. 7 - Procédé de composition de message électronique en utilisant une architecture informatique conforme à la revendication principale, caractérise en ce qu'il comprend les étapes suivantes: # Réception de la requête de composition de message au niveau d'un module Process Manager d'une interface informatique # Demande d'authentification auprès d'un serveur via le réseau par l'intermédiaire d'un module Processeur dédié Custom Process Manager) et Gestionnaire de protocole dédié (Custom Protocol Handler) # Envoi de message saisi via le module Gestionnaire de protocole dédié (Custom Protocol Handler)