Brevet FR2711260A1 — publié le 19950421

La présente invention concerne des systèmes de téléconférence. De façon plus spécifique, la présente invention concerne des mécanismes de communication de données entre plusieurs participants dans un système de conférence électronique. L'une des zones de développement majeur des réseaux d'ordinateur est le domaine des conférences électroniques. Les conférences assurent la capacité de réaliser une "réunion" électronique en ligne entre plusieurs utilisateurs de systèmes d'ordinateurs situés à divers emplacements. Des utilisateurs situés à plusieurs sites peuvent communiquer entre eux comme s'ils étaient dans le même local. En utilisant de tels programmes d'application, les systèmes modernes de communication ont apporté la possibilité de réaliser une réunion dans laquelle tous les utilisateurs participent à la réunion par l'intermédiaire de leurs systèmes individuels d'ordinateurs et partagent des données, des graphiques, des textes et d'autres types d'information. Des utilisateurs peuvent communiquer entre eux en partageant des données sous forme d'image graphique, de texte ou d'autres annotations et d'autres informations représentées sur l'affichage du système d'ordinateur. Ceci est analogue à une réunion dans laquelle les participants peuvent, au cours d'une réunion face à face, afficher l'un à l'autre des informations sur un tableau blanc ou noir et d'autres participants peuvent ajouter des annotations, effacer le tableau ou le modifier d'une autre manière. On prévoit également que des données vidéo pourront aussi être partagées parmi plusieurs utilisateurs reliés au cours de telles téléconférences au fur à mesure que la largeur de bande du milieu de communication s'améliore et que des normes de compression de données graphiques deviennent aussi plus robustes. L'une des.. exigences d'un système électronique de conférence est le besoin de former des répliques des mêmes données sur les affichages de tous les utilisateurs qui participent à la conférence. De tels systèmes mettent typiquement en oeuvre cette capacité de diverses manières. La plus commune est le modèle client/serveur dans lequel un noeud unique relié agit comme "serveur" d'autres noeuds du système et les autres noeuds reliés à la conférence agissent comme asservis ou clients du processus serveur. Ainsi, chacun des clients reçoit simplement une donnée venant de la machine centrale pour mettre à jour ses affichages. De tels systèmes dépendent cependant totalement du service qui est fourni par le serveur et du débit du milieu de communication. Evidemment, des systèmes dans lesquels les clients agissent simplement comme affichage et comme entrées de demandes d'utilisateurs souffrent de problèmes sévères de performance en raison des mises à jour de données venant du serveur qui résultent de cette situation, ce qui est typiquement traité de façon sérielle par le serveur. Une autre solution de l'art antérieur destinée à maintenir tout l'affichage d'un participant dans un système de conférence se fie de façon synchrone à un système réparti client/serveur. Selon une approche répartie client/serveur, une structure objet partagée est maintenue sur le serveur et les clients sont avisés de modifications de cette information partagée au moyen d'alertes ou de démonstrations. L'inconvénient de cette approche, qui est semblable à l'approche centralisée client/serveur est la nécessité de se fier à l'architecture elle-même. Ceci inclut une application de conférence de données qui doit pouvoir relier plusieurs utilisateurs sur une ligne téléphonique d'un point à un autre sans exiger d'accès à un serveur commun centralisé. Dans l'approche client/serveur, en outre, la performance souffre fortement parce que des demandes d'addition ou d'annulation d'objet, par exemple des annotations, des images graphiques ou une autre information, sur un affichage d'un participant dépend entièrement d'une communication venant du serveur. Ainsi, une performance en temps réel souffre sévèrement, dans les modèles client/serveur de l'art antérieur, puisque l'approbation d'agir sur des objets et de les manipuler sur un affichage d'un participant dépend entièrement d'un ensemble complet de variables dépendantes, par exemple le nombre de demandes en attente au serveur, le débit du milieu de communication, le nombre de participants reliés, etc. Une autre approche encore de l'art antérieur pour maintenir le caractère synchrone de plusieurs participants dans un système de conférence est l'utilisation d'un système réparti orienté vers l'objet. Il s'agit ici d'une approche généralisée qui est basée, selon une solution de l'art antérieur, sur des extensions du langage appelé SmallTalk lui-même. Dans ce système de l'art antérieur, des objets "locaux" envoient des messages à des objets "mandataires" qui sont des représentants locaux d'objets dans l'espace objet "partagé". Les objets mandataires communiquent avec les objets réels par l'intermédiaire d'un mécanisme dit d'Appel de Procédure éloignés, ou RPC. L'appel de procédure éloignés est un protocole qui gouverne le procédé au moyen duquel une demande active des processus sur d'autres noeuds et restitue les résultats. Un tel mécanisme classique est défini par Sun Microsystems, Inc. et est décrit dans le document RFC-1057 qui fournit une norme de lancement et de commande de processus sur des systèmes d'ordinateur éloignés ou répartis. Le problème de cette approche consiste en sa généralité qui exige un support extensif pour partager un objet quelconque tout en ne faisant aucune supposition concernant le comportement des objets. Ceci souffre de deux inconvénients. En premier lieu, un "système SmallTalk" complexe est nécessaire pour supporter la répartition d'objets en général. En deuxième lieu, le problème de simultanéité pour un objet quelconque est difficile parce que des participants multiples peuvent disposer d'objets divers dans leurs systèmes, et ces différents objets peuvent ne pas être susceptibles de communiquer avec les utilisateurs restants. Un autre inconvénient encore des systèmes de conférence de données de l'art antérieur est leur capacité à supporter le transfert de très grands blocs d'information. Typiquement, ces systèmes se fient à des schémas de communication d'un point à un autre dans lesquels des noeuds individuels, comme le serveur dans le modèle client/serveur, doivent transmettre l'information d'un noeud individuel vers le serveur et ensuite depuis le serveur vers les systèmes des participants restants. De plus, les transferts de très grands éléments de données, par exemple des fichiers et/ou des images ou d'autres données, consomment des quantités importantes de ressources du système et de la largeur de bande du milieu de communication. Ainsi, les systèmes de conférences de l'art antérieur souffrent de pénalisations sévères de leurs performances, provoquées par la quantité de données qui peut être transmise à l'intérieur du système pendant une conférence éloignés. Les systèmes de conférence de données de l'art antérieur souffrent donc de nombreux inconvénients auxquels la présente invention veut remédier. L'un des buts de la présente invention est donc de réaliser un système de conférence de données dans lequel une performance en temps réel de participants individuels dans un système de conférence de données ne souffre pas des problèmes de performance dus au débit du milieu. Un autre but de la présente invention est de réaliser un système perfectionné de conférence de données qui permette à des utilisateurs d'obtenir de leurs systèmes individuels, pendant la conférence, une réponse plus ou moins en temps réel. Un autre but de la présente invention est de remédier aux inconvénients de l'art antérieur du modèle client/serveur réalisé dans certaines applications de conférence. Un autre but de la présente invention est de réaliser un système qui réalise une simultanéité parmi plusieurs participants dans une application de conférence, sans cependant souffrir d'inconvénients inhérents qui résulteraient d'impacts en temps réel sur la performance provoqués par de telles exigences de simultanéité. Un autre but encore de la présente invention est d'offrir la capacité de transférer de très grands éléments de données sans impact sur la performance en temps réel d'utilisateurs dans un programme d'application de conférence. Pour atteindre ces buts, la présente invention fournit, selon un premier aspect, un procédé de transfert, mis en oeuvre dans un système de conférence électronique dans lequel une donnée est partagée entre plusieurs participants pendant une conférence électronique, de blocs de données de grand objet entre lesdits participants pendant ladite conférence électronique caractérisé en ce qu'il comprend les étapes consistant à: a. recevoir une demande asynchrone de données de grand objet; b. placer ladite demande dans une file d'attente de demandes; c. recevoir une demande asynchrone de modification de priorité dans ladite file d'attente de demandes; d. déterminer une capacité de milieu de transport; e. segmenter en blocs de données lesdites données de grand objet, une dimension desdits blocs de données étant variable et correspondant à ladite capacité dudit milieu de transport; f. transférer lesdites données de grand objet demandées à chacun desdits participants par l'intermédiaire dudit milieu de transport; et g. enlever ladite demande de ladite file d'attente de demandes lors de l'achèvement de l'étape d'envoi desdites données de grand objet demandées. De préférence, ledit grand objet peut être un grand objet binaire, ou BLOB. Dans ce cas, le procédé peut comprendre en outre l'étape consistant à ne transférer un BLOB d'un participant à un autre participant que si un état de transfert indique la disponibilité pour envoi. et/ou ladite étape de mise en place de ladite demande dans une file d'attente de demandes peut alors inclure en outre une étape de maintien de file d'attente de transfert qui inclut une entrée pour chaque demande de transfert d'un ou plusieurs BLOB, le procédé pouvant dès lors comprendre de plus outre une étape consistant à modifier la priorité de ladite file d'attente de transfert si une demande de modification de priorité est reçue d'un participant. Selon un deuxième aspect, la présente invention réalise un appareil inclus dans un système de conférence électronique dans lequel une donnée est partagée entre plusieurs participants pendant une conférence électronique, et servant à transférer des blocs de données de grand objet entre lesdits participants pendant ladite conférence électronique, caractérisé en ce qu'il comprend: a. un moyen de réception d'une demande asynchrone de données de grand objet; b. un moyen de mise en place de ladite demande dans une file d'attente de demandes; c. un moyen de réception d'une demande asynchrone de modification de priorité dans ladite file d'attente de demandes; d. un moyen de détermination d'une capacité de milieu de transport; e. un moyen de segmentation desdites données de grand objet en blocs de données, une dimension desdits blocs de données étant variable et correspondant à ladite capacité dudit milieu de transport; f. un moyen de transfert desdites données de grand objet demandées à chacun desdits participants par l'intermédiaire dudit milieu de transport; et g. un moyen d'enlèvement de ladite demande, hors de ladite file d'attente de demandes, lors de l'achèvement de l'étape d'envoi desdites données de grand objet demandées. Ledit grand objet peut être un grand objet binaire, ou BLOB. Dans ce cas, l'appareil peut comprendre en outre un moyen permettant de ne transférer un BLOB d'un participant à un autre participant que si un état de transfert indique la disponibilité pour envoi et/ou ledit moyen de mise en place de ladite demande dans une file d'attente de demandes inclut en outre un moyen de maintien de file d'attente de transfert qui inclut une entrée pour chaque demande de transfert d'un ou plusieurs BLOB, l'appareil pouvant dès lors comprendre en outre un moyen de modification de la priorité de ladite file d'attente de transfert si une demande de modification de priorité est reçue d'un participant. D'autres buts, avantages et particularités de la présente invention ressortiront de l'étude de la description qui suit d'un mode de réalisation préféré, donnée à titre d'illustration et non à titre limitatif et des dessins annexés o des références similaires indiquent des éléments similaires et dans lesquels: La Figure 1 illustre une topologie d'un système dans lequel divers agents peuvent être reliés dans un système de conférence. La Figure lb illustre un schéma fonctionnel de circuit contenu dans un agent qui participe dans un système de conférence. La Figure 2 illustre un schéma fonctionnel des diverses procédures de commande qui sont présentes dans un agent qui participe à une conférence. La Figure 3 illustre un schéma fonctionnel de classes utilisées dans un mode de réalisation de mise en oeuvre de la présente invention. La Figure 4 illustre les types d'annotations qui doivent être exécutés sur un affichage d'interface d'utilisateur d'un agent unique à l'intérieur de diverses mises en oeuvre du mode de réalisation préféré. La Figure 5 illustre la hiérarchie d'objets utilisée dans certains modes de réalisation de la présente invention. Les Figures 6a et 6b illustrent des schémas logiques d'un processus effectué lors de la détection d'un évènement qui exige, pendant une conférence électronique, une création ou une annulation ou une modification d'objets qui peuvent être exécutées à partir d'une boucle d'évènement du gestionnaire d'objet dans un mode de réalisation de la présente invention. Les Figures 7a à 7e illustrent des structures d'objet maintenues par un arbitre et un agent dans un système de conférence pendant diverses périodes o un agent est en train d'exécuter des actions dans son système local. La Figure 8 illustre un procédé utilisé pour le transfert différé de très grandes données objet binaires à l'intérieur de certains modes de réalisation de la présente invention. La Figure 9 illustre un schéma logique de processus de demande de données objet utilisé dans un mode de réalisation de la présente invention. La Figure 10 illustre la détermination d'un qualificateur de transport utilisé pour transférer de grandes données objet dans un mode de réalisation de la présente invention. La Figure 11 illustre un schéma logique de processus utilisé pour déterminer le besoin d'une demande partielle de grande donnée objet dans un mode de réalisation de la présente invention. Les Figures 12a à 12c illustrent diverses étapes d'achèvement du transfert de très grandes données objet dans un mode de réalisation de la présente invention. La Figure 13 illustre l'architecture de gestionnaire de transfert d'arrière plan. Les Figures 14 à 15 illustrent la logique de traitement qui concerne la Logique de connexion et de déconnexion de participant. La Figure 16 illustre une entrée en file d'attente de transfert. La Figure 17 illustre un exemple du processus de modification de priorité de demande de transfert. La Figure 18 illustre, pour une entrée de file d'attente de transfert, un exemple du traitement de disponibilité pour envoi. Les Figures 19 et 20 illustrent la logique de traitement de données selon la présente invention. On va maintenant décrire de façon détaillée un mode de réalisation préféré de la présente invention qui concerne des procédés et appareils de communication entre agents dans un système de conférence électronique. Bien que la présente invention soit décrite en référence à des noms, des signaux, des formats, des intervalles de temps spécifiques et à d'autres informations spécifiques, ceux-ci doivent être considérés comme utilisés dans des buts d'illustration seulement et ne pas être considérés comme limitant la présente invention. L'homme de l'art peut comprendre que de nombreuses modifications et variantes peuvent être réalisées sans s'écarter de l'esprit et du cadre d'ensemble de la présente invention. Comme illustré à la Figure la, un système de communication peut comprendre une série d'agents comme 11 à 14 qui sont tous couplés à un milieu de communication, par exemple 20, illustré à la Figure la. Dans certains modes de réalisation de la présente invention, chaque agent individuel couplé au milieu 20 possède des capacités équivalentes pour réaliser une communication entre les agents. Le système de conférence mis en oeuvre utilise une approche répartie dans laquelle chacun des agents 11 à 14 maintient un exemplaire local de la structure de conférence, appelée une "réunion", et ceux-ci sont tous cohérents entre eux. De plus, l'un des agents, 13, agit dans un mode de réalisation de la présente invention comme arbitre pour accorder des demandes d'addition d'objets à diverses structures à l'intérieur de chaque agent afin de maintenir une cohérence parmi les objets affichés sur chacun des systèmes des agents. Le système utilisé dans divers modes de réalisation de la présente invention utilise une architecture répartie, dans laquelle chaque agent 11 à 14 maintient des exemplaires locaux de tous les objets qui sont utilisés dans les conférences électroniques. Ainsi, des affichages, des textes, des graphiques et toutes autres informations affichées sur les affichages des systèmes d'ordinateurs des agents sont représentés dans une structure de données maintenue dans chacun des dispositifs locaux de mémoire et/ou de milieux de systèmes qui sont couplés à ces systèmes. Ainsi, le présent système comprend un hybride de l'architecture client/serveur dans lequel c'est chaque agent qui maintient un exemplaire local de la donnée, au lieu que des exemplaires centralisés de tous les objets du système de conférence électronique soient maintenus, de sorte que des modifications des données peuvent être plus ou moins immédiates. La structure d'un agent, qui peut être couplée au milieu de communication comme 20 illustré à la Figure la, est illustrée en référence à la Figure lb. En se référant à la Figure lb, un système sur lequel est mis en oeuvre un mode de réalisation d'un agent, par exemple 11 de la Figure la, de la présente invention est représenté par 100. Le système 100 comprend un bus ou d'autres moyens de communication 101 pour communiquer les informations, et un moyen de traitement 102 couplé au bus 101 pour traiter l'information. Le système 100 comprend en outre une mémoire vive, ou RAM, ou un autre dispositif de mémoire volatile 104, appelé une mémoire principale, couplé au bus 101 pour mémoriser des informations et des instructions à exécuter par le processeur 102. La mémoire principale 104 peut aussi être utilisée pour mémoriser des variables temporaires ou une autre information intermédiaire pendant l'exécution d'instructions par le processeur 102. Le système 100 comprend aussi une mémoire morte ou ROM et/ou un autre dispositif de mémoire statique 106 couplé au bus 101 pour mémoriser une information statique et des instructions destinées au processeur 102, et un dispositif de mémoire de données 107, par exemple un disque magnétique ou un disque optique et son unité de disque correspondante. Le dispositif de mémoire de données 107 est couplé au bus 101 pour mémoriser des informations et des instructions. Le système 100 peut en outre être couplé à un dispositif d'affichage 121, par exemple un tube à rayons cathodiques ou CRT, ou un affichage à cristaux liquides ou LCD couplé au bus 101 pour afficher une information à un utilisateur d'ordinateur. Un dispositif d'entrée alphanumérique 122, incluant des touches alphanumériques et autres, peut être lui aussi couplé au bus 101 pour communiquer des informations et des choix d'ordres au processeur 102. Un dispositif additionnel d'entrée d'utilisateur est une commande par curseur 123, par exemple une souris, une bille roulante, un stylet, ou des touches de direction du curseur, couplée au bus 101 pour communiquer une information de direction et des choix d'ordre au processeur 102, et pour commander le déplacement du curseur sur l'affichage 121. Un autre dispositif qui peut être couplé au bus 101 est un dispositif 124 d'impression de documents qui peut être utilisé pour imprimer des instructions, des données ou d'autres informations sur un milieu comme un papier, un film, ou des types similaires de milieux. Dans les modes de réalisation décrits, un autre dispositif qui est couplé au bus 101 est un dispositif de communication 125 qui est utilisé pour communiquer avec d'autres agents. Ce dispositif de communication peut inclure un nombre quelconque de dispositifs périphériques commercialisés de mise en réseau, par exemple ceux qui sont utilisés pour coupler à un milieu de communication Ethernet ou Token-Ring. On notera aussi que tous les composants du système 100 et tout l'équipement associé peuvent être utilisés dans divers modes de réalisation, mais on peut comprendre que toute configuration du système peut être utilisée pour des buts divers selon la mise en oeuvre particulière. Selon un mode de réalisation, le système 100 est un ordinateur personnel du type compatible IBM. Le processeur 102 peut être l'un des microprocesseurs compatibles 80x86, par exemple les microprocesseurs 80386, 80486 ou de marque PentiumTM fabriqué par Intel Corporation, Inc. de Santa Clara, Californie. On note que la description qui suit de divers modes de réalisation décrits ici se rérfere spécifiquement à une série de sous-programmes qui sont engendrés dans un langage de programmation de haut niveau orienté objet, par exemple, le Microsoft C/C++ commercialisé par Microsoft, Inc. Redmond, Washington. Cette série de sous-programmes est compilée, liée, et ensuite mise en oeuvre en tant que code objet dans le système 100 pendant le temps de mise en oeuvre. L'homme de l'art comprend, cependant, que les procédés et les appareils qui suivent peuvent être mis en oeuvre dans des dispositifs d'équipement spécialisés, par exemple des dispositifs logiques discrets, des circuits intégrés à grande échelle ou LSI, des circuits intégrés spécifiques à une application, ou ASIC, ou d'autres équipements spécialisés. La présente description s'applique également à des appareils qui exercent des fonctions similaires. On décrira en premier lieu l'organisation du logiciel d'un agent. A l'intérieur de chaque agent, une série de procédures de logiciel qui sont organisées de la manière illustrée en se référant à la Figure 2 est mise en oeuvre pendant un temps de conférence. La Figure 2 illustre en 200 un schéma général de l'organisation des processus à l'intérieur d'un agent unique selon un mode de réalisation de la présente invention. L'organisation de logiciel 200 à l'intérieur d'un agent unique comprend un processus 240 à points multiples qui est responsable d'une communication directe sur le milieu de communication 260 de façon à permettre de communiquer avec d'autres agents 250. Ceci réalise toutes les fonctions de communication de bas niveau qui permettent un accès direct au milieu de communication 260. Dans différents modes de réalisation de la présente invention, le milieu de communication peut être l'un quelconque des divers milieux normalisés utilisés pour la mise en réseau, y compris des réseaux locaux comme Ethernet, Token-Ring ou d'autres types de milieux normalisés de mise en réseau. Le milieu de communication 260 peut également être un réseau téléphonique ou une connexion par modem ou d'autres milieux de communication de données. Une fonction 240 à points multiples réalise donc toute la mise nécessaire en paquets ainsi que toutes les réponses à des communications reçues par l'intermédiaire du milieu de communication 260. Le niveau supérieur suivant dans l'organisation de logiciel 200 d'un agent unique est le gestionnaire de conférence 230 qui exerce toutes les fonctions d'exécution nécessaires pour la communication avec les fonctions de communication 240 de niveau bas et les fonctions du niveau supérieur exercées par le processus 210 d'interface humaine et le gestionnaire 220 d'objets. Le gestionnaire 230 de conférence commande le gestionnaire d'objets 220 par l'intermédiaire d'une série de rappels à des ordres existant dans le système de conférence qu'il est souhaitable d'exécuter. Le gestionnaire de conférence 230 exécute aussi tous les rappels dans le gestionnaire d'objet 220 en fonction des messages qui sont reçus du processus de communication 240 et dirige la création, l'annulation ou d'autres effets sur des objets du système. Comme décrit de façon plus détaillée ci-dessous, des objets situés à l'intérieur du système, par exemple des annotations, des pages, des ordres et d'autres objets utilisés à l'intérieur du système, sont traités en utilisant un système orienté objet dans lequel des hiérarchies d'objets sont définies. Ceci sera décrit de façon plus détaillée ci-dessous. Une communication allant du gestionnaire d'objet 220 au gestionnaire de conférence 230 est réalisée par l'intermédiaire de messages qui sont envoyés au gestionnaire 240 de liaisons à points multiples pour la création d'objets, l'arbitrage entre l'arbitre et l'agent et une communication avec d'autres agents de la conférence. En outre, le gestionnaire de conférence 230 dirige un processus 210 d'interface humaine par l'intermédiaire d'indicateurs afin d'afficher divers éléments sur l'affichage. Des résultats venant de l'affichage de fonctions d'interfaces humaines sont renvoyés au gestionnaire de conférence 230 par l'intermédiaire de messages. Le gestionnaire d'objet 220 est un processus qui agit pendant le temps de fonctionnement afin de garder un suivi des divers objets utilisés pendant une conférence entre l'agent et d'autres agents du système. Le gestionnaire d'objet coordonne la réunion entre les agents. Le gestionnaire d'objet garde un suivi de tous les objets créés pendant la réunion y compris d'autres agents, les divers éléments affichés pendant la conférence et d'autres objets. De plus, le gestionnaire d'objet est utilisé pour maintenir l'état de la réunion et pour garder tous les agents synchronisés avec l'agent actuel. Le contenu d'une réunion peut être sauvegardé et être restitué à partir de la mémoire de masse, par exemple, 107 à la Figure lb, lors d'une sortie de conférence ou lors d'une entrée en conférence. Le gestionnaire d'objet échange aussi le contenu de la réunion avec d'autres gestionnaires d'objet, situés dans d'autres agents, afin de garder synchronisés des exemplaires de la réunion. Chaque gestionnaire d'objet 220 maintient son propre exemplaire local de la réunion qui est fourni à l'interface humaine 210 selon les besoins. Le gestionnaire d'objet 220 informe l'interface humaine 210 au sujet de modifications venant d'autres agents qui participent à la réunion. La couche 210 d'interface humaine peut ensuite ajuster l'affichage selon les directives. L'interface humaine 210 informe aussi le gestionnaire d'objet au sujet de modifications que l'utilisateur souhaite apporter à la réunion actuelle. Le gestionnaire d'objet 220 synchronise ensuite les variations avec tousles autres gestionnaires d'objet qui participent à la réunion. Le gestionnaire d'objet commande l'interface humaine en envoyant des messages, de même que l'interface humaine dirige le gestionnaire d'objet afin d'effectuer certaines actions sur des objets, en fonction de l'ajustement de l'affichage sous commande de l'interface humaine 210. On va maintenant donner, en référence à la Figure 3, une brève vue générale de la structure d'objets, et plus particulièrement une structure de classification des objets, dans un mode de réalisation de la présente invention. La Figure 3 illustre une classification générale des objets de haut niveau qui sont utilisés dans un mode de réalisation de la présente invention. Dans ce mode de réalisation, la classe 300 de gestionnaire d'objets comprend la classification la plus large d'objets à l'intérieur du système. De façon générale, deux zones générales, les réunions publiques 310 et les réunions privées 320 sont à l'intérieur de la classe de gestionnaire d'objets. Une information que l'utilisateur a entré dans son espace privé est mainteneur par le gestionnaire d'objets dans la classe 320 d'objets de réunions privées qui est distincte de la classe 310 d'objets de réunions publiques. Chaque information est maintenue sous forme de structure séparée d'objet à l'intérieur de la classe de réunions. Par conséquent, pendant une réunion publique mémorisée dans la classe 310 de réunions publiques, un utilisateur peut mémoriser de façon semblable une information privée 320 qui doit aussi être associée à cette même réunion. De plus, le gestionnaire 220 d'objet maintient une information concernant l'utilisateur dans la classification 330 et une information concernant l'arbitre dans la classification 340, étant entendu qu'il n'existe qu'un seul arbitre pendant une conférence électronique quelconque, et les autres participants de la réunion sont dans une classification 350 de participants. Tous ceux-ci sont également membres de la classe de gestionnaire d'objets. Le gestionnaire 300 d'objet maintient un suivi des participants de la réunion de manière que, lorsque de nouveaux participants rejoignent la réunion, les exemplaires de ces nouveaux participants soient amenés en synchronisation avec ceux de tous les autres participants. Au fur et à mesure que des participants quittent la réunion, toutes les contributions des utilisateurs sont assurées d'être partagées avant que le participant ne quitte la réunion. L'un des agents ou participants de la réunion est appelé l'arbitre. Celui-ci est représenté dans la classe 340 d'arbitre. L'arbitre résout des conflits entre les utilisateurs lorsqu'il se pose une question de commande des propriétés de la réunion. L'arbitre détermine le participant qui commande une annotation, le nombre de pages qui existent dans la réunion actuelle, etc. Il garde également un exemplaire maître de la réunion avec lequel tous les participants se synchronisent. Des gestionnaires d'objets à l'intérieur de chaque agent participant coordonnent celui qui est arbitre et assignent un nouvel arbitre lorsque l'arbitre assigné quitte la réunion ou selon ce que dictent d'autres évènements de conférence: par exemple, lors d'une ouverture ou d'une fusion d'un fichier de réunion dans lequel le participant qui ouvre ou fusionne le fichier de réunion devient l'arbitre avant l'ouverture ou la fusion du fichier. Selon une mise en oeuvre de la présente invention, c'est au premier utilisateur qui commence une réunion qu'est assigné le rôle d'arbitre. Une approximation très grossière des types d'objets qui peuvent être présents sur un affichage de participant est illustrée à la Figure 4. Généralement, un utilisateur dispose, sur son affichage, d'une zone de réunion 400 dans laquelle diverses informations peuvent être entrées. Typiquement, chaque réunion comprend une série de pages qui est analogue à un tableau blanc unique ou à un espace d'affichage partagé auquel des utilisateurs pourraient accéder dans un local. De façon analogue, un mode de réalisation de la présente invention utilise la métaphore du carnet qui est, en fait, un "carnet" partagé entre plusieurs participants de la réunion, dans lequel chacun des participants peut entrer des informations. La zone partagée ou carnet comprend plusieurs pages 410 sur lesquelles des annotations peuvent être portées. Des utilisateurs peuvent créer ou annuler à volonté des pages, sous certaines conditions. Des annotations portées sur les pages peuvent être d'au moins quatre types, selon un mode de réalisation de la présente invention. Les trois premiers de ces types sont illustrés à la Figure 4. Par exemple, une page 410 peut comprendre une annotation 411 de dessin, qui est typiquement un dessin orienté objet créé par un utilisateur unique. De telles illustrations de dessins orientés objet, comme 411, comprennent une description de positions de points et de segments entre ceux-ci et sont bien connus de l'homme de l'art antérieur. Des annotations peuvent également comprendre des annotations graphiques 412 qui sont généralement des représentations d'une donnée d'image graphique par implantations de bits. Des annotations textuelles 413 peuvent être placées sur une page. Des annotations textuelles peuvent être d'un type quelconque au choix de l'utilisateur et comprendre certaines mises en oeuvre de l'art antérieur, qui peuvent permettre aux utilisateurs de choisir un style, une dimension de points, et une police et une autre information de formatage, d'une manière typique de l'art antérieur. Une autre annotation qui peut être utilisée selon un mode de réalisation de la présente invention est l'annotation qui utilise le protocole Object Linking and Embedding ou OLE, c'est-à-dire littéralement Liaison et incorporation d'objet, commercialisé par Microsoft Corporation de Redmond, Washington. Des annotations OLE peuvent référencer d'autres "objets", qui sont créés et/ou maintenus par d'autres programmes d'application et qui peuvent être, soit liés, soit incorporés en utilisant le protocole OLE. Chacune de ces annotations est mémorisée en tant qu'objet sous une classification "d'annotation", qui est associée à des objets de la classification de type page. La Figure 5 illustre la classification pour des objets utilisés selon un mode de réalisation de la présente invention. La structure d'ensemble des classes d'objets est illustrée en référence à la Figure 5. La Figure 5 inclut l'objet de la réunion, l'utilisateur, l'arbitre, les participants et les objets d'annotation qui ont été décrits et illustrés en référence aux Figures 3 et 4 ci- dessus. A la Figure 5, des relations sont illustrées en se référant à la représentation en traits simples et en traits doubles dans laquelle des relations d'héritage sont représentées par les flèches, la direction de l'héritage suivant l'orientation de la flèche. De plus, chacune des relations illustrées aux Figures indique des relations multiples. En effet, si unerelation est n:1, ceci signifie qu'il peut y avoir n objets de la sous-classe sous l'objet parent. Par exemple, comme illustré et décrit en référence à la Figure 3 et comme représenté maintenant à la Figure 5, le CObjetManager 501, ou littéralement gestionnaire 501 d'objet C inclut deux classes d'objets CCMeeting, ou littéralement réunion CC: la réunion "publique" et la réunion "privée" selon la représentation de la Figure 3. De plus, la classe d'objet CCMeeting 506 comprend des objets 509 de participant, ou CCParticipant qui y sont associés, ceux qui sont représentés en 350 à la Figure 3. De plus, la classification 506 d'objet CCMeeting référence l'objet 508 CCPage. La classification CCPage est utilisée pour définir toutes les pages qui peuvent relever d'une réunion spécifique. Sous la classification CCPage 508, on trouve les classifications d'annotation, sous la classe CCAnnotation 532, qui sont représentées avec leurs diverses relations d'héritage dans la partie inférieure du schéma. Ainsi, la classification CCAnnotation 532 peut comprendre des objets qui héritent de toutes les relations de l'objet d'annotation, pour des annotations de texte contenues à l'intérieur de la classe CCTextAnnotation 521, la classe CCGraphicAnnotation 522 pour représenter des graphiques ou des annotations d'implantation de bits comme 412 à la Figure 4 et la classe CCDrawAnnotation 523 pour référencer des annotations de dessin comme 411 à la Figure 4. Une autre annotation qui peut être utilisée dans un mode de réalisation de la présente invention, est la classe 520 CCOLEAnnotation qui fait partie de la classification 503 COLEDocument pour effectuer une liaison et une incorporation d'objet en utilisant le protocole Object Linking and Embedding, ou OLE, commercialisé par Microsoft Corporation de Redmond, Washington. Des annotations peuvent donc être des références à des "objets" créés et/ou maintenus par d'autres programmes d'application et qui peuvent être soit liés soit incorporés en utilisant OLE. D'autres classifications sont disponibles à partir de la classification CCObjectManager 501, comme par exemple la classification 512 CCPerson qui est associée à une classification 510 CCPassword pour associer des mots de passe, ou passwords, d'utilisateurs à des objets de personnes. De plus, une classe CCadress 513 et une classe CCPhone 514 sont associées à chaque personne pour définir les adresses et/ou les numéros de téléphone d'accès au réseau des participants. Finalement, l'ensemble restant de classes d'objet représentées à la Figure 5 inclut la classification d'objet 515 CCCachableBlob et la classe 516 CCBlob qui possède une relation et qui hérite des caractéristiques de la classification d'objet d'annotation et des classifications d'objets 532 et 515 CCCachableBlob. La classe CCBlob 516 est utilisée pour présenter de très grands objets dans divers modes de réalisation de la présente invention. Divers modes de réalisation de la présente invention permettent de très grands objets binaires, appelés dans ce mode de réalisation Binary Large Objects ou BLOB, c'est-à-dire grands objets binaires, qui peuvent être d'un type quelconque de données. Ces très grands objets binaires peuvent eux aussi être partagés et répartis parmi les utilisateurs. En outre, divers modes de réalisation de la présente invention permettent à ces objets de n'être transférés que sur la demande d'utilisateurs spécifiques et/ou lorsque le trafic du milieu le permet. De cette manière, le milieu de communication n'est pas surchargé par la tâche de transmettre ces très grands objets binaires, sauf en cas d'exigence absolue. De très grands objets binaires ou BLOB peuvent être utilisés pour représenter un type quelconque d'information mais, dans certains modes de réalisation, ils ne peuvent être utilisés que pour représenter des grandes données à implantation de bits ou d'autres données d'image graphique, par exemple des informations comprimées de type animation ou audio, comme celles qui sont représentées dans le format MEPG, ou Motion Picture Experts Group, c'est-à-dire littéralement groupe d'experts des représentations en mouvement, ou bien JPEG, ou Joint Photographers Experts Group, c'est-à-dire littéralement groupe des experts photographes réunis. On prévoit que d'autres données binaires peuvent être transmises dans des variantes de mode de réalisation en utilisant ces techniques, y compris des données de programmes exécutables. On va maintenant décrire une vue d'ensemble du fonctionnement de synchronisation différée Comme décrit déjà, chacun des participants d'une conférence maintient ses propres données en ce qui concerne l'état actuel d'affichage du carnet partagé pour tous les utilisateurs de la conférence. De cette manière, aucun participant individuel ne dépend d'un accès à un serveur central pour l'affichage de sa propre information. Cependant, un participant spécial de la conférence est appelé "l'arbitre" et l'arbitre maintient une "version officielle" d'une réunion. Tous les autres participants doivent maintenir leurs versions synchronisées avec l'exemplaire officiel de l'arbitre. Un deuxième participant peut devenir l'arbitre, soit sur sa propre demande, soit lorsque l'arbitre désire cesser de participer à la conférence. Dans ce cas, tous les autres participants sont informés eux aussi de la modification et un nouvel arbitre peut commencer à fonctionner. Selon un mode de réalisation de la présente invention, l'arbitre d'une conférence est le participant d'origine qui a commencé la réunion. L'arbitre agit aussi comme système central sur lequel sont approuvées des annotations portées sur l'exemplaire officiel de la structure de réunion. Bien que des utilisateurs puissent apporter des modifications en temps réel à leurs propres exemplaires locaux de la structure de réunion, sans autorité de l'arbitre, l'arbitre doit prendre une décision finale concernant la position de certaines annotations afin que la réunion soit maintenue cohérente parmi tous les participants. Dans le reste de la présente demande, on appelle synchronisation différée l'ensemble constitué par le fait de permettre à un participant unique de modifier sa structure de réunion, sans l'autorité de l'arbitre, et par la synchronisation ultérieure de cette structure de conférence avec tous les autres participants de la conférence. A chaque objet de classe de page et d'annotation de la structure de réunion est associée une variable qui indique si la page ou l'annotation a été synchronisée avec d'autres participants de la conférence. Ceci est appelé le drapeau "bloqué" et ce drapeau est placé à vrai jusqu'à ce que l'objet de page ou d'annotation ait été synchronisé avec les autres participants. De plus, l'arbitre maintient des indices d'objet et en attribue à de nouveaux objets au fur et à mesure qu'ils sont créés et/ou modifiés par un agent particulier, en maintenant ainsi toute la réunion synchronisée entre tous les participants. L'agent qui demande ensuite l'addition et/ou la modification d'objets reçoit de l'arbitre des messages qui indiquent un nouvel indice d'objet, de sorte que le participant peut mettre à jour sa structure locale de réunion afin d'être compatible avec les autres participants de la réunion. De plus, le drapeau bloqué peut être modifié à faux pour indiquer que les objets en question sont maintenant synchronisés et qu'aucune poursuite de communication n'est nécessaire avec l'arbitre actuellement. Par exemple, un participant peut décider d'ajouter une annotation à une page existante. Le processus 210 d'interface humaine détecte cette demande et envoie un message au gestionnaire d'objet 220 afin d'ajouter l'annotation. Puis, une demande est envoyée par le gestionnaire d'objets 220 du participant demandeur au gestionnaire d'objet de l'arbitre. De plus, le gestionnaire d'objet ajoute un objet à sa structure locale de réunion, le drapeau indiquant que l'annotation est "bloquée" pour indiquer que l'objet n'a pas été synchronisé avec d'autres participants à la réunion. De plus, dans la communication vers un arbitre, le participant a indiqué son indice de participant et une demande concernant un indice d'objet à attribuer par l'arbitre. Puis, l'utilisateur de l'agent peut continuer à agir sur l'annotation, jusqu'à ce que l'indice d'objet soit reçu en retour de l'arbitre. Dès lors que l'indice d'objet a été reçu, le participant peut mettre à jour sa structure de conférence pour s'adapter à l'indice reçu en retour de l'arbitre. On va maintenant décrire de façon détaillée le processus concernant une synchronisation différée en se référant aux Figures 6a à 7e. Les Figures 6a et 6b illustrent des étapes détaillées d'un procédé 600 qui peut être exécuté lors de la détection d'une demande d'exécution d'un ordre exigeant une synchronisation avec d'autres participants dans une réunion à l'intérieur de la boucle d'évènements du gestionnaire de conférence. Ainsi, il est possible d'entrer dans le procédé 600 lors de la détection d'une création d'un nouvel objet, de la modification d'un objet existant ou de l'annulation d'un objet, détectée par l'interface humaine 210 de la Figure 2. Le procédé 600 peut commencer à un point d'entrée typique de procédé, par exemple 601 illustré à la Figure 6a. Il est ensuite déterminé à l'étape 602 si l'ordre est un ordre qui exige un arbitrage différé. Dans le cas contraire, l'opération actuelle peut être exécutée à l'étape 613 avec une communication normale, et avec la latence éventuelle associée, entre l'agent actuel et tout autre participant à la conférence. Puis, à l'étape 620, il est possible de sortir du procédé à un point typique de sortie de procédé. En revanche, le procédé continue à l'étape 603 s'il s'agit d'un ordre qui exige un arbitrage différé, c'est-à-dire que les exigences de synchronisation concernant la. synchronisation de conférence sont relâchées et que l'utilisateur peut apporter toute modification à la structure locale de réunion sans la latence provoquée par la synchronisation avec d'autres agents. A l'étape 603, il est déterminé si le but de l'ordre actuel est de modifier un objet qui est déjà "bloqué". Un objet n'est indiqué comme bloqué que s'il a été déterminé que l'objet a été modifié, annulé ou ajouté précédemment et que l'objet n'a pas encore été synchronisé avec d'autres participants de la conférence. Comme décrit précédemment, ce drapeau n'est placé que lors de la détection d'une modification, mais avant l'assignation d'un indice d'objet par l'arbitre. S'il n'est pas bloqué, s'il s'agit d'une action initiale sur l'objet par exemple, il est ensuite déterminé à l'étape 604 si la demande a été détectée en vue d'une annulation de l'objet. Une annulation exige une série spécifique d'étapes, puisque la propriété de tous les objets qu'il faut détruire doit être acquise avant toute annulation. Ce processus exige aussi une communication avec d'autres participants de la conférence comme représenté à la Figure 6b. En premier lieu, à l'étape 614, il est déterminé si la propriété de l'objet a été obtenue. Ceci inclut la propriété de tous les objets et sous- objets. Dans le cas contraire, cette propriété est demandée à l'étape 615 à chacun des propriétaires des objets. Si la propriété est attribuée, comme détecté à l'étape 616, ou si la propriété de l'objet a déjà été obtenue selon la détection en 614, le procédé peut continuer en revenant à l'étape 605 illustrée à la Figure 6a. Dans le cas contraire, l'annulation a été manquée, comme indiqué à l'étape 617, et le procédé revient à un point typique de sortie de procédé comme celui qui est représenté en 620 à la Figure 6a. A l'étape 605, il a maintenant été déterminé que l'objet est un objet qui n'était pas précédemment bloqué, c'est-à-dire qu'il a été synchronisé précédemment, et qu'il se produit maintenant un certain type de modification de l'objet. Ainsi, lorsque ceci se produit, une demande doit être envoyée pour demander pour l'objet un indice d'objet afin que le participant soit synchronisé avec tous les autres participants. Cependant, l'utilisateur peut continuer à effectuer des modifications et effectuer d'autres opérations, même avant la réception de l'indice de l'objet qui vient de l'arbitre. Des modifications ne seront donc que locales jusqu'à la synchronisation ultérieure de la structure de conférence du participant demandeur avec d'autres participants de la réunion. Les modifications demandées par l'utilisateur ne sont effectuées localement qu'à l'étape 606, en apportant toutes les modifications qui sont admissibles à la structure de réunion, et les modifications sont indiquées comme bloquées à l'étape 607. Puis, il est possible de sortir de ce sous-procédé à l'intérieur de la boucle d'événement à l'étape 620, un point typique de sortie de procédé. Le procédé 600 continue par les étapes initiales 601, 602 et 603 pour des objets bloqués pour lesquels des ordres ont été reçus. Si l'objet est détecté comme "bloqué" c'est-à-dire si une demande concernant un indice d'objet a été envoyée à l'arbitre, et que cependant aucune réponse n'a encore été reçue, le procédé 600 continue à l'étape 609. L'étape 609 détecte si la réponse contenant l'indice d'objet a été reçue de l'arbitre. Dans le cas contraire, le procédé passe aux étapes 606, 607 et 620, comme décrit précédemment. En d'autres termes, des modifications continuent à être effectuées localement et toutes modifications sont indiquées comme bloquées jusqu'à ce que se soit produite la synchronisation avec l'arbitre et, donc avec les autres participants. En revanche, si une réponse a été reçue de l'arbitre, l'indice d'objet est reçu à l'étape 610. Puis, le participant peut mettre à jour sa structure locale de réunion à l'étape 611 afin de rendre le participant synchrone avec l'arbitre, et donc avec les autres participants de la réunion. De plus, la couche d'interface humaine HI 210 est informée de cet évènement afin que le participant mette à jour son affichage. Par exemple, une page que le participant local avait désignée comme page 4 avait déjà été ajoutée par le participant, mais qu'elle devient la page 5 par suite de l'assignation donnée par l'arbitre, la couche d'interface humaine 210 détecte cette modification et met à jour l'affichage de façon correspondante afin de déplacer visuellement la page à la page 5. Par exemple, dans la métaphore du carnet représenté sur l'affichage, une nouvelle tabulation ou "tab" de page peut être créée pour la page en utilisant des ordres d'interface d'utilisateur bien connus dans l'art antérieur afin d'associer à la page créée localement une nouvelle tabulation de page intitulée "Page 5". Puis, quand sa propre structure et son propre affichage locaux de réunion ont été modifiés à l'étape 611, le participant diffuse l'une quelconque des variations bloquées, c'est-à-dire des pages ou des annotations modifiées, aux participants à la conférence à l'étape 612 comme demandé par les participants. Par conséquent, aucun des autres participants n'est synchrone avec le participant actuel jusqu'à cet instant. Dès lors que ceci est accompli, les autres participants de la conférence peuvent aussi mettre à jour leurs propres structures locales de réunion et les affichages associés à l'aide des pages et annotations appropriés afin d'être synchrones avec le participant qui exécute les modifications. Finalement, l'opération en cours peut ensuite être exécutée avec une communication normale à l'étape 613, en rendant ainsi synchrones tous les participants de la conférence. Puis, l'étape 620 représente une étape de sortie du procédé à un point typique de sortie de procédé. On donnera une illustration simple des structures de réunion d'un participant local et d'un arbitre en référence aux Figures 7a à 7e, qui représentent l'addition d'un objet pendant certaines étapes dans le procédé 600 illustré aux Figures 6a à 6b. Par exemple, à un instant tl, comme illustré à la Figure 7a, un agent ou participant unique peut posséder dans sa structure de conférence trois articles 701 à 703, liés de façon hiérarchique, par exemple une liste d'annotations ou une liste de pages. De même, un agent arbitre peut aussi posséder dans sa structure de réunion trois objets semblables, 711 à 713, tous les objets n'étant pas bloqués chez aucun des agents. A un deuxième instant t2, illustré à la Figure 7b, le participant peut créer un objet additionnel, par exemple 704, par exemple une page ou une annotation à ajouter à sa structure locale de réunion. Simultanément, l'arbitre peut recevoir d'un deuxième participant une demande d'ajouter un objet à sa structure de réunion O'4 714 en raison d'une demande d'addition d'un ordre. Ultérieurement, à un instant t3, l'arbitre et l'agent possèdent chacun, dans sa structure locale de réunion, un objet différent portant le même indice d'objet 4. Par exemple, l'agent peut posséder l'objet 704 comme quatrième objet dans sa structure de réunion d'objets, et l'arbitre peut posséder l'objet 714 comme quatrième objet dans sa structure de réunion. Puis, à un instant ultérieur t4, l'agent envoie à l'arbitre une demande d'addition d'un objet additionnel à la structure "officielle" d'objets maintenue par l'arbitre. Ceci est illustré en 715 à la Figure 7d. Puisque toutes les demandes sont prises en série par l'arbitre à partir de chacun des participants à la conférence, la demande du premier agent d'ajouter l'objet 715 est arrivée plus tard que la demande concernant l'objet 714. Il lui est donc assigné un indice d'objet 5. L'arbitre transmet ensuite en retour à l'agent demandeur l'indice 5 à associer à l'objet. L'arbitre transmet ensuite en retour une réponse indiquant que l'indice d'objet 5 devrait être assigné à l'objet 704 en remplacement du précédent. Un autre participant transmet ensuite en retour un nouvel objet à insérer dans la liste d'objets du participant local 0'4 705. Ainsi, à un instant ultérieur t5 illustré à la Figure 7e, les structures de réunion tant de l'arbitre que de l'agent d'origine peuvent être totalement synchronisées entre elles et avec celles d'autres participants à la conférence. En d'autres termes, tous les objets de la structure de réunion de l'agent et de la structure de réunion de l'arbitre sont les mêmes et sont dans le même ordre. Par conséquent, une synchronisation différée d'objets pour des participants dans une conférence électronique offre des avantages sensibles par rapport au modèle client/serveur de l'art antérieur parce que les exigences de synchronisation entre le client et le serveur sont plus relâchées. Puisqu'une cohérence complète entre participants est différée, les participants locaux peuvent exécuter des opérations intensives en unité centrale de traitement, par exemple la modification et la création d'annotations en temps réel, sans la latence de coordination de telles opérations avec le serveur. Un autre avantage que la synchronisation différée d'objets offre par rapport au modèle client/serveur de l'art antérieur, est que la synchronisation d'objets pour tous les participants est réalisée sans utiliser de répertoire central de données, de la manière classique dans le modèle client/serveur. Ceci offre un avantage sensible parce que le système de conférence par ordinateur peut être utilisé entre des ordinateurs personnels là o un modèle client/serveur en réseau n'est pas disponible ou pratique. Le participant local effectue toutes ces modifications dans la structure locale d'affichage et de réunion, et les mises à jour ne sont coordonnées qu'à la réception d'une réponse venant de l'arbitre, qui assigne un indice d'objet. Par conséquent, la présente invention offre des avantages sensibles par rapport aux systèmes de l'art antérieur qui exigent une synchronisation totale à tout instant entre tous les participants à la conférence, ce qui provoque une latence sensible pour la synchronisation et des délais de réponse dans l'interface de l'utilisateur avec le système. On va maintenant décrire de façon détaillée le transfert de grandes données d'objet selon l'invention. L'un des types de données d'objet qui peuvent être transférés entre participants dans une conférence électronique est appelé un très grand objet binaire, ou "BLOB" selon les initiales du terme anglo-saxon BinaryLarge OBject. Un BLOB est un objet qui ne pourrait normalement pas être transmis pendant un cycle d'attente complet du participant et du milieu de transport. Ainsi, ces objets doivent être répartis en plus petites parties, ou paquets et être transmis pendant plusieurs cycles inactifs par une tâche d'arrière plan. Des BLOB comprennent typiquement des éléments comme de très grandes données graphiques, des annotations OLE ou des fichiers à transférer. Dans d'autres modes de réalisation de la présente invention, ces BLOB peuvent inclure des objets vidéo à plein mouvement, par exemple le fichier MPEG ou JPEG et/ou d'autres données audio. En utilisant les procédés et l'appareil décrits, la donnée de BLOB est transmise en paquets, la dimension de chacun des paquets étant basée dynamiquement sur les capacités du milieu de transport qui peuvent varier dynamiquement au fur et à mesure que les liaisons entre participants varient. Par conséquent, si la vitesse du milieu de transport de liaison entre deux participants varie, la dimension des paquets transmis par l'émetteur est modifiée. Ceci est effectué dynamiquement pendant le temps de transmission afin de permettre l'utilisation la plus efficace du milieu de transport pendant la transmission de BLOB. De plus, des demandes de transmission de BLOB sont mises en file d'attente de façon que des BLOB à priorité supérieure puissent être transmis avant des BLOB à moindre priorité. De cette manière, quand un participant qui voit une première page contenant des données de BLOB passe à une deuxième page qui contient aussi des données de BLOB, la deuxième page, qui devient la page d'observation actuelle contenant le ou les BLOB, reçoit une nouvelle priorité à l'intérieur du transmetteur pour être transmise avant le BLOB de la première page. Ceci est effectué en utilisant une demande de modification de priorité venant du demandeur. Puis, l'agencement de la file d'attente de transfert de sortie est modifié par l'émetteur afin d'effectuer la modification souhaitée de priorité de transfert. On va maintenant décrire les détails de ces mécanismes. En premier lieu, pendant une conférence électronique typique, il n'est pas nécessaire que les BLOB de données soient transmis à d'autres participants dès la création d'un BLOB à l'intérieur d'un participant local. En d'autres termes, une transmission de données d'un BLOB peut être différée jusqu'à un temps ultérieur pendant lequel le milieu de transport peut être inactif, ou pendant lequel le participant local peut disposer d'un certain temps de traitement inactif. Par conséquent, pendant la création d'un BLOB, des participants éloignés peuvent être notifiés de ce que la donnée de BLOB n'est pas contenue à l'intérieur du BLOB à créer, et le participant ou les participants éloignés créent simplement dans leur structure locale de réunion l'objet destiné à toute donnée absente de BLOB. Au cours de périodes inactives ultérieures, du participant local et/ou des participants éloignés, la donnée de BLOB elle-même, qui doit être contenue à l'intérieur de l'objet de BLOB dans la structure de réunion du participant éloigné, peut être ajoutée à un temps adapté pour les deux participants. Une chronologie typique d'actions qui peuvent être exécutées pendant une création et une transmission de BLOB est illustrée en se référant à la Figure 8. Les étapes illustrées en référence à la Figure 8 illustrent les séquences d'étapes parcourues par un participant local et un ou des participants éloignés engagés dans une conférence. Par exemple, à une première étape comme l'étape 801 de la Figure 8, un participant local peut ajouter à sa structure locale de conférence un objet contenant un BLOB. Le gestionnaire d'objet 230 contenu à l'intérieur du participant local notifie alors, à l'étape 802, à tous les participants éloignés qu'ils doivent aussi créer à l'intérieur de leur structure locale de réunion un objet pour un BLOB. Ceci est évidemment effectué après toute la synchronisation nécessaire, décrite en référence au processus de synchronisation différée ci-dessus, y compris la détermination de l'indice d'objet et d'autres informations appropriées pour un objet. Ainsi, chacun des participants éloignés soumet individuellement au participant local, à l'étape 803, des demandes asynchrones concernant les données BLOB. A l'étape 805, le participant local traite ensuite la demande de données BLOB, par exemple en plaçant la demande dans une file d'attente de demandes de BLOB et en fournissant ensuite les données pendant des temps inactifs. De plus, après les demandes asynchrones concernant les données BLOB, effectuées par les divers participants à l'étape 803, les participants éloignés peuvent ensuite soumettre, à l'étape 804, des demandes de modification de priorité pour des demandes antérieures concernant des données BLOB. En d'autres termes, si un participant a demandé en premier lieu un BLOB 1 et a ensuite demandé le BLOB 2, les deux demandes peuvent faire l'objet d'une modification de priorité afin que la priorité du BLOB 2 soit supérieure à celle du BLOB 1 pour le participant éloigné. Ainsi, si le participant éloigné passe d'une première page contenant le BLOB 1 à une deuxième page contenant le BLOB 2, le participant local réordonne les demandes de BLOB pour ce participant particulier. Comme décrit déjà, le participant local traite des demandes de données BLOB à l'étape 805. Ceci sera décrit de façon plus détaillée en se référant à la Figure 9 ci-dessous. A l'étape 806, le participant local enverra ensuite à chacun des participants éloignés les paquets de données BLOB demandés. Comme décrit de façon plus détaillée ci-dessous, des paquets de données BLOB sont envoyés en fonction du milieu de transport entre les deux participants. Par conséquent, si le participant éloigné est relié à un milieu de transport à haute vitesse à haute capacité, par exemple un Ethernet, la dimension des paquets de données est sensiblement plus grande que si le participant est relié par l'intermédiaire d'un modem ou d'une ligne téléphonique. Au fur et à mesure que le participant local envoie, à l'étape 806, des paquets de données BLOB, chacun des participants éloignés reçoit les données BLOB et ajoute les paquets de données BLOB à la structure existante de données BLOB. Puis, à l'étape 807, après l'achèvement de la transmission de tous les paquets de données BLOB pour les BLOB demandés, le participant local enlève le BLOB de la file d'attente de demande lors de l'achèvement du transfert de données. Le processus d'interface humaine du participant éloigné est notifié pour mettre à jour l'affichage de l'objet contenant les BLOB qui était précédemment incomplet. Des illustrations plus détaillées de certaines étapes du procédé vont maintenant être décrites. Le procédé 900 à la Figure 9 illustre une série d'étapes qui sont prises par un participant local lorsqu'il reçoit une demande de données BLOB, la demande étant transmise par des participants éloignés. Par exemple, à l'étape 901, on entre dans le procédé à un point d'entrée tel qu'une boucle d'événement d'un procédé principal. En d'autres termes, des demandes nouvelles et multiples de modification de priorité, venant de participants multiples, peuvent être reçues de façon asynchrone. Puis, à l'étape 902, le qualificateur de transport de la demande nouvelle ou d'une demande de modification de priorité est déterminé. En d'autres termes, il est déterminé si le milieu de transport pour le participant éloigné est un milieu de transport à haute vitesse ou à faible vitesse. La détermination des capacités du milieu, c'est-à-dire une haute ou une basse vitesse, est utilisée comme qualification lorsque l'on considère la combinaison de demandes venant des participants multiples. Comme décrit de façon plus détaillée ci-dessous, pendant le transfert d'un BLOB, une dimension, ou SIZE, et un déport ou OFFSET est maintenu, pour chaque BLOB de la file d'attente de transfert, pour chaque entrée ou donnée BLOB en file d'attente de transfert afin que la dernière donnée du BLOB qui a été transférée puisse être référencée. Des demandes multiples peuvent être combinées en une entrée unique en file d'attente et, de même, des demandes multiples de modifications de priorité provoquent simplement une modification de priorité des entrées en file d'attente. Par conséquent, lors d'une demande initiale d'une donnée BLOB, le déport, c'est-à-dire le début du BLOB, est de zéro et la dimension est rendue égale à la longueur totale du BLOB. Dans tous les cas, des étapes plus détaillées de détermination du qualificateur de transport seront illustrées en référence au procédé 1000 à la Figure 10. Un exemple du processus de modification de priorité est décrit en liaison avec la Figure 17. Dès lors que le qualificateur de transport a été déterminé, il est déterminé à l'étape 903 si une demande existante en cours concernant des données indique une réception d'une demande de modification de priorité, d'une demande d'origine pour des données BLOB. S'il s'agit d'une demande pour des données en cours, il est déterminé à l'étape 904 si une demande partielle est demandée. En d'autres termes, si d'autres participants éloignés demandent la même donnée de BLOB que celle qui a déjà été demandée et dont le transfert a déjà commencé, les nouveaux participants demandeurs peuvent recevoir la donnée de BLOB à partir du point intermédiaire auquel la demande a été faite, mais ils vont également demander toute donnée qui a déjà été transférée jusqu'à ce point. Ainsi, des transferts redondants de données sont éliminés en combinant des demandes presque simultanées venant de multiples participants éloignés. Dans des cas o un transfert associé à une demande d'origine n'a pas encore commencé, les participants demandeurs ultérieurs sont simplement ajoutés à la liste de répartition de l'entrée d'origine en file d'attente de transfert. Dans le cas contraire, si le transfert est déjà commencé, une entrée additionnelle en file d'attente, est ajoutée, en plus de la précédente, pour tenir compte des données déjà transférées. En revanche, s'il n'existe aucune demande en cours pour la donnée BLOB actuelle, une nouvelle entrée en file d'attente de transfert est entrée dans la file d'attente de transfert des participants à l'étape 905, afin de garder le suivi du transfert de BLOB. Comme décrit précédemment, l'entrée en file d'attente maintient un déport et une dimension pour le suivi du transfert de demandes individuelles. Dans tous les cas, lors de l'achèvement de l'une des étapes 904 ou 905, le traitement de demandes de données est achevé à l'étape 906, à la suite de quoi un transfert réel de données BLOB se produit dans l'arrière plan, c'est-à-dire pendant un temps de traitement inactif, et le procédé 900 revient à la boucle normale d'événement du sous-programme d'exécution du participant local. Une illustration plus détaillée des étapes de procédé suivi à l'étape 902 à la Figure 9 est illustrée en référence à la Figure 10. Le procédé 1000 est utilisé pour déterminer le qualificateur de transport. Le qualificateur de transport est utilisé pour traiter la combinaison de demandes multiples. En d'autres termes, des demandes venant de récepteurs reliés par l'intermédiaire d'un milieu à haute vitesse ne sont pas combinées avec des demandes venant de récepteurs reliés par des milieux à basse vitesse, et vice versa. Ceci est effectué dynamiquement, à chaque demande de transfert d'un paquet BLOB pendant un temps de traitement inactif. Ainsi, le qualificateur de transport d'un participant particulier est utilisé pour permettre une adaptation au milieu de transport à capacité supérieure ou inférieure. Il faut noter que le qualificateur de transport peut spécifier un nombre quelconque de niveaux de débit de transport. La présente invention n'est pas limitée à un niveau haut et un niveau bas de traitement. Par exemple, les niveaux de transport peuvent être spécifiés de façon à séparer des modem de bande 4800, des modem de bande 9600, des liaisons par réseau numérique à intégration de services ou ISDN, des liaisons par réseaux lents et rapides, etc. Dans tous les cas, le procédé 1000 commence à un point typique 1001 d'entrée de procédé. Puis, à l'étape 1002, il est déterminé si une installation de transport à haute vitesse est disponible entre le participant local et le participant demandeur. Si tel est le cas, le qualificateur de transport à haute vitesse est utilisé à l'étape 1003. En revanche, si le participant éloigné et le participant local sont couplés par un milieu de transport à faible vitesse, selon la détection de l'étape 1002, c'est un qualificateur de transport à faible vitesse qui est utilisé à l'étape 1004. Dans tous les cas, à l'étape 1005, une détermination du qualificateur de transport est achevée et le procédé qui l'accompagne peut continuer. Le transfert différé d'un traitement de donnée d'objet qui a été décrit en référence à l'étape 904 de la Figure 9 va maintenant être décrit en référence au procédé 1100 de la Figure 11. Par exemple, il a déjà été déterminé à l'étape 1101, qui est un point typique d'entrée de procédé à partir d'une boucle d'événement d'un procédé d'exécution, qu'une demande existante est en cours pour la donnée spécifique BLOB. Si une demande est déjà en cours pour le participant actuel de l'étape 1102, on considère une demande de modification de priorité pour le participant donné, et la priorité de la demande existante de BLOB sur la file d'attente de transfert peut être modifiée à l'étape 1107 illustrée à la Figure 11. Ainsi, toutes autres demandes de BLOB de ce participant particulier reçoivent de nouvelles priorités. Puis, à l'étape 1106, le procédé est achevé, puis on revient au procédé 1100 à partir d'un point typique de sortie du procédé. En revanche, si aucune demande n'était en cours pour ce participant particulier, ce qui est détecté en référençant pour le participant demandeur l'indice du participant qui est associé à l'élément de la file d'attente de transfert, le participant demandeur est ajouté, à l'étape 1103, à la liste de répartition de l'entrée existante en file d'attente de transfert. Par conséquent, l'indice de participant peut être ajouté à l'entrée existante en file d'attente de transfert. Une entrée correspondante de demande partielle peut exister pour chaque participant dans la liste de répartition, mais ceci n'est pas nécessaire. Des demandes venant de participants multiples peuvent avoir été reçues avant le début du transfert associé de données, et par conséquent, seule l'entrée unique en file d'attente de transfert existe. Dès lors que le transfert de données commence, des demandes additionnelles venant de nouveaux participants provoquent une combinaison avec l'entrée existante et l'addition d'une entrée partielle pour le transfert de données qui a été réalisé jusqu'à cet instant. Par conséquent, si le transfert de données a déjà commencé pour le BLOB particulier, comme spécifié dans son entrée en file d'attente de transfert à l'étape 1104, une demande partielle de la partie restante du BLOB doit être ajoutée dans l'entrée en file d'attente de transfert. Ceci est exécuté à l'étape 1105. En d'autres termes, toutes les données associées au BLOB et transférées précédemment aux autres participants éloignés doivent être transférées au participant demandeur actuel lors de l'achèvement du transfert actuel. Le but de ceci est que le participant puisse également mettre son BLOB à niveau avec celui des autres participants de la conférence. En revanche, si un transfert de données n'a pas encore commencé pour cette entrée, le participant demandeur a simplement été ajouté à l'entrée existante en file d'attente de transfert à l'étape 1103, et on passe de l'étape 1104 à l'étape 1106, le point de sortie du procédé. La demande partielle concernant la partie d'une entrée existante de transfert transférée précédemment à l'étape 1105 est illustrée de façon plus détaillée en référence à la Figure 12. Ainsi, une demande partielle additionnelle est ajoutée à la file d'attente de transfert à l'étape 1105. On va maintenant décrire ceci en référence à la Figure 12. La préparation de demande partielle est illustrée en se référant aux Figures 12a à 12c. Par exemple, deux participants B et C peuvent demander à un participant local de transférer un BLOB de 38.000 octets. Dans ce cas, initialement, le déport est réglé à zéro pour les deux participants et il est égal à 38.000 dans un transfert restant. Puis, à un certain instant intermédiaire ultérieur, par exemple à l'instant t1, qui est le temps après le commencement du transfert de données, illustré à la Figure 12a, le déport de transfert est égal à 2.000 et la dimension de transfert restante est égale à 36.000, ce qui indique que 2. 000 octets ont été transférés jusqu'ici. Ceci est illustré en référence à la partie 1201 et à la partie 1202 de la représentation graphique du BLOB 1200. A cet instant, un troisième participant, le participant D, peut demander au participant local un transfert de la même donnée de BLOB. Dans ce cas, le participant D est ajouté à la liste de répartition de l'entrée existante en file d'attente de BLOB dont le déport est de 2. 000 et la taille 36.000 et un élément de file d'attente de transfert partiel ultérieur, qui correspond à la demande, est ajouté à la file d'attente de transfert à une position située après l'entrée actuelle en file d'attente de transfert, pour un déport de zéro et une dimension de 2.000. Ainsi, à un instant ultérieur t2 illustré à la Figure 12b, le participant D est ajouté à la liste existante de répartition d'entrée de transfert et le transfert peut se poursuivre à partir du déport 2.000 de transfert et de la dimension restante de transfert de 36.000 indiquée dans l'entrée de file d'attente de transfert de BLOB. Ceci est représenté graphiquement en référence à 1210 qui illustre le transfert partiel 1211 effectué jusqu'ici et la partie restante 1212. Finalement, lors de l'achèvement du transfert de l'élément représenté à la Figure 12b, une autre entrée en file d'attente est référencée pour ne transférer qu'une partie du BLOB puisque la demande du participant D a été reçue au milieu du transfert initial vers les participants B et C. Dans ce cas, le déport de l'entrée suivante de transfert à l'instant t3 illustrée à la Figure 12c est de zéro, ce qui indique le début du fichier, et la dimension du transfert restant est de 2.000, ce qui indique qu'il est demandé que les 2.000 premiers octets du BLOB soient transférés au participant D. Ceci est illustré graphiquement en référence à 1220 qui illustre le BLOB complet et la seule partie 1221 dont le transfert au participant D est demandé par cette entrée en file d'attente. Dès lors que ce transfert partiel a été achevé, tous les participants B, C et D ont reçu le BLOB complet et des transferts redondants, de la partie de la donnée représentée par 1202 et par 1112 aux Figures 12a et 12b, ont été évités. Ainsi, le participant D ne reçoit que la partie qui a été transférée jusqu'à l'instant o sa propre demande a été effectuée, c'est-à-dire la partie représentée par la zone 1221 à la Figure 12c. Le transfert de données de la fraction partielle illustrée à la Figure 12c est transféré à partir de la fin de la fraction partielle jusqu'au début, afin que le BLOB puisse être maintenu de façon contiguë dans la mémoire du participant demandeur. Puis, à l'achèvement de la réception de la partie partielle illustrée à la Figure 12c, le participant D notifie à son interface humaine de mettre à jour l'affichage de l'annotation qui contient l'objet de BLOB précédemment incomplet. Ainsi, à l'achèvement du transfert indiqué par l'entrée de transfert représentée à la Figure 12c, le transfert du BLOB à tous les participants B, C et D est complet. Le transfert vers les participants B et C est complet à l'achèvement du transfert associé à l'entrée d'origine en file d'attente. Le transfert au participant D est achevé à un instant ultérieur, lorsque l'entrée en file d'attente associée à la demande partielle est achevée. Pendant des transferts de telles données de BLOB, les participants éloignés et les participants locaux peuvent être informés de ces opérations en utilisant une barre d'évolution ou une autre particularité d'interface d'utilisateur sous commande de la couche 210 d'interface humaine, ou HI, de l'agent pendant le temps inactif du participant. Ainsi, l'utilisateur peut être informé de transferts intermédiaires de données en vue d'une rétroaction appropriée du système. Il faut noter que le mécanisme de transfert de données du BLOB utilise un protocole Clear-to-Send ou CTS, c'est-à-dire disponible pour envoi, dans lequel, si un transfert de données associé à une entrée particulière en file d'attente de transfert ne peut pas se poursuivre parce qu'un récepteur n'est pas disponible pour envoi, des entrées ultérieures en file d'attente de transfert qui ne contiennent pas un récepteur qui n'est pas disponible pour envoi sont prises en compte pour le transfert. Ceci est exécuté afin de maximiser le potentiel total du milieu de transport, pendant les temps inactifs de participant individuel. Le protocole de disponibilité pour envoi de la présente invention est décrit de façon plus détaillée en liaison avec la Figure 18. En se référant maintenant à la Figure 13, un schéma architectural illustre les composants du Background Transfer Manager, ou BTM, c'est-à- dire du gestionnaire de transfert d'arrière plan, de la présente invention. Le transfert de grandes données d'objets est commandé par le gestionnaire de transfert d'arrière plan. Le gestionnaire de transfert d'arrière plan consiste en six parties majeures: 1) une logique de commande 1312 de connexion et de déconnexion de participant, 2) une logique de traitement 1314 de demande, 3) une logique de traitement 1316 de transfert de données, 4) une liste 1318 de disponibilité pour envoi, 5) une liste 1320 de transferts de sortie et 6) une liste 1322 de transferts d'entrée. Le composant 1312 de logique est décrit en liaison avec les Figures 14 et 15. Les composants 1314 et 1316 de logique sont décrits en liaison avec les Figures 16 à 20. La liste 1318 de disponibilité pour envoi est utilisée pour maintenir l'état de disponibilité pour envoi de demandes. Le protocole est décrit en liaison avec la Figure 18. La liste 1322 de transferts d'entrée est utilisée pour enregistrer les entrées pour lesquelles les demandes de données BLOB ont été soumises à des utilisateurs éloignés. Le gestionnaire de transfert d'arrière plan utilise cette liste lorsqu'il traite des demandes ultérieures afin de déterminer s'il doit * envoyer une nouvelle demande ou une demande de modification de priorité. La liste 1320 de transferts de sortie est utilisée pour maintenir des priorités de transferts de données BLOB sortantes. La logique de traitement 1312 de connexion et de déconnexion de participants concerne une nouvelle initialisation lors de la notification d'une connexion de participant, et la purge d'une information spécifique au participant lors d'une notification de déconnexion de participant. En se référant maintenant aux Figures 14 et 15, des schémas logiques illustrent ce traitement de connexion et de déconnexion. En se référant à la Figure 14, une notification d'une connexion de participant est reçue au bloc 1410. Le participant nouvellement connecté est ajouté, au bloc 1420, à la liste 1318 de disponibilité pour envoi. Selon les caractéristiques du milieu de transport, le participant est qualifié, aux blocs 1428 et 1430 pour un transfert à haute vitesse selon une dimension optimale correspondante de paquet ou est qualifié, aux blocs 1434 et 1436, pour un transfert à basse vitesse selon une dimension optimale correspondante de paquet. En se référant à la Figure 15, une notification d'une déconnexion de participant est reçue au bloc 1510. La dimension optimale de paquet est recalculée au bloc 1520. Le participant est enlevé, au bloc 1522, de la liste de disponibilité pour envoi. Le participant est enlevé, au bloc 1524, de toutes les listes de répartition pour toutes les entrées en file d'attente de transfert. Des entrées en file d'attente de transfert pour lesquelles le participant est le seul récepteur sont enlevées au bloc 1526. A l'instant de la connexion ou de la déconnexion des participants, des dimensions optimales de transfert sont déterminées pour chaque niveau de début de transport, à haute et à basse vitesses, en utilisation. Ces dimensions restent constantes entre les événements de connexion et de déconnexion de participant. En d'autres termes, seuls des événements de connexion et de déconnexion de participants affectent la dimension optimale de transfert. Il faut noter que la dimension optimale de transfert n'est pas une dimension maximale de paquet transférable. Il s'agit de la dimension optimale qui peut être traitée pour empêcher une division du paquet. En utilisant cette dimension de paquet, ou une dimension plus petite, le paquet prend le trajet le plus rapide à travers la logique de traitement des deux extrémités, d'expédition et de réception. En se référant à nouveau à la Figure 13, la logique 1314 de traitement de demande est utilisée sur les deux systèmes, émetteur et récepteur. La logique 1314 de traitement de demande et la logique 1316 de transfert de données utilisent l'une et l'autre une file d'attente de transfert pour suivre le statut de demandes de BLOB et de données de BLOB. En se référant à la Figure 16, un schéma architectural illustre la structure d'une entrée 1610 dans une file d'attente de transfert du gestionnaire de transfert d'arrière plan. L'entrée 1610 en file d'attente de transfert comprend une référence à un objet unique BLOB 1612 qui représente l'objet BLOB dont le suivi est assuré par l'entrée en file d'attente de transfert. Un déport 1614 de transfert suivant et une dimension 1616 de transfert restant sont utilisés pour le suivi de l'évolution du transfert de données BLOB. La liste 1618 de récepteurs est une liste de participants qui devraient recevoir le BLOB particulier identifié par la référence 1612. Une entrée précédente 1620 en file d'attente de transfert et une entrée suivante 1622 en file d'attente de transfert sont utilisées pour relier entre elles des demandes de BLOB dans la file d'attente de transfert. En se référant à la Figure 19, la logique 1910 de traitement de demandes pour un participant demandeur est illustrée. La Figure 20 illustre la logique 2010 de traitement de demandes pour un participant qui est à l'origine d'un BLOB. Un participant qui est à l'origine d'un BLOB d'une donnée de BLOB envoie à d'autres participants une structure d'objet de BLOB sans sa donnée correspondante. Ces autres participants sont appelés des "demandeurs" en ce qui concerne cette donnée de BLOB. Comme représenté à la Figure 19, un demandeur de donnée BLOB vérifie d'abord la liste 1322 de transfert d'entrée pour déterminer si un BLOB particulier est déjà dans la liste 1322: c'est bloc de décision 1912. Si tel est le cas, une demande de modification de priorité est envoyée au participant qui est à l'origine du BLOB, en augmentant ainsi la priorité de la demande existante de donnéeBLOB, au bloc de traitement 1922. Si le BLOB n'est pas déjà dans la liste 1322 de transfert d'entrée, le demandeur de BLOB ajoute une entrée en file d'attente de transfert à la liste 1322 de transfert d'entrée, au bloc de traitement 1918, et envoie une nouvelle demande de BLOB de donnée au participant qui est à l'origine du BLOB, au bloc de traitement 1920. La logique de traitement de donnée pour un demandeur de BLOB se termine ensuite par le bloc de retour 1924. Comme représenté à la Figure 20, le participant qui est à l'origine du BLOB traite ensuite cette demande et, soit ajoute une nouvelle entrée en file d'attente de transfert de sortie, au bloc de traitement 2018, soit modifie la priorité à une entrée en file d'attente de transfert existante, au bloc de traitement 2026, soit combine la demande avec une entrée existante, au bloc de traitement 2034, pour suivre le transfert de la donnée de BLOB. Aucun transfert de donnée de BLOB ne résulte de ce traitement. La Figure 17 illustre un exemple de la modification de priorité de file d'attente de transfert. Comme représenté, les demandes de BLOB sont ajoutées à la file d'attente de transfert dans l'ordre reçu, aux étapes 1720 et 1730, jusqu'à ce qu'une demande d'une modification de priorité soit reçue, à l'étape 1740. A l'étape 1740, la demande 1 est avancée devant la demande 2. Les demandes ultérieures sont ajoutées à la file d'attente de transfert, à l'étape 1750, jusqu'à ce qu'une autre demande de modification de priorité soit reçue, à l'étape 1760. La demande 3 est alors déplacée devant les deux demandes 1 et 2. Si une autre demande de modification de priorité est reçue, la demande concernée, c'est-à-dire la demande 1 à l'étape 1770, est avancée devant les autres demandes dans la file d'attente de transfert. En se référant à nouveau à la Figure 13, la logique 1316 de traitement de transfert de données est utilisée pendant le temps inactif de traitement. A cet instant, le gestionnaire de transfert d'arrière plan examine la file d'attente actuelle de sorties quant à des entrées qui demandent un transfert de données. Pour ces entrées, le gestionnaire de transfert d'arrière plan vérifie d'une façon répétée si le transport est disponible pour envoi d'un paquet d'une dimension optimale, déterminée précédemment, à la liste de récepteurs listés dans l'entrée en file d'attente de transfert, et il envoie le paquet en cas de disponibilité pour envoi. La liste 1318 de disponibilité pour envoi est utilisée pour suivre l'état de disponibilité à l'envoi concernant des paquets de données du BLOB. Si des récepteurs ne sont pas disponibles pour envoi, ils sont marqués comme non disponibles pour envoi, et le gestionnaire de transfert d'arrière plan passe à l'entrée suivante, dans la file d'attente de transfert, pour laquelle la liste de récepteurs ne contient pas un récepteur qui n'est pas disponible pour envoi et, il répète le processus d'envoi de paquets. Ce processus se poursuit jusqu'à ce que, soit toutes les entrées de gestionnaire de transfert d'arrière plan ont été traitées, soit les participants sont marqués comme non disponibles pour envoi. A cet instant, l'état d'indisponibilité pour envoi de tous les participants est effacé afin de préparer le traitement suivant de temps inactif. La Figure 18 illustre un exemple de traitement de disponibilité pour envoi selon la présente invention. Dans cet exemple, chaque cellule ou case représente une entrée en file d'attente de transfert. Le numéro de chaque cellule représente un numéro d'entrée qui n'est utilisé que dans des buts d'identification. La lettre ou les lettres de chaque cellule représente ou représentent le ou les récepteurs qui correspondent à l'entrée en file d'attente de transfert. A l'état initial dans cet exemple, à l'étape 1810, chaque entrée, ou cellule, en file d'attente de transfert est initialisée et chaque récepteur est initialement disponible pour envoi: c'est-à-dire A-OK, B-OK, et C-OK. A l'étape 1820, des paquets venant de l'entrée 1 sont envoyés jusqu'à ce que le récepteur B ne soit plus disponible pour envoi, c'est-à-dire qu'ils deviennent indisponibles pour envoi ou NCTS. Dans ce cas, la logique 1316 de traitement de transfert de données décale l'opération de transfert de données vers l'entrée 2, à l'étape 1830. A l'étape 1830, des paquets venant de l'entrée 2 sont envoyés jusqu'à ce que le récepteur C ne soit plus disponible pour envoi. A l'étape 1840, l'entrée 3 est sautée, parce que le participant B est un récepteur de l'entrée 3 et n'est pas disponible pour envoi. A l'étape 1850, des paquets venant de l'entrée 4 sont envoyés jusqu'à ce que le récepteur A ne soit plus disponible pour envoi. Puisque toutes les entrées de la file d'attente de transfert sont non disponibles pour envoi à l'étape 1860, le traitement de transfert de données se termine et le traitement revient à la boucle principale. Ce processus est répété pendant chaque temps inactif. Ainsi, en conclusion, on a décrit un procédé perfectionne de transmission de très grandes données d'objets, et la synchronisation différée de participants dans une conférence électronique. Bien que la présente invention ait été décrite en se référant à des modes de réalisation spécifiques, l'homme de l'art comprend que des variantes et modifications peuvent être apportées. REVENDICATIONS 1. Procédé de transfert (801 à 809), mis en oeuvre dans un système de conférence électronique dans lequel des données sont partagées entre plusieurs participants pendant une conférence électronique, de blocs de données de grand objet entre lesdits participants pendant ladite conférence électronique caractérisé en ce qu'il comprend les étapes consistant à: a. recevoir une demande asynchrone de données d'un grand objet (801 à 803); b. placer ladite demande dans une file d'attente de demandes (805); c. recevoir une demande asynchrone de modification de priorité (804) dans ladite file d'attente de demandes; d. déterminer (805) une capacité de milieu de transport; e. segmenter en blocs de données (805) lesdites données de grand objet, une dimension desdits blocs de données étant variable et correspondant à ladite capacité dudit milieu de transport; f. transférer (806 et 808) lesdites données de grand objet demandées à chacun desdits participants par l'intermédiaire dudit milieu de transport; et g. enlever (807 et 809) ladite demande de ladite file d'attente de demandes lors de l'achèvement de l'étape d'envoi desdites données de grand objet demandées. 2. Procédé selon la revendication 1, caractérisé en ce que ledit grand objet est un grand objet binaire (ou BLOB). 3. Procédé selon la revendication 2, caractérisé en ce que ladite étape de mise en place de ladite demande dans une file d'attente de demandes inclut en outre une étape de maintien de file d'attente de transfert qui inclut une entrée pour chaque demande de transfert d'un ou plusieurs BLOB. 4. Procédé selon la revendication 2, caractérisé en ce qu'il comprend en outre l'étape consistant à ne transférer un BLOB d'un participant (806 et 808) à un autre participant que si un état de transfert indique la disponibilité pour envoi. 5. Procédé selon la revendication 3, caractérisé en ce qu'il comprend en outre l'étape consistant à modifier la priorité de ladite file d'attente de transfert si une demande de modification de priorité (804) est reçue d'un participant. 6. Appareil inclus dans un système de conférence électronique dans lequel une donnée est partagée (801 à 809) entre plusieurs participants pendant une conférence électronique, et servant à transférer des grands blocs de données de grand objet entre lesdits participants pendant ladite conférence électronique, caractérisé en ce qu'il comprend: a. un moyen de réception d'une demande asynchrone (801 à 803) de données de grand objet; b. un moyen de mise en place (805) de ladite demande dans une file d'attente de demandes; c. un moyen de réception (804) d'une demande asynchrone de modification de priorité dans ladite file d'attente de demandes; d. un moyen de détermination (805) d'une capacité de milieu de transport; e. un moyen de segmentation (805) desdites données de grand objet en blocs de données, une dimension desdits blocs de données étant variable et correspondant à ladite capacité dudit milieu de transport; f. un moyen de transfert (806 et 808) desdites données de grand objet demandées à chacun desdits participants par l'intermédiaire dudit milieu de transport; et g. un moyen d'enlèvement (807 et 809) de ladite demande, hors de ladite file d'attente de demandes, lors de l'achèvement de l'étape d'envoi desdites données de grand objet demandées. 7. Appareil selon la revendication 6, caractérisé en ce que ledit grand objet est un grand objet binaire (ou BLOB). 8. Appareil selon la revendication 7, caractérisé en ce que ledit moyen de mise en place de ladite demande dans une file d'attente de demandes inclut en outre un moyen de maintien de file d'attente de transfert qui inclut une entrée pour chaque demande de transfert d'un ou plusieurs BLOB. 9. Appareil selon la revendication 7, caractérisé en ce qu'il comprend en outre un moyen permettant de ne transférer un BLOB (806 et 808) d'un participant à un autre participant que si un état de transfert indique la disponibilité pour envoi. 10. Appareil selon la revendication 8, caractérisé en ce qu'il comprend en outre un moyen de modification de la priorité de ladite file d'attente de transfert si une demande (804) de modification de priorité est reçue d'un participant.