Brevet FR2882164A1 — publié le 20060818

La présente invention se rapporte au transfert de données numériques, à format progressif ou scalable, entre un dispositif client et un dispositif serveur à travers un réseau de communication. Elle trouve une application particulière dans la livraison de données numériques et, plus particulièrement, d'images numériques ayant un format progressif ou scalable. D'une manière générale, au sein d'un réseau de communication, certains ordinateurs serveurs offrent des services aux autres ordinateurs, dits clients, du réseau de communication. Autrefois, ces services étaient accessibles via des protocoles propriétaires, tels que CORBA ( Common Object Request Broker Architecture pour Architecture pour un Intermédiaire Commun dans les Requêtes d'Objets ), DCOM ( Distributed Component Object Mode/ pour Modèle de Composant Objet Distribué ) ou JINI ( Java Image I/O ). Aujourd'hui, ces services sont de plus en plus accessibles à l'aide de protocoles de communication non propriétaires ou normalisés, tels que SOAP. Le protocole SOAP ( Simple Object Access Protocol pour Protocole d'Accès Objet Simple ) est une application du langage de balisage XML ( Extensible Markup Language ). Il permet à deux ordinateurs de s'échanger des informations sous forme de blocs. D'une manière générale, un message SOAP consiste en une enveloppe contenant des blocs d'en-tête et des blocs de corps. Par ailleurs, le langage SOAP ne fournissant pas de protocole de communication propre, un message SOAP, c'est-à-dire une enveloppe SOAP, est effectivement transmis(e) d'un ordinateur à un autre par un protocole de communication, tel que le protocole de transfert hypertexte dit HTTP ( HyperText Transfer Protocol ), ou par un protocole utilisé pour l'échange de courrier électronique tel que SMTP ( Simple Mail Transfer Protocol ), ou bien encore par un protocole de transfert de fichiers de type FTP ( File Transfer Protocol ). La couche qui permet d'interfacer le protocole SOAP avec ces protocoles de communication est appelée, en anglais, un binding . L'outil permettant de traiter les messages SOAP est appelé, ci-après, processeur SOAP. En pratique, inclure des données binaires dans des données XML nécessite un encodage préalable des données binaires au format base 64. Or, l'encodage au format base 64 implique une augmentation d'un tiers du volume des données. Les protocoles SwA ( SOAP Messages with Attachments ) et MTOM ( Message Transmission Optimization Mechanism pour Mécanisme d'Optimisation de la Transmission de Message ) définissent, respectivement pour le langage SOAP versions 1.1 et 1.2, un moyen d'attacher au message les données binaires brutes, c'est-à-dire sans encodage en base 64. Ceci permet donc d'optimiser les messages en terme de bande passante, mais aussi en terme de temps de calcul à l'émission et à la réception des messages, puisque le codage en base 64 et le décodage en base 64 ne sont plus nécessaires. En pratique, les protocoles SwA et MTOM s'appuient tous les deux sur le format MIME Multipart ( Multipurpose Internet Mail Extensions ), qui est un protocole de communication qui permet d'inclure autre chose que du texte (image, par exemple) dans le courrier électronique. En particulier, SwA décrit une façon d'écrire un message SOAP 1.1 dans une partie d'un message MIME Multipart et une façon de référencer les autres parties MIME du message dans le message SOAP. Le protocole MTOM décrit une sérialisation de messages SOAP 1.2 au format MIME Multipart. Un service SOAP est en général décrit par un document WSDL ( Web Service Description Language ). WSDL est un langage de description de service spécialement adapté à la description de services SOAP ou HTTP. On connaît aussi le langage XOP ( XML-binary Optimised Packaging ), qui est une application du langage XML. Cette spécification fournit une méthode de sérialisation de messages XML dans un format d'empaquetage extensible (c'est-à-dire un format dans lequel on peut délimiter des parties). Elle décrit notamment la sérialisation XML au format MIME Multipart/related. Le message XML est alors la partie MIME racine du message et l'apport de XOP consiste à remplacer les données binaires encodées classiquement dans un message XML en base 64 par une référence sur une partie MIME. Ceci permet d'éviter la redondance et le temps de traitement introduits par la représentation en base 64 des données binaires. L'outil permettant d'analyser le format MIME est appelé, ciaprès, analyseur MIME. Par ailleurs, la notion de scalabilité (ou progressivité) est liée à la notion de compression de données multimédia. Afin d'adresser plusieurs dispositifs clients avec un même fichier compressé, il est nécessaire de disposer des données audio, images et/ou vidéo dans un format progressif composé d'une version de base et d'une ou plusieurs versions de raffinement. De plus, de tels formats scalables permettent également à un dispositif serveur de transmettre les données de façon progressive ( streaming ) vers un ou plusieurs dispositifs clients. On peut citer comme exemple de format scalable, dans le cadre de la compression d'images, le standard JPEG2000 (acronyme de Joint Photographic Expert Group ), avec son protocole de transmission Internet JPIP ( JPEG 2000 Internet Protocol ) qui, dans le contexte d'une application client/serveur, consiste à échanger des données JPEG2000. Un tel protocole JPIP permet de transmettre uniquement les données encodées nécessaires correspondant à une requête d'un dispositif client. Par exemple, les données correspondantes à une zone donnée de l'image ou les données pour la basse résolution de l'image sont uniquement transmises après encodage. En pratique, le mécanisme MTOM décrit ci-avant permet d'attacher des données binaires, de type image, audlio ou vidéo, à des données de type texte, comme des messages XML, au sein d'une enveloppe SOAP. Ceci signifie qu'un serveur répondant à une requête client sur une image ou une vidéo peut émettre un message dont la taille dépend de la taille de l'image ou de la vidéo demandée. Le message peut donc être d'une taille importante et son traitement peut s'avérer préjudiciable dans le cas de dispositifs clients possédant une faible bande passante pour communiquer avec le dispositif serveur ou de dispositifs clients ne disposant pas des capacités de mémoire, de calcul et/ou d'affichage suffisantes pour traiter l'intégralité du message ainsi formé. Cette indétermination peut, dans un premier temps, s'avérer gênante d'un point de vue qualité de service pour l'usager, qui doit attendre la fin de réception et de traitement du message pour visualiser l'image ou la vidéo contenue dans le message. Une conséquence plus dommageable est par exemple la saturation 5 de la mémoire de l'appareil client qui peut générer des erreurs dans le traitement du message et éventuellement compromettre la stabilité de l'application, voire du système de traitement. Une première solution à ce problème est proposée dans la demande de brevet US2003/0055907A1 intitulée Clientless electronic mail MIME attachment re-delivery system via the web to reduce network bandwidth usage . Cette solution évite la saturation du réseau dans un système de messagerie électronique en traitant les courriers contenant des pièces jointes. La solution consiste à remplacer chaque pièce jointe par une référence sur laquelle l'application cliente peut faire une requête si elle souhaite récupérer la pièce jointe correspondante. Toutefois, cette solution s'avère relativement brutale puisqu'il s'agit d'un système tout ou rien , dans lequel chaque pièce jointe est soit intégralement transmise, soit entièrement retirée du message. De plus, elle nécessite une nouvelle, voire plusieurs, requête(s) du client pour récupérer les pièces jointes éventuellement remplacées par des liens. Une seconde solution est proposée dans le brevet US 6,684,088, intitulé System and method for displaying electronic mail messages on a low bandwidth device . Aussi bien le corps du message (un courrier électronique) que les pièces attachées ( attachments ) éventuelles sont ici adaptées par le dispositif serveur en fonction des caractéristiques de dispositifs clients mobiles et communiquant avec le même serveur via le protocole WAP ( Wireless Application Protocol ). L'adaptation du message à un appareil client donné incombe au dispositif serveur et conduit ensuite à l'émission d'un message adapté et formaté selon les caractéristiques du dispositif client. Le choix est ensuite laissé au client de demander plus d'informations sur les contenus du message électronique. Ce système s'applique uniquement à des services de messagerie électronique et à leurs protocoles dédiés tels que IMAP4 ( Internet Message Access Protocol version 4 ) ou POP3 ( Post Office Protocol 3 ). Par contre, il ne s'applique pas aux services web en général s'appuyant sur le protocole SOAP. Le Demandeur s'est posé le problème de fournir un transfert de 5 données numériques à format progressif ou scalable n'ayant pas les inconvénients des transferts de l'art antérieur. La présente invention apporte justement une solution à ce problème. Elle porte sur un procédé de transfert de données numériques entre un dispositif client et un dispositif serveur sur un réseau de communication, ledit procédé étant mis en oeuvre au sein dudit dispositif serveur. Selon une définition générale de l'invention, le procédé comprend les étapes suivantes: i) en provenance du dispositif client, recevoir une requête de livraison, écrite en format de balisage, d'un objet numérique ou d'une partie d'un objet numérique choisi, ii) obtenir dans le réseau de communication une représentation de l'objet demandé, iii) vérifier si la représentation de l'objet ainsi obtenu correspond à un format de compression de données de type progressif, iv) en cas de vérification positive, diviser l'objet numérique en une pluralité de sous-parties, à chaque sous-partie étant attribué un rang de priorité élevé défini selon au moins un critère choisi, et v) envoyer à destination du dispositif client une réponse en format de balisage comprenant lesdites sous-parties de l'objet en format binaire et les rangs de priorité associés en format de balisage. Ainsi, le procédé selon l'invention est une transmission de données binaires dans des messages de format progressif ou scalable, qui laisse à l'application la possibilité de traiter une ou plusieurs sous parties du message afin d'une part, de disposer plus rapidement d'au moins une partie des pièces considérée relativement importante selon un critère choisi et, d'autre part, de laisser une issue de secours en cas d'erreur durant la lecture du message. Selon une réalisation, les paramètres de la requête provenant du dispositif client sont définis par des structures de balisage de type XML ou analogue échangées entre le dispositif client et le dispositif serveur par un protocole de transport de type SOAP ou analogue. Selon une autre réalisation, l'envoi à destination du dispositif client de la réponse s'effectue par l'envoi d'un message comportant des structures de balisage de type XML ou analogue et des données binaires, le message correspondant étant formaté selon un format de balisage spécifique de type XOP ou analogue. Par exemple, l'envoi du message s'effectue par un protocole de transport de type SOAP ou analogue, le message étant sérialisé selon le protocole MTOM ou analogue. Selon encore une autre réalisation, les données binaires de chaque souspartie de l'objet sont incluses dans une partie MIME ou analogue. Par exemple, le critère de priorité est défini en fonction d'au moins une information relative à l'objet numérique ou au transfert de celui-ci et appartenant au groupe formé par le débit du transfert, la résolution de l'objet, la qualité de l'objet. En pratique, le rang de priorité est exprimé sous la forme d'une chaîne de critères numériques, alphanumériques, ou d'opérateurs booléens. En pratique, le rang de priorité est inséré dans la réponse du dispositif serveur sous forme d'un attribut dans le langage de balisage. En cas de rang de priorité élevé, l'insertion sous forme d'attribut dans la réponse du dispositif serveur est optionnelle. En pratique, la requête client comprend l'URI de l'objet demandé. Selon une réalisation, le format de compression de données prédéterminé de type progressif est le format de type JPEG2000. La présente invention a également pour objet un procédé de transfert de données numériques entre un dispositif client et un dispositif serveur sur un réseau de communication, ledit procédé étant mis en oeuvre au sein dudit dispositif client, ledit procédé comprenant les étapes suivantes: 1) en provenance du dispositif serveur et, en réponse à une requête de livraison d'un objet numérique ou d'une partie d'un objet numérique choisi adressée audit dispositif serveur, recevoir une réponse en format de balisage comprenant des rangs de priorité en forrnat de balisage attribués à des sous-parties de l'objet et lesdites sous-parties de l'objet en forrnat binaire; 2) traiter les sous-parties reçues dans l'ordre décroissant de leur rang de priorité ; 3) à chaque sous-partie ainsi traitée, vérifier une condition de capacité de traitement; 4) en cas de vérification positive, traiter les données binaires de la sous- partie de l'objet de rang de priorité inférieur; et 5) en cas de vérification négative, ne pas prendre en compte la sous-partie courante, ainsi que les sous-parties de rang de priorité inférieur. La présente invention a également pour objet un dispositif serveur pour le transfert de données numériques avec un dispositif client sur un réseau de communication. Selon un autre aspect de l'invention, le dispositif comprend: -des moyens de réception aptes, en provenance du dispositif client, à recevoir une requête de livraison en forrnat de balisage d'un objet numérique ou d'une partie d'un objet numérique choisi, - des moyens pour obtenir dans le réseau de communication une 20 représentation de l'objet demandé, - des moyens de vérification pour vérifier si la représentation de l'objet ainsi obtenu correspond à un format de compression de données de type progressif, - des moyens de traitement pour, en cas de vérification positive, diviser l'objet numérique en une pluralité de sous-parties, à chaque sous-partie étant attribué un rang de priorité défini selon au moins un critère choisi, et - des moyens de communication pour envoyer, à destination du dispositif client, une réponse en format de balisage comprenant les sous-parties de l'objet en format binaire et les rangs de priorité associés en format de balisage. La présente invention a également pour objet un dispositif client pour le transfert de données numériques avec un dispositif serveur sur un réseau de communication, ledit dispositif client comprenant: - des moyens de réception aptes à recevoir, en provenance du dispositif serveur et, en réponse à une requête de livraison d'un objet numérique ou d'une partie d'un objet numérique choisi adressée audit dispositif serveur, une réponse en format de balisage comprenant des rangs de priorité en format de balisage attribués à des sous-parties de l'objet et lesdites sous- parties de l'objet en format binaire; et - des moyens de traitement aptes à traiter les sous-parties reçues dans l'ordre décroissant de leur rang de priorité, à vérifier une condition de capacité de traitement à chaque sous-partie ainsi traitée, à traiter les données binaires de la souspartie de l'objet de rang de priorité inférieur en cas de vérification positive et à ne pas prendre en compte la sous-partie courante ainsi que les sous-parties de rang de priorité inférieur en cas de vérification négative. La présente invention a également pour objet un dispositif de transfert de données numériques entre un dispositif client et un dispositif serveur sur un réseau de communication, dans lequel le dispositif serveur et/ou le dispositif client est adapté pour la mise en oeuvre du procédé mentionné ci- avant. La présente invention a également pour objet un support d'informations lisible par un système informatique, caractérisé en ce qu'il comporte des instructions d'un programme informatique permettant la mise en oeuvre d'un procédé de transfert mentionné ci-avant. La présente invention a également pour objet un support d'informations amovible, partiellement ou totalement, lisible par un système informatique, caractérisé en ce qu'il comporte des instructions d'un programme informatique permettant la mise en oeuvre d'un procédé de transfert mentionné ci-avant, lorsque ce programme est chargé et exécuté par un système informatique. La présente invention a enfin pour objet un programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant la mise en oeuvre d'un procédé de transfert, lorsque ce programme est chargé et exécuté par un système informatique. D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description détaillée ci-après et des dessins dans lesquels: - la figure 1 représente schématiquement un réseau de communication dans lequel le procédé selon l'invention est mis en oeuvre; - la figure 2 représente schématiquement un ordinateur dans lequel le logiciel selon l'invention peut être exécuté ; - la figure 3 est un organigramme illustrant les étapes du procédé 10 selon l'invention côté dispositif serveur; - la figure 4 est un organigramme illustrant les étapes du procédé selon l'invention côté dispositif client; et - la figure 5 est un organigramme illustrant le traitement des éléments XOP selon l'invention. En référence à la figure 1, on a décrit un exemple de contexte applicatif de l'invention utilisant un dispositif serveur 1, traitant les données selon le protocole MTOM, un réseau de communication 2 ayant zéro ou plusieurs noeuds intermédiaires 4 et un ou plusieurs dispositifs clients 3 traitant les données selon le protocole MTOM. Il est prévu un échange, selon le protocole MTOM, entre le dispositif serveur 1 et les dispositifs clients 3 de messages 5 contenant des données binaires (audio, vidéo, images...). Ces messages 5 peuvent éventuellement traverser les noeuds intermédiaires 4 se trouvant dans le réseau 2. Les noeuds intermédiaires 4 se contentent de faire suivre les messages 5 venant du dispositif serveur 1 jusqu'aux dispositifs clients 3 et les requêtes 7 des dispositifs clients 3 vers le dispositif serveur 1. Un exemple d'utilisation est le suivant: le dispositif serveur 1 dispose d'une base de données d'images et d'un service web permettant de traiter des requêtes 7 de demande d'images et de répondre en retournant l'image demandée, le tout via des messages 5, écrits en langage SOAP et formatés en format MIME. L'invention porte essentiellernent sur la façon dont la réponse du dispositif serveur est construite et sur la façon dont elle est traitée par le dispositif client. Cette construction permet au dispositif client de disposer plus rapidement d'une partie de l'image et lui en indique les parties les plus importantes (ayant un rang de priorité élevé par exemple). La requête du dispositif client correspondant à la demande d'image est un message écrit en langage SOAP classique. En référence à la figure 2, on a représenté un dispositif 10, tel un micro-ordinateur et ses différents périphériques, dans lequel l'invention peut être mise en place. Le dispositif 10 comprend, par exemple, une caméra numérique 25 (ou un scanner ou tout moyen d'acquisition ou de stockage d'image) reliée à une carte graphique et fournissant des informations à compresser selon l'invention. Le dispositif 10 comporte une interface de communication 18 reliée au réseau de communication apte à transmettre des données numériques à compresser ou à transmettre des données compressées par le dispositif 10. Le dispositif 10 comporte également un moyen de stockage 14, tel que par exemple un disque dur, ainsi qu'un lecteur de disquette 15. La disquette 24 peut contenir des données compressées selon l'invention ainsi que le code de l'invention qui, une fois lu par le dispositif 10, est stocké dans le disque dur 14. Selon une variante, le programme du logiciel, permettant au dispositif de mettre en oeuvre l'invention, peut être stocké en mémoire morte 9 (appelée ROM). Selon une autre variante, le programme peut être reçu pour être stocké de façon identique à celle décrite précédemment par l'intermédiaire du réseau de communication 2. Le dispositif 10 est relié à un microphone 23, par l'intermédiaire de la carte d'entrée/sortie 22. Les données à transmettre (cas du dispositif serveur) selon l'invention sont, dans ce cas, du signal audio. Un écran 12 permet de visualiser les données à compresser (cas du dispositif client), à l'aide du clavier 13 ou de tout autre moyen (souris, par exemple). L'unité centrale 11 (appelée CPU) exécute les instructions relatives à la mise en oeuvre de l'invention, instructions stockées dans la mémoire morte 9 ou dans les autres éléments stockage. Lors de la mise sous tension, les programrnes de gestion des ressources SOAP (processeur SOAP) et de décompression stockés dans une mémoire non volatile, par exemple la ROM 9, sont transférés dans la mémoire vive RAM 17 qui contient alors le code exécutable de l'invention, ainsi que des registres pour mémoriser les variables nécessaires à la mise en oeuvre de l'invention. Bien entendu, les disquettes peuvent être remplacées par tout support d'information tel que CD-ROM ou carte mémoire. De manière plus générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non au dispositif, éventuellement amovible, mémorise un programme mettant en oeuvre le procédé d'exécution. Le bus de communication 21 permet la communication entre les différents éléments inclus dans le microordinateur 10 ou reliés à lui. La représentation du bus 21 n'est pas limitative et notamment l'unité centrale 11 est susceptible de communiquer des instructions à tout élément du micro-ordinateur 10 directement ou par l'intermédiaire d'un autre élément du micro-ordinateur 10. En référence à la figure 3, on a représenté la mise en oeuvre de l'invention côté dispositif serveur. Tout d'abord, lors de l'étape E301, le dispositif serveur reçoit la requête 7 du dispositif client. Cette requête 7 consiste en un message SOAP contenant un identifiant de l'image que le dispositif client souhaite récupérer. Lors de l'étape E302, le dispositif serveur extrait du message SOAP, grâce à un processeur SOAP, cet identifiant (URI par exemple) et récupère, lors de l'étape E303, le contenu associé (dans le mode de réalisation représenté ici, une image). Lors de l'étape E304, le dispositif serveur vérifie si le format de l'image est un format d'encodage progressif (scalable). Si tel est le cas, lors de l'étape E305, le dispositif serveur met en oeuvre une opération qui consiste à diviser le contenu de l'objet numérique en différentes sous-parties, reliées les unes aux autres selon une relation hiérarchique choisie. Cette division peut se baser sur un critère de débit pour la transmission de l'image, sur un critère de résolution de l'image si le dispositif serveur connaît les capacités d'affichage du dispositif client ou sur un critère de qualité de l'image. Par exemple, selon une réalisation, on considère une image en un format de compression de données progressif de type JPIEG2000 encodée sur R niveaux de résolution et Q niveaux de qualité. Une division consiste à borner le nombre des différentes parties ou sous-parties à N,VN e [1, max(R,Q)] et ainsi, définir les relations suivantes: Indice de la partie Niveau de résolution Niveau de qualité Niveau de priorité 1 Partie entière de 1 *R/N Partie entière de 1 *Q/N Pmax 2 Partie entière de 2*R/N Partie entière de 2*Q/N Pmax. (1-2/N) I I Partie entière de i'Q/N Pmax. (1-i/N) N R Q 0 Pour la division effective des données, le dispositif serveur dispose d'un décodeur (ou plus exactement d'un analyseur, dans la mesure où il n'y a pas de décodage complet des images, mais seulement une sélection de données) JPEG2000, qui récupère les données, ou l'incrément de données binaires associées respectivement à un niveau de résolution et à un niveau de qualité donnés, ou à l'incrément en résolution et/ou en qualité d'une sous-partie à une autre. Chaque sous-partie est insérée lors de cette même étape dans sa propre partie MIME, tel qu'illustré dans l'exemple 1 mentionné ci-après. La division effectuée, le serveur assigne des rangs de priorité, lors de l'étape E306, à chacune des sous-parties obtenues. IJn exemple de calcul de rang de priorité est donné dans le tableau ci-dessus. Le rang de priorité de chaque sous-partie est gardée en mémoire du dispositif serveur et est utilisée lors de la formation de la réponse à l'étape E308. Lors de l'étape E308 de formation de la réponse, le dispositif serveur peut signaler le rang de priorité des différentes sous-parties en format binaire transmises en pièces jointes au dispositif client, afin qu'il puisse décider de leur traitement ou non. Ceci est réalisé lors de l'écriture du message MTOM par le processeur SOAP: un attribut optionnel est ajouté à l'élément , qui signale la présence d'une pièce jointe. La valeur de cet attribut correspond à la valeur de rang de priorité calculée lors de l'étape E306 et tel qu'illustré dans le tableau précédent. L'exemple 1 ci-dessous illustre une telle réponse en utilisant le mécanisme MTOM décrit précédemment. En gras, apparaissent les différences par rapport à l'état de la technique (envoi de l'image en une seule partie au format MIME part, tel qu'illustré dans l'exemple 2 mentionné ci-après). Il est à noter que le mécanisme de priorité décrit ici n'est pas limitatif et peut être, par exemple, un système d'attribut booléen, indiquant simplement si la sous-partie est optionnelle ou obligatoire, ou encore ne mentionnant que les parties optionnelles ou tout autre moyen d'introduire une information d'importance ou de rang de priorité à l'égard de chaque sous-partie. De plus, si besoin, le dispositif serveur peut procéder à l'ordonnancement des sous-parties selon leur rang de priorité lors de l'étape E308. MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary; type="application/xop+xml"; start=" " ; start-info=" "application/soap+xml" Content-Description: An XML document with my picture in it --MIME_boundary Content-Type: application/xop+xml; charset=UTF-8; type="text/xml" Content-Transfer-Encoding: 8bit ContentID: mymessage.xml@example.org --MIME_boundary Content-Type: image/jp2 ContentTransfer-Encoding: binary Content-Length: 27841 Content-ID:http://example.org/myphoto_basic jp2 // binary octets for the first required part of the image --MIME boundary Content-Type: image/jp2 Content-Transfer-Encoding: binary Content-Length: 127893 Content-ID: http://example.org/myphoto_enhl.jp2 // binary octets for the second optional part of the image - -MIME boundary Content-Type: image/jp2 Content-Transfer-Encoding: binary Content-Length: 157896 Content-ID: http://example.org/myphoto_enh2.jp2 // binary octets for the third part of the image - -MIME boundary Exemple 1: réponse du dispositif serveur selon l'invention MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary; type="application/xop+xml"; start=" " ; start-info="text/xml" Content-Description: An XML document with my picture in it - -MIME_boundary Content-Type: application/xop+xml; charset=UTF-8; type="text/xml" Content-TransferEncoding: 8bit Content-ID: mymessage.xml@example.org - -MIME boundary Content-Type: image/jp2 Content-Transfer-Encoding: binary Content-Length: 324842 Content-ID: http://example.org/myphoto.jp2 // binary octets for the whole image - -MIME boundary Exemple 2: message MTOM de l'art antérieur Suite à l'étape E308 de formation de la réponse, celle-ci est envoyée au dispositif client, lors de l'étape E309 et cet envoi clôt le traitement du dispositif serveur. II est à noter que, si le dispositif serveur détecte que le format du contenu demandé n'est pas scalable, celui-ci procède alors à l'écriture de toutes les données images dans une seule MIME part , tel qu'illustré dans l'exemple 2 ci-dessus. Ceci est réalisé lors de l'étape E307. Cette étape est alors suivie de l'écriture complète du message de l'exemple 2, étape E308, puis de son émission vers le dispositif client, étape E309. En référence aux figures 4 et 5, on a décrit la mise en oeuvre de l'invention côté client. La première étape consiste en la réception de la réponse du dispositif serveur lors de l'étape E401. Cette réponse est un message MTOM. Le traitement de cette réponse commence à l'étape E402 par l'analyse (parsing en anglais) de l'en-tête au format MIME. Celle-ci indique, en référence à l'exemple 1, que le type du contenu est xop+xml et indique également la chaîne de caractères séparant les différentes parties MIME (MIME Boundary). L'en-tête indique également la partie MIME racine du message, via le champ start . L'analyse de la partie MIME correspondante commence lors de l'étape E403. C'est le processeur SOAP du dispositif client qui prend en charge cette opération en désérialisant l'enveloppe écrite en langage SOAP et en traitant éventuellement l'entête du message SOAP. Lors de l'étape E404, on commence le traitement du corps du message SOAP en récupérant le nom du premier élément, suivant la balise indiquant le début du corps du message SOAP ( ). Puis lors de l'étape E405, on vérifie si l'élément ainsi récupéré correspond à la balise , et, s'il ne s'agit pas du premier de ce type pour l'élément parent courant, on vérifie si l'élément précédent a été traité. Si cette balise n'est pas présente ou si la balise précédente a été écartée, on continue le traitement par l'étape E407 de recherche de l'élément suivant. Lors de cette même étape, on teste si cet élément suivant existe pour, soit reboucler vers l'étape E405, soit terminer le traitement vers l'étape E408. Si l'étape E405 de test indique que l'élément courant est bien un , le traitement se poursuit alors, selon l'étape E406, détaillée dans la suite en référence à la figure 5. En sortie de ce traitement, on passe à l'étape E407 où l'on teste si l'élément a été considéré ou non. Si oui, on passe à l'étape E405, sinon le traitement se termine (E408) sans considérer les autres éléments. Sur la figure 4, apparaît une partie de l'invention qui consiste à considérer que plusieurs éléments peuvent se suivre (rebouclage de l'étape E407 vers l'étape E405), ainsi que l'étape de test E405 permettant d'écourter éventuellement le traitement des parties MIME restantes. En référence à la figure 5, on a détaillé l'étape E406 de la figure 4. Les étapes de la colonne de gauche correspondent au traitement classique lorsque l'invention n'est pas utilisée, les étapes intermédiaires sur la droite correspondent à l'invention. La première étape du traitement, étape E61, consiste à activer l'analyseur MTOM. Cette étape consiste à récupérer, de l'analyseur XML, la valeur de l'espace de nommage courant et le préfixe associé (typiquement xop) et le nom de l'élément courant (Include). Elle consiste également à récupérer un booléen de l'application (décodeur/afficheur JPEG2000 selon un mode préféré) indiquant si les parties ou sous--parties de rang de priorité faible ou inférieur sont à considérer ou non (conformément à la description ci-après de l'étape E66). Si ces valeurs sont cohérentes (telles que définies dans la spécification XOP), alors l'étape suivante E62 consiste à vérifier si l'attribut href est bien présent et à récupérer sa valeur. A partir de cette étape, interviennent les modifications apportées par l'invention: l'étape E63 consiste à vérifier si un attribut priorité est présent ou non. S'il n'est pas présent (cas classique), on considère alors que la partie au format MIME référencée par l'attribut href est de priorité haute et doit être traitée. Cette partie MIME est alors récupérée lors de l'étape E67. Pour cela, un analyseur MIME cherche parmi les parties au format MIME du message, si l'une d'elles correspond au content-ID en valeur de l'attribut href. Si cette partie est trouvée lors du test de l'étape E68, alors les données binaires associées sont extraites du message et mises à disposition de l'application (décodeur/afficheur JPEG2000 selon un mode préféré) dans une mémoire tampon partagée lors de l'étape E69. Le traitement de l'élément se termine alors à l'étape E70. Si la partie MIME n'est pas trouvée, correspondant au test négatif de l'étape E68, l'analyseur MTOM doit alors générer une erreur (étape E71) qui doit remonter jusqu'à l'application, qui décide ou non de la poursuite du traitement via l'étape E407 de la figure 4. Si au cours de l'étape E63, un attribut priorité est détecté, alors l'analyseur MTOM récupère sa valeur à l'étape E64. L'étape suivante, étape E65, consiste à tester si la valeur de l'attribut priorité est élevée ou non. Si la valeur est une chaîne de caractères, cette étape peut consister en une comparaison avec haute et basse . Si la priorité est exprimée sous la forme d'une valeur entière, cette étape peut consister en un seuillage basé sur une valeur prédéfinie. Par exemple, si l'on définit N niveaux de priorités possibles, si n le niveau de priorité courant est supérieur ou égal à N/2, alors le rang de priorité est considéré comme élevé. Dans le cas où le rang de priorité est élevé, la partie MIME doit être traitée. Pour cela, elle est récupérée lors de l'étape E67 et suit ensuite les étapes E68, E69 et E70. Dans le cas d'une priorité considérée comme non élevée, l'étape E66 permet à l'application de décider du traitement ou non de la partie MIME associée. Cette étape peut consister en un test sur, par exemple, une quantité de données binaires préalablement reçues ou encore sur un critère de temps de traitement du dispositif client (par exemple pour de la vidéo ou de l'audio). La mise en oeuvre consiste, en cette étape E66, à traiter les parties MIME de rang de priorité faible ou inférieur également uniquement si la quantité de données déjà reçues est compatible avec les caractéristiques de la machine client. Pour cela, lors de cette étape E66, l'analyseur MTOM considère l'événement reçu de l'application lors de l'activation E61 pour déterminer si le traitement se termine sans considérer les données (passage à l'étape E70) ou en les traitant (passage à l'étape E67). Si les données ne sont pas considérées, un marqueur est conservé dans l'analyseur MTOM, puis passé au processeur SOAP lors de la recherche de l'élément suivant, étape E407 de la figure 4. Ce marqueur est utilisé par la suite dans le test de l'étape E405, comme décrit précédemment. La présente invention a l'avantage de fournir un moyen de hiérarchiser des données binaires via un protocole indépendant du transport et 25 des systèmes d'exploitation des dispositifs clients et serveurs. Une mise en oeuvre simplifiée de l'invention pourrait se faire en ne considérant que le premier xop:Include et en écartant les suivants. REVENDICATIONS 1. Procédé de transfert de données numériques entre un dispositif client (3) et un dispositif serveur (1) sur un réseau de communication (2) , ledit procédé étant mis en oeuvre au sein dudit dispositif serveur (1), caractérisé en ce qu'il comprend les étapes suivantes: i) en provenance du dispositif client (3), recevoir une requête de 10 livraison (7) en format de balisage d'un objet numérique ou d'une partie d'un objet numérique choisi, ii) obtenir dans le réseau de communication (2) une représentation de l'objet demandé, iii) vérifier si la représentation de l'objet ainsi obtenu correspond à 15 un format de compression de données de type progressif, iv) en cas de vérification positive, diviser l'objet numérique en une pluralité de sous-parties, à chaque sous-partie étant attribué un rang de priorité défini selon au moins un critère choisi, et v) envoyer à destination du dispositif client (3) une réponse en 20 format de balisage comprenant les sous-parties de l'objet numérique en format binaire et les rangs de priorité associés en format de balisage. 2. Procédé selon la revendication 1, dans lequel les paramètres de la requête provenant du dispositif client (3), sont définis par des structures de balisage de type XML ou analogue échangées entre le dispositif client (3) et le dispositif serveur (1) par un protocole de transport de type SOAP ou analogue. 3. Procédé selon la revendication 1 ou 2, dans lequel l'envoi à destination du dispositif client (3) de la réponse, s'effectue par l'envoi d'un message comportant des structures de balisage de type XML ou analogue et des données binaires, le message correspondant étant formaté selon un format de balisage spécifique de type XOP ou analogue. 4. Procédé selon la revendication 3, caractérisé en ce que l'envoi du message s'effectue par le protocole de transport de type SOAP ou analogue, le message étant sérialisé selon le protocole MTOM ou analogue. 5. Procédé selon la revendication 4, caractérisé en ce que les données binaires de chaque sous-partie de l'objet sont incluses dans une partie MIME ou analogue. 6. Procédé selon l'une des revendications 1 à 5, dans lequel ledit critère de priorité est défini en fonction d'au moins une information relative à l'objet numérique ou au transfert de celui-ci et appartenant au groupe formé par le débit du transfert, la résolution de l'objet, la qualité de l'objet. 7. Procédé selon l'une de revendications 1 à 6, dans lequel le rang de priorité est exprimé sous la forme d'une chaîne de caractères numériques, alphanumériques ou d'opérateurs booléens. 8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce que le rang de priorité est inséré dans la réponse du dispositif serveur sous forme d'un attribut dans le langage de balisage. 9. Procédé selon la revendication 8, caractérisé en ce que, en cas de rang de priorité élevé, l'insertion sous forme d'attribut dans la réponse du dispositif serveur (1) est optionnelle. 10. Procédé selon l'une des revendications 1 à 9, dans lequel la requête client comprend l'URI de l'objet demandé. 11. Procédé selon l'une des revendications 1 à 10, caractérisé en ce que le format de compression de données de type progressif est le format de type JPEG2000 ou analogue. 12. Procédé de transfert de données numériques entre un dispositif client (3) et un dispositif serveur (1) sur un réseau de communication (2), ledit procédé étant mis en oeuvre au sein du dispositif client (3), caractérisé en ce que le procédé comprend les étapes suivantes: 1) en provenance du dispositif serveur (1) et, en réponse à une requête de livraison d'un objet numérique ou d'une partie d'un objet numérique choisi adressée audit dispositif serveur (1), recevoir une réponse en format de balisage comprenant des rangs de priorité en format de balisage attribués à des sous-parties de l'objet et lesdites sous-parties de l'objet en format binaire; 2) traiter les sous-parties reçues dans l'ordre décroissant de leur rang de priorité; 3) à chaque sous-partie traitée, vérifier une condition de capacité de traitement; 4) en cas de vérification positive, traiter les données binaires de la sous-partie de l'objet de rang de priorité inférieur; 5) en cas de vérification négative, ne pas prendre en compte la sous-partie courante ainsi que les sous- parties de rang de priorité inférieur. 13. Procédé selon la revendication 12, caractérisé en ce que la condition de capacité de traitement est fonction d'une quantité binaire préalablement reçue par le dispositif client ou du temps de traitement dudit dispositif client (3). 14. Dispositif serveur pour le transfert de données numériques avec un dispositif client (3) sur un réseau de communication (2), caractérisé en ce qu'il comprend au sein dudit dispositif serveur (1) : -des moyens de réception aptes, en provenance du dispositif client (3), à recevoir une requête de livraison en format de balisage d'un objet 30 numérique ou d'une partie d'un objet numérique choisi, - des moyens pour obtenir dans le réseau de communication (2) une représentation de l'objet demandé, des moyens de vérification pour vérifier si la représentation de l'objet ainsi obtenu correspond à un format de compression de données de type progressif, - des moyens de traitement pour, en cas de vérification positive, diviser l'objet numérique en une pluralité de sous-parties, à chaque sous-partie étant attribué un rang de priorité défini selon au moins un critère choisi, et - des moyens de communication pour envoyer, à destination du dispositif client (3), une réponse en format de balisage comprenant les sous-parties de l'objet numérique en format binaire et les rangs de priorité associés en format de balisage. 15. Dispositif client pour le transfert de données numériques avec un dispositif serveur (1) sur un réseau de communication (2), ledit dispositif client (3) comprenant: - des moyens de réception aptes à recevoir, en provenance du dispositif serveur et, en réponse à une requête de livraison d'un objet numérique ou d'une partie d'un objet numérique choisi adressée audit dispositif serveur, une réponse en format de balisage comprenant des rangs de priorité en format de balisage attribués à des sous-parties de l'objet et lesdites sous-parties de l'objet en format binaire; et - des moyens de traitement aptes à traiter les sous-parties reçues dans l'ordre décroissant de leur rang de priorité, à vérifier une condition de capacité de traitement à chaque sous-partie ainsi traitée, à traiter les données binaires de la sous-partie de l'objet de rang de priorité inférieur en cas de vérification positive et à ne pas prendre en compte la sous-partie courante ainsi que les sous- parties de rang de priorité inférieur en cas de vérification négative. 16. Dispositif de transfert de données numériques entre un dispositif client (3) et un dispositif serveur (1) sur un réseau de communication (2) , caractérisé en ce qu'il comprend un dispositif serveur adapté pour la mise en oeuvre du procédé selon l'une quelconque des revendications 1 à 11 et/ou un dispositif client adapté pour la mise en oeuvre du procédé selon la revendication 12 ou la revendication 13. 17. Support d'informations lisible par un système informatique, caractérisé en ce qu'il comporte des instructions d'un programme informatique permettant la mise en oeuvre d'un procédé de transfert selon l'une quelconque des revendications 1 à 13. 18. Support d'informations amovible, partiellement ou totalement, lisible par un système informatique, caractérisé en ce qu'il comporte des instructions d'un programme informatique permettant la mise en oeuvre d'un procédé de transfert selon l'une quelconque des revendications 1 à 13, lorsque ce programme est chargé et exécuté par un système informatique. 19. Programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant la mise en oeuvre d'un procédé de transfert selon l'une quelconque des revendications 1 à 13, lorsque ce programme est chargé et exécuté par un système informatique.