FR2863127A1 - Procedes et dispositifs pour la delivrance asynchrone de donnees numeriques - Google Patents

Procedes et dispositifs pour la delivrance asynchrone de donnees numeriques Download PDF

Info

Publication number
FR2863127A1
FR2863127A1 FR0314147A FR0314147A FR2863127A1 FR 2863127 A1 FR2863127 A1 FR 2863127A1 FR 0314147 A FR0314147 A FR 0314147A FR 0314147 A FR0314147 A FR 0314147A FR 2863127 A1 FR2863127 A1 FR 2863127A1
Authority
FR
France
Prior art keywords
data
client system
col
request
server system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR0314147A
Other languages
English (en)
Inventor
Pascal Viger
Eric Nassor
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to FR0314147A priority Critical patent/FR2863127A1/fr
Priority to EP04292848A priority patent/EP1538808A1/fr
Priority to US11/002,400 priority patent/US7711804B2/en
Publication of FR2863127A1 publication Critical patent/FR2863127A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/32—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
    • H04N1/327—Initiating, continuing or ending a single-mode communication; Handshaking therefor
    • H04N1/32765—Initiating a communication
    • H04N1/32771—Initiating a communication in response to a request, e.g. for a particular document
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G06F16/9577—Optimising the visualization of content, e.g. distillation of HTML documents
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/32—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
    • H04N1/327—Initiating, continuing or ending a single-mode communication; Handshaking therefor
    • H04N1/32765—Initiating a communication
    • H04N1/32771—Initiating a communication in response to a request, e.g. for a particular document
    • H04N1/32776—Initiating a communication in response to a request, e.g. for a particular document using an interactive, user-operated device, e.g. a computer terminal, mobile telephone
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/32—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
    • H04N1/333—Mode signalling or mode changing; Handshaking therefor
    • H04N1/33376—Mode signalling or mode changing; Handshaking therefor according to characteristics or state of one of the communicating parties, e.g. available memory capacity
    • H04N1/33384—Mode signalling or mode changing; Handshaking therefor according to characteristics or state of one of the communicating parties, e.g. available memory capacity according to transient characteristics or state
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2355—Processing of additional data, e.g. scrambling of additional data or processing content descriptors involving reformatting operations of additional data, e.g. HTML pages
    • H04N21/2358—Processing of additional data, e.g. scrambling of additional data or processing content descriptors involving reformatting operations of additional data, e.g. HTML pages for generating different versions, e.g. for different recipient devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8146—Monomedia components thereof involving graphical data, e.g. 3D object, 2D graphics
    • H04N21/8153—Monomedia components thereof involving graphical data, e.g. 3D object, 2D graphics comprising still images, e.g. texture, background image

Abstract

Le procédé de délivrance asynchrone de données numériques selon l'invention est mis en oeuvre dans au moins un système serveur et au moins un système client reliés à travers un réseau de télécommunications.Selon le procédé, lors d'une demande de données émanant d'un système client, une information de contexte (CINF) représentative d'un premier état du système client lors de l'émission de la demande est associée à celle-ci.Lors de la délivrance au système client d'une réponse, la réponse incorpore l'information de contexte (CINF).Le système client extrait l'information de contexte (CINF) et réagit à celle-ci pour se mettre dans un second état analogue au premier état mentionné ci-dessus.Le procédé selon l'invention offre une gestion de contexte permettant à l'utilisateur d'associer les réponses reçues à des demandes parfois effectuées bien avant dans le temps.

Description

La présente invention concerne de manière générale la
distribution de données numériques à travers un réseau de télécommunications.
Plus particulièrement, l'invention concerne des procédé et dispositif pour délivrer de manière asynchrone, c'est-à-dire, en temps différé, 15 des données numériques à des postes clients.
Une application privilégiée particulièrement intéressante, mais non exclusive, de la présente invention est la distribution d'images numériques mufti-résolutions.
Dans un réseau de télécommunications, la délivrance asynchrone de données numériques se distingue essentiellement d'un service synchrone en ce que la réponse à une demande peut être stockée temporairement sur un serveur dédié sur le réseau avant d'être envoyée à un poste client.
Le stockage temporaire de la réponse permet de palier à une connectivité faible ou limitée du poste client ou d'un serveur détenteur de la ressource ou des données demandées.
Différents procédés et dispositifs de délivrance asynchrone de données sont connus dans l'état de la technique.
Ainsi, le document US-6070184 décrit un service de délivrance asynchrone de données pour un navigateur Web installé dans un appareil 30 mobile tel qu'un assistant PDA ou un téléphone GSM.
Le navigateur Web client de l'appareil mobile se connecte temporairement ou par intermittence à un serveur dédié sur le réseau Internet. Le serveur dédié a pour fonction de relayer une commande reçue de l'appareil mobile vers un serveur distant sur le réseau Internet, de recevoir et stocker la réponse du serveur distant et de prévenir ensuite le navigateur Web client de la disponibilité de la réponse.
2863127 2 Le développement ces dernières années des réseaux et systèmes distribués de type "pair-à-pair" ("peer-to-peer" ou P2P en anglais) a favorisé l'émergence de services de délivrance asynchrone, notamment pour les images numériques.
En effet, dans les réseaux et systèmes P2P, les postes clients et les serveurs se connectent ou se déconnectent périodiquement sur le réseau. La disponibilité directe des données sur le réseau est très aléatoire. Le stockage temporaire des images demandées et leur délivrance en temps différé constituent une solution technique adaptée à la technologie P2P.
Il est ainsi connu des inventeurs un système de partage d'images numériques multi-résolutions de type P2P dans lequel des images originales de haute résolution restent stockées dans des serveurs locaux des utilisateurs (machines clientes) du système. Des versions de basse résolution des images sont elles stockées dans un serveur central du système et sont directement disponibles pour les utilisateurs. Une certaine qualité de service est obtenue par la disponibilité dans le serveur central des versions de basse résolution des images. Toutefois, un problème de disponibilité persiste pour les images originales, surtout lorsque la connectivité des serveurs locaux possédant ces images originales est fluctuante ou que le niveau de réplication des images originales est faible.
Afin de résoudre ce problème de disponibilité des images originales de haute résolution, il a été proposé d'inclure un serveur dédié pour les images originales dans le système de partage d'images ci-dessus. Les images originales sont téléchargées en temps différé dans le serveur dédié depuis les machines clientes détentrices des images. Le serveur dédié avertit ensuite les utilisateurs demandeurs de la disponibilité des images originales de haute résolution.
Bien que les procédé et dispositif de délivrance asynchrone de données numériques de la technique antérieure décrits ci-dessus ont apportés des solutions techniques satisfaisantes à l'époque de leur conception, ces procédé et dispositif méritent aujourd'hui d'être améliorés.
Ainsi, un point sur lequel la technique antérieure demande à être améliorée est la manière dont les réponses aux demandes des utilisateurs sont fournies à ces derniers.
En effet, les réponses sont fournies brutes d'information aux utilisateurs et ceux-ci éprouvent une certaine difficulté à associer les réponses reçues à des demandes parfois effectuées bien avant dans le temps. Par 2863127 3 exemple, les machines des utilisateurs peuvent être dans des états de fonctionnement très différents lors de la réception des réponses, par rapport aux états de celles-ci lors de la formulation des demandes correspondantes.
Une autre amélioration souhaitable de la technique antérieure se situe au niveau du traitement qui est réservé à des demandes successives en provenance d'un même utilisateur.
Lorsque aucun traitement spécifique n'est prévu, chacune des demandes est traitée indépendamment des autres, et l'utilisateur reçoit autant de notifications de réponse que de demandes formulées. Ainsi, par exemple, si l'utilisateur effectue par erreur deux fois la même demande, il recevra deux notifications de réponse alors qu'une seule suffirait. Outre le manque de confort pour l'utilisateur, ces notifications multiples génèrent un trafic réseau supplémentaire qu'il serait souhaitable de réduire à un minimum.
Le service de délivrance asynchrone selon US-6070184 offre bien une possibilité de chaînage ou regroupement des réponses selon des souhaits préalables exprimés par l'utilisateur, mais cette solution n'est pas satisfaisante dans tous les cas. En effet, elle demande une intervention volontaire de l'utilisateur. De plus, le regroupement effectué est statique, aucun changement n'est possible sans une nouvelle intervention de l'utilisateur.
La présente invention a essentiellement pour objet d'apporter à la technique antérieure les améliorations indiquées plus haut et offre les avantages succinctement exposés dans les pages suivantes.
La présente invention vise en premier lieu à fournir un procédé de délivrance asynchrone de données numériques mis en oeuvre dans au moins un système serveur et au moins un système client reliés à travers un réseau de télécommunications, le système client étant susceptible de recevoir en temps différé des données numériques demandées auprès du système serveur, caractérisé en ce qu'il comprend des étapes de: - association à une demande de données émanant du système client d'une information de contexte représentative d'un premier état d'au moins une partie du système client demandeur lors de l'émission de la demande de données; - recherche, à partir de la demande, de certaines au moins des données demandées dans au moins un des systèmes reliés au réseau de télécommunications; et délivrance au système client demandeur d'une réponse incorporant l'information de contexte, le système client demandeur étant apte à 2863127 4 extraire l'information de contexte et à réagir à celle-ci pour se mettre au moins en partie dans un second état analogue au premier état.
Corrélativement, l'invention concerne aussi un dispositif de délivrance asynchrone de données numériques incorporé de manière répartie dans au moins un système serveur et au moins un système client reliés à travers un réseau de télécommunications, le système client étant susceptible de recevoir en temps différé des données numériques demandées auprès du système serveur, caractérisé en ce qu'il comprend: - des moyens d'association, incorporés dans le au moins un système client, pour associer à une demande de données émanant d'un système client demandeur une information de contexte représentative d'un premier état d'au moins une partie du système client demandeur lors de l'émission de la demande de données; - des moyens de recherche, incorporés dans le système serveur, pour rechercher, à partir de la demande, certaines au moins des données demandées dans au moins un des systèmes reliés au réseau de télécommunications; et - des moyens de délivrance, incorporés dans le système serveur, pour délivrer au système client demandeur une réponse incorporant l'information de contexte, le système client demandeur étant apte à extraire l'information de contexte et à réagir à celle-ci pour se mettre au moins en partie dans un second état analogue au premier état.
Selon un autre aspect, la présente invention vise aussi à fournir un procédé de délivrance asynchrone de données numériques mis en oeuvre dans un système serveur apte à coopérer avec au moins un système client relié au système serveur à travers un réseau de télécommunications, le système client étant susceptible de recevoir en temps différé des données numériques demandées auprès du système serveur, caractérisé en ce qu'il comprend des étapes de: - réception d'une demande de données émanant du système client et comportant une information de contexte représentative d'un premier état d'au moins une partie du système client demandeur lors de l'émission de la demande de données; - recherche, à partir de la demande, de certaines au moins des 35 données demandées dans au moins un des systèmes reliés au réseau de télécommunications; et 2863127 5 délivrance au système client demandeur d'une réponse incorporant l'information de contexte.
Corrélativement, l'invention concerne aussi un dispositif de traitement d'information apte à fonctionner comme un système serveur capable de coopérer avec au moins un système client relié au système serveur à travers un réseau de télécommunications, le système client étant susceptible de recevoir en temps différé des données numériques demandées auprès du système serveur, caractérisé en ce qu'il comprend: - des moyens de réception pour recevoir une demande de données émanant du système client et comportant une information de contexte représentative d'un premier état d'au moins une partie du système client demandeur lors de l'émission de la demande de données; - des moyens de recherche pour rechercher, à partir de la demande, certaines au moins des données demandées dans au moins un des 15 systèmes reliés au réseau de télécommunications; et - des moyens de délivrance pour délivrer au système client demandeur une réponse incorporant l'information de contexte.
Selon encore un autre aspect, la présente invention vise aussi à fournir un procédé de demande / réception de données numériques mis en oeuvre dans un système client relié à au moins un système serveur à travers un réseau de télécommunications, le système client étant susceptible de demander des données numériques au système serveur et de recevoir en temps différé les données numériques demandées après une recherche de celles-ci effectuée par le système serveur, caractérisé en ce qu'il comprend des étapes de: à l'émission de la demande de données: - génération d'une information de contexte représentative d'un premier état d'au moins une partie du système client lors de l'émission de la demande de données et association de l'information de contexte à la demande de données émise; et à la réception d'une réponse incorporant l'information de contexte en provenance du système serveur: - extraction de l'information de contexte de la réponse, et - gestion de contexte en mettant au moins une partie du système client dans un second état analogue au premier état en réaction à l'information de contexte extraite.
2863127 6 Corrélativement, l'invention concerne aussi un dispositif de traitement d'information apte à fonctionner comme un système client relié à au moins un système serveur à travers un réseau de télécommunications, le système client étant susceptible de demander des données numériques au système serveur et de recevoir en temps différé les données numériques demandées après une recherche de celles-ci effectuée par le système serveur, caractérisé en ce qu'il comprend du côté émission: - des moyens de génération pour générer, à l'émission de la demande de données, une information de contexte représentative d'un premier état d'au moins une partie du système client lors de l'émission de la demande de données, et des moyens d'association pour associer l'information de contexte à la demande de données émise; et du côté réception: - des moyens d'extraction pour extraire l'information de contexte d'une réponse reçue en provenance du système serveur, et - des moyens de gestion de contexte pour mettre au moins une partie du système client dans un second état analogue au premier état en réaction à l'information de contexte extraite.
L'invention apporte ainsi une première amélioration sensible à la technique antérieure en offrant une gestion de contexte permettant à l'utilisateur d'associer les réponses reçues à des demandes parfois effectuées bien avant dans le temps.
En effet, lors du traitement de la réponse par le système client, celuici passe, au moins pour partie, dans un état analogue à celui qui prévalait lors de la formulation de la demande. Il est ainsi possible de créer pour l'utilisateur un contexte analogue au contexte qui existait lors de la demande. Cette homogénéité des contextes non seulement facilite, dans l'esprit de l'utilisateur, une association de la réponse reçue à une demande formulée, mais autorise également la mise en place d'outils et de ressources adéquats, éventuellement utiles pour l'exploitation de la réponse.
Le procédé selon l'invention tel que défini plus haut présente l'avantage de pouvoir être mis en oeuvre dans n'importe quel type de réseau, aussi bien de type client-serveur que P2P. Le procédé selon l'invention est compatible avec une infrastructure de communication de type filaire ou sans fil, supportant un réseau Internet ou local privé.
Selon une caractéristique préférée, la recherche est précédée par un regroupement de demandes de données successives émanant d'un même système client dans un même premier état en une seule demande de données à partir de laquelle est exécutée la recherche. De plus, la délivrance de la réponse peut être précédée par un regroupement de plusieurs réponses à une ou plusieurs demandes de données émanant d'un même système client dans un même premier état en une seule réponse à délivrer au même système client.
De préférence, le regroupement de demandes de données 10 successives comprend aussi une fonction de suppression d'une redondance éventuelle dans les demandes de données successives.
L'invention apporte ainsi une seconde amélioration sensible à la technique antérieure en autorisant une gestion optimale des demandes de données successives et des réponses successives au niveau du serveur central.
Le confort de l'utilisateur est accrû car il ne reçoit qu'une seule notification pour plusieurs demandes, et corrélativement, le trafic réseau est réduit.
Selon encore une autre caractéristique, la recherche des données demandées est effectuée dans une base de données comprise dans le système serveur. La recherche des données demandées peut aussi être effectuée au moins dans un serveur local de fichiers compris dans un système client autre que le système client demandeur.
Selon un mode particulier de réalisation, la délivrance des données comprend aussi l'envoi de la réponse ou d'une partie de celle-ci sous la forme d'une notification indiquant une disponibilité des données demandées. De préférence, la notification comporte une partie ou toutes les données demandées. La notification peut aussi comporter au moins un lien vers un emplacement où les données demandées sont disponibles ou partiellement disponibles et/ou au moins un lien vers un ensemble d'ordre supérieur dont font partie les données demandées.
La délivrance des données peut aussi comprendre un chargement dans le système client demandeur des données demandées ou d'une partie de cellesci à partir d'un ou plusieurs emplacements dans le système serveur et/ou un système client.
Ce mode particulier de réalisation succinctement décrit ci-dessus est particulièrement adapté à des données numériques sous la forme d'images 2863127 8 multi-résolutions. Les données transmises dans la notification comprennent alors, par exemple, des versions de basse résolution des images, dites imagettes , ou thumbnails en anglais.
L'invention offre des modes de réalisation parfaitement adaptés au traitement des données organisées en des ensembles d'ordre supérieur tels que des albums, des collections d'images et/ou des catalogues.
Dans un tel cas, les premier et second états comprennent par exemple au moins au moins un affichage d'écran et/ou l'exécution d'au moins un logiciel informatique associés aux ensembles d'ordre supérieur.
Le logiciel informatique peut comprendre une interface logicielle de visualisation sous la forme par exemple d'un logiciel dédié ou d'un navigateur de type Internet. Le logiciel dédié est par exemple un logiciel de gestion de collections d'images.
Selon d'autres aspects, l'invention concerne aussi un système de télécommunications, ainsi qu'un moyen de stockage d'information et un programme d'ordinateur pour une mise en oeuvre des procédés de l'invention décrits brièvement ci-dessus.
L'invention offre aussi des modes de réalisation adaptés au traitement de données de type multi-résolutions comprenant notamment des données d'image et/ou des données vidéo et/ou des données audio et/ou des données de texte.
D'autres aspects et avantages de la présente invention apparaîtront plus clairement à la lecture de la description de modes particuliers de réalisation qui va suivre, cette description étant donnée uniquement à titre d'exemple non limitatif et étant faite en référence aux dessins annexés, dans lesquels la Fig.1 montre la structure générale d'un mode particulier de réalisation du système de télécommunications selon l'invention; la Fig.2 montre une configuration matérielle particulière d'un dispositif de traitement d'information selon l'invention apte à fonctionner comme système serveur dans le système de télécommunications de la Fig.1; la Fig.3A représente une structure de fichier d'une collection d'images à partir de laquelle sont émises des demandes asynchrones pour des images de haute résolution dans le système de télécommunications de la Fig.1; la Fig.3B montre un exemple d'affichage sur écran de la collection d'images de la Fig.3A; 2863127 9 la Fig.4 est un algorithme montrant les principales étapes du procédé de demande / réception de données numériques selon l'invention mis en oeuvre dans un système client relié au système de télécommunications de la Fig.1; la Fig. 5 montre un exemple de structure d'une base de données installée dans le système serveur du système de télécommunications de la Fig.1 pour la mise en oeuvre dans ce système serveur du procédé de délivrance asynchrone de données numériques selon l'invention; la Fig.6 est un algorithme montrant des premières étapes de traitement du procédé de délivrance asynchrone de données numériques selon l'invention mis en oeuvre dans le système serveur, d'une étape de réception d'une demande asynchrone à une étape de recherche d'une image demandée; la Fig.7 est un algorithme montrant d'autres étapes de traitement du procédé de délivrance asynchrone de données numériques selon l'invention mis en oeuvre dans le système serveur, d'une étape de connexion d'un système client à une étape d'émission d'une notification de réponse au système client; et la Fig.8 montre un exemple d'affichage sur écran d'une notification de réponse à un système client.
Les modes particuliers de réalisation des procédés et dispositifs de l'invention présentés ci-dessous sont décrits dans le contexte général d'un système de télécommunications selon l'invention conçu plus particulièrement pour le partage d'images numériques multi-résolutions entre un groupe d'utilisateurs. Bien entendu, les différentes caractéristiques de l'invention présentées dans le préambule ci-dessus sont indépendantes du type des données numériques et s'appliquent sans restriction aux modes particuliers de réalisation décrits ci-dessous.
Dans le système de télécommunications de l'invention montré de manière globale à la Fig.1, on notera de prime abord que: - les données numériques demandées et délivrées éventuellement de manière différée sont constituées par des images numériques multi-résolutions; - les images numériques sont regroupées dans des collections qui forment des ensembles d'ordre supérieur; et 2863127 10 - l'information de contexte représentative de l'état d'au moins une partie d'un système client demandant une image numérique comprend une information représentative de la collection à partir de laquelle le système client demande l'image numérique.
Afin de ne pas surcharger inutilement la description de l'invention, il n'est considéré ici que des images numériques à deux résolutions.
Dans le même esprit, il est également considéré ici qu'un système client est attribué à un seul utilisateur. Bien entendu, l'invention n'est pas limitée à ce cas de figure simple rendant plus aisée sa description et est parfaitement applicable dans un contexte multi-utilisateurs.
L'image numérique comprend donc ici une version de basse résolution et une version de haute résolution.
La version de basse résolution de l'image numérique est appelée imagette ( thumbnail en anglais), le terme imagette étant celui employé dans la suite de la description. La version de haute résolution de l'image numérique est l'image numérique originale et est appelée ici image de haute résolution ou image HR.
Les images de haute résolution sont dans ce système de télécommunications de l'invention celles qui font essentiellement l'objet d'une délivrance asynchrone. II est en effet considéré que le système de télécommunications est équipé d'un système serveur dans lequel sont stockées les imagettes des différentes collections partagées. Les imagettes sont donc directement disponibles.
Bien entendu, comme cela apparaîtra clairement à l'homme du métier, la présente invention ne dépend pas du nombre de résolutions des images numériques et peut traiter des images numériques ayant un nombre quelconque de résolutions.
De plus, les termes image multi-résolutions doivent être interprétés de manière large, car ils se réfèrent ici par exemple aussi bien à des images numériques ayant un format multi-résolutions tel que le format JPEG2000, qu'à des images numériques ayant un format mono-résolution tel que le format JPEG.
Dans le cas du format mono-résolution tel que JPEG, la multirésolutions est supportée soit par la construction de fichiers indépendants correspondant à des sous-résolutions différentes obtenues à partir d'un même fichier d'image de haute résolution, soit par un format de fichier tel que 2863127 11 FlashPix (marque déposée de la société Kodak) qui stocke plusieurs résolutions dans le même fichier.
En référence à la Fig.1, le système de télécommunications selon ce mode particulier de réalisation, désigné globalement par le repère 1, comprend un réseau de télécommunications 100, N systèmes clients 1101 à 110N, N étant un entier au moins égal à 1, un système serveur 120, et un dispositif de délivrance asynchrone de données numériques selon l'invention qui est incorporé de manière répartie dans les N systèmes clients 1101 à 110N et le système serveur 120.
Le réseau de télécommunications 100 est par exemple le réseau Internet ou un réseau local d'entreprise (LAN). Le réseau 100 relie entre eux les systèmes clients 1101 à 110N et le système serveur 120. Le réseau 100 est ici un réseau capable de supporter des modes de connexion de types pairàpair et/ou client-serveur.
Les connexions client-serveur permettent aux systèmes clients d'accéder périodiquement au système serveur 120.
Les connexions pair-à-pair permettent aux systèmes clients 110 d'échanger directement entre eux des images numériques, et ceci indépendamment du système serveur 120.
Les systèmes clients 110 sont bâtis autour d'un dispositif ou machine de traitement d'information 111, typiquement un micro-ordinateur personnel, dans lequel est installé un logiciel 112 implémentant les algorithmes nécessaires à la mise en oeuvre des procédés selon l'invention.
Les systèmes clients 110 sont connectés au réseau 100 au 25 moyen de différentes techniques connues, telles que par exemple une liaison DSL, un modem 56Kbits/s ou un modem câble.
Le logiciel 112 implémente du côté système client 110 les algorithmes nécessaires à la mise en oeuvre des procédés selon l'invention.
Le logiciel 112 peut se présenter sous différents aspects selon les contraintes de conception imposées au système de télécommunications 1.
Ainsi, le logiciel 112 peut prendre la forme d'un logiciel dédié ou, plus simplement, sa fonction peut être remplie par un navigateur Internet standard auquel est éventuellement associé un module d'extension, désigné plug-in en anglais.
De préférence, le logiciel 112 est téléchargé dans un système client 110 depuis le système serveur 120 et est installé ensuite dans le système client 110.
2863127 12 Comme montré pour le système client 110n, qui est un système client 110 quelconque du système 1, lorsqu'un mode de connexion pair-àpair est souhaité, le logiciel 112,, peut comprendre, outre une interface de visualisation d'image 113,, un serveur local de fichiers 114, fonctionnant de manière couplée avec l'interface 113n.
Le serveur local de fichiers 114n est de type classique et ne sera pas décrit ici.
L'interface de visualisation d'image 113n est par exemple supportée par un logiciel dédié manipulant des collections d'images, des 10 albums, des catalogues et autres analogues.
Selon un mode de réalisation particulier bien adapté à des connexions de type pair-à-pair, le logiciel 112 comporte deux processus distincts aptes à communiquer entre eux. Un premier processus manipule l'interface 113 et communique avec le serveur local de fichiers 114. Un second processus indépendant implémente le serveur local de fichiers 114 qui est exécuté dès la mise en route du système client 110.
Selon un mode de réalisation plus simple, montré à titre d'exemple pour le système client 110N mais qui peut être implanté dans n'importe lequel des systèmes clients 110, la fonction de l'interface de visualisation d'image est assurée par exemple par un navigateur Internet standard 113N auquel est éventuellement associé un module d'extension.
Ainsi, lorsqu'un mode de connexion client-serveur strict est souhaité, le logiciel 112 peut comporter au minimum un navigateur Internet remplissant la fonction d'interface de visualisation d'image 113 et qui se connecte au système serveur 120 afin de permettre une visualisation des images numériques partagées sur le réseau.
Selon un mode de connexion pair-à-pair, le logiciel 112, disposant au minimum d'un navigateur Internet, peut au préalable se connecter au système serveur 120 et ainsi être redirigé vers au moins un système client 110, chacun de ces systèmes ou leur ensemble permettant de proposer toute ou partie du contenu de la visualisation.
Le système serveur 120 est de préférence bâti autour d'un dispositif ou machine de traitement d'information, typiquement un micro-ordinateur personnel, dans lequel est installé un logiciel implémentant les algorithmes nécessaires à la mise en oeuvre des procédés selon l'invention.
Le système serveur 120 est adapté à communiquer directement avec les systèmes clients 110. 2863127 13 Comme montré à la Fig.1, dans ce mode particulier de
réalisation, le système serveur 120 comprend notamment un dispositif de stockage de données volatiles 121 et une base de données 122.
Le dispositif de stockage de données volatiles 121, également appelé mémoire cache 121 dans la suite de la description, est apte à stocker des données à durée de vie longue telles que des images, mais aussi des données plus volatiles telles que des listes d'adresses, des listes de demandes asynchrones, etc., comme cela apparaîtra plus clairement par la suite dans la description.
La base de données 122 autorise une gestion aisée et efficace des données volatiles stockées dans le dispositif de stockage de données volatiles 121. On notera cependant que la base de données 122 n'est pas un élément indispensable dans l'invention et qu'elle peut ne pas être présente dans certains modes de réalisation de l'invention.
Selon une variante de réalisation, le système serveur 120 comprend plusieurs serveurs couplés entre eux et accessibles à partir d'une seule adresse réseau.
En référence à la Fig.2, un dispositif ou machine de traitement d'information 200 apte à fonctionner en tant que système serveur 120 dans le système de télécommunications 1 selon l'invention est maintenant décrit essentiellement dans sa configuration matérielle.
Le dispositif de traitement d'information 200 est typiquement un microordinateur ou une station de travail.
Le dispositif de traitement d'information 200 est équipé de 25 manière à assurer de préférence une connexion permanente au réseau 100, et cela afin d'offrir un service continu.
Dans ce mode particulier de réalisation, le dispositif de traitement d'information 200 est totalement dédié à remplir la fonction du système serveur 120 et exécute un ou plusieurs programmes informatiques PROG qui autorisent la mise en oeuvre des procédés selon l'invention du côté système serveur.
Selon une variante, les programmes PROG ne sont pas installés dans le dispositif 200 du système serveur 120, mais sont installés dans le dispositif de traitement d'information 111 d'un système client 110 qui les exécute en tâche de fond. Le dispositif de traitement d'information 111 est alors reconnu comme fournisseur de service par un serveur central du système de télécommunications 1 qui diffuse cette information vers les autres systèmes clients 110.
2863127 14 Comme montré à la Fig.2, le dispositif de traitement d'information 200 comporte une unité centrale de traitement (CPU) 201 telle qu'un microprocesseur, une mémoire non volatile telle qu'une mémoire morte ROM 202, une mémoire vive RAM 203, des moyens d'interface homme-machine tels qu'un écran 204, un clavier 205 et une souris 206, des moyens de stockage d'information tels qu'un disque dur 207 et un lecteur de disquette 208, une interface de communication 209 et un bus de communication interne 210.
Le dispositif de traitement d'information 200 est aussi équipé de la base de données 122, qui sera décrite de manière détaillée par la suite en référence à la Fig. 5.
La mémoire ROM 202 comprend éventuellement, en partie ou totalité, les programmes PROG.
La mémoire RAM 203 contient des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes PROG. La mémoire RAM 203 comprend aussi éventuellement une zone de stockage temporaire correspondant à la mémoire cache 121 pour stocker des données volatiles échangées sur le réseau 100 et transitant par le dispositif de traitement d'information 200.
Le disque dur 207 est optionnel et contient éventuellement une partie ou la totalité des programmes PROG, ainsi que la mémoire cache 121.
Le lecteur 208 est adapté à recevoir une disquette 211 et à y lire ou à y écrire des données traitées ou à traiter conformément aux procédés selon l'invention.
L'interface de communication 209 est reliée au réseau de télécommunications 100 et est apte à transmettre et à recevoir des données.
Le bus de communication 210 permet une communication et une interopérabilité entre les différents éléments inclus dans le dispositif de traitement d'information 200 ou reliés à celui-ci. La représentation du bus 210 montrée à la Fig.2 n'est pas limitative. En particulier, l'unité centrale de traitement 201 est susceptible de communiquer des instructions à tout élément du dispositif de traitement d'information 200, directement ou par l'intermédiaire d'un autre élément du dispositif 200.
Le code exécutable des programmes PROG est de préférence stocké dans le disque dur 207 et/ou dans la mémoire ROM 202.
La disquette 211 peut contenir des données ainsi que le code exécutable des programmes PROG qui, une fois lu par le dispositif 200, sera stocké dans le disque dur 207.
2863127 15 De plus, le code exécutable des programmes PROG pourra être reçu par l'intermédiaire du réseau de télécommunications 100, via l'interface de communication 209, pour être stocké dans le disque dur 207.
La disquette 211 peut être remplacée par tout support 5 d'information tel que, par exemple, un disque compact (CD-ROM) ou une carte mémoire.
De manière générale, tout moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non dans le dispositif 200, éventuellement amovible, est adapté à mémoriser, en partie ou totalité, les programmes PROG. De plus, les programmes PROG peuvent être chargés en partie ou totalité dans un des moyens de stockage d'information du dispositif 200 avant d'être exécutés.
L'unité centrale 201 commande et dirige l'exécution des instructions ou portions de code des programmes PROG, les instructions étant stockées dans le disque dur 207 et/ou la mémoire ROM 202 et/ou dans les autres moyens de stockage d'information indiqués ci-dessus.
Lors de la mise sous tension, les programmes PROG stockés dans une mémoire non volatile, telle que le disque dur 207 ou la mémoire ROM 202, sont transférés en partie ou totalité dans la mémoire RAM 203 qui contiendra alors le code exécutable transféré des programmes PROG, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre des procédés selon l'invention.
On notera également que le dispositif 200 peut prendre la forme d'un appareil programmé. Cet appareil programmé contient alors le code exécutable des programmes PROG par exemple sous une forme figée dans un circuit intégré à application spécifique (ASIC).
En référence aux Figs.3A et 3B, il est décrit ci-dessous la structure générale d'un fichier supportant une collection d'images numériques COL à partir de laquelle il est possible à un utilisateur d'émettre une demande asynchrone pour une image HR, ainsi qu'un exemple d'affichage d'une page d'en-tête de la collection COL dans un système client 110.
De manière générale, une collection COL peut être définie comme un ensemble de contenus d'image et de méta-données. Par extension, une collection COL peut contenir d'autres collections qui seront alors appelées sous-collections.
2863127 16 Comme indiqué précédemment, la collection COL peut être manipulée par un logiciel dédié, ou plus simplement, elle peut être supportée par une ou plusieurs pages Web ou HTML.
Lorsqu'une page HTML est employée pour la collection COL, cette page contient des méta-données nécessaires à l'affichage de la page et des liens notamment vers des images auxquelles sont attribués des identifiants uniques d'image IUID. Les identifiants uniques d'image IUID remplacent dans ce cas les adresses Web classiques.
Comme montré à la Fig.3A, un fichier de collection comprend une portion d'en-tête HD et une portion de corps BD.
La portion d'en-tête HD contient des méta-données comprenant notamment un identifiant unique de collection CUID et un titre de collection TLC. D'autres méta-données MDs peuvent être incorporées dans la portion d'entête HD et sont relatives par exemple à la présentation de la collection, l'auteur de la collection, la date de création de la collection, etc. Les méta-données de présentation décrivent par exemple la place des titres, des commentaires, des balises ( tags en anglais), mais aussi, les images de fond, les couleurs, les cadres des images, les fontes des textes, etc. Les méta-données de présentation peuvent aussi plus simplement être constituées d'un identifiant de modèle de présentation MPID. L'identifiant MPID correspond alors à un fichier de modèle de présentation particulier dans lequel sont définis les différents éléments constituant la présentation de la collection COL.
Lorsque la collection COL est supportée par des pages HTML, un fichier de présentation de type CSS tel que défini par l'organisme normatif W3C peut être associé à la collection COL. Le navigateur Internet du système client 110 affiche alors une page HTML de la collection COL en fonction des éléments définis dans le fichier CSS associé. L'utilisateur du système client 110 a alors la possibilité de modifier aisément la présentation d'origine de la collection COL en sélectionnant un fichier CSS différent de celui d'origine pour l'affichage de la collection COL.
Comme montré également à la Fig.3A, la portion de corps BD comporte une liste LT indiquant les identifiants IUID des images faisant partie de la collection COL.
La liste LT peut aussi contenir des identifiants CUID différents du CUID de la collection COL, qui représentent des collections (ou souscollections) accessibles à partir de la collection COL courante.
2863127 17 On notera que l'imagette et l'image HR ont toutes les deux le même identifiant IUID dans ce mode de réalisation. Afin de déterminer de manière précise un objet, à savoir, l'imagette ou l'image HR, l'identifiant IUID est associé à un "type" de donnée.
Le type de données est généralement implicite selon les demandes envoyées sur le réseau. Par exemple, les imagettes sont ici requises par exemple pour la visualisation de la page d'en-tête de la collection COL. C'est par contre l'image HR, ou une image de résolution intermédiaire dans un mode de réalisation différent de l'invention, qui est demandée pour une visualisation sur l'écran d'un système client 110.
Un exemple d'affichage d'écran SD d'une page d'en-tête d'une collection COL comportant cinq images est montré à la Fig. 3B.
Il est considéré ici que l'affichage d'écran SD est celui correspondant à une page HTML visualisée au moyen d'un navigateur Internet installé dans un système client 110. Le navigateur Internet est alors par exemple connecté au système serveur 120 afin de télécharger la page HTML et/ou les imagettes à afficher. Les identifiants CUID et IUID sont utilisés pour le téléchargement. Dans le cas où la page HTML et les imagettes sont disponibles localement, le chargement par le navigateur Internet interviendra à partir du serveur local de fichiers 114.
Dans le cas où toutes ou certaines parties des pages HTML et/ou imagettes ne sont pas disponibles localement, celles-ci peuvent être chargées depuis plusieurs systèmes clients 110, voire le système serveur 120.
Dans l'exemple de la Fig.3B, l'affichage d'écran SD comprend une zone de titre 300, une zone d'affichage complémentaire 301 et cinq zones d'affichage d'imagette 302 à 306.
La méta-donnée de titre TLC est affichée dans la zone 300. Des métadonnées indiquant l'auteur de la collection et la date de création de celle- ci sont par exemple affichées dans la zone 301. Les zones 302 à 306 affichent les imagettes de l'ensemble des images numériques de la liste d'images LT.
Les zones 302 à 306 contiennent des liens URL, LHR1 à LHR5, vers les images HR.
Lorsque l'utilisateur sélectionne une imagette, par exemple en cliquant sur celle-ci, le lien LHR est activé et une requête est dirigée vers le serveur local de fichiers 114 ou le système serveur 120 selon le cas. Si le serveur local de fichiers 114 ou le système serveur 120 détecte que l'image HR 2863127 18 n'est pas disponible sur le réseau, le lien LHR est interprété comme une demande asynchrone AD et son exécution est redirigée vers une zone d'enregistrement sur le système serveur 120. La demande asynchrone AD se présente alors par exemple sous la forme: http://www. centralhost.com/gethighres?iuid=lUlD&cuid=CUID&uui d=UUID où: iuid est un mot clé permettant d'interpréter la donnée IUID' comme représentant l'identifiant unique de l'image partagée; cuid est un mot clé permettant d'interpréter la donnée 'CUID' comme représentant l'identifiant unique de la collection partagée; uuid est un mot clé permettant d'interpréter la donnée 'UUID' comme représentant l'identifiant unique du système client; centralhost.com est l'adresse du système serveur; et gethighres est le mot-clé pour la commande d'acquisition de l'image HR.
L'identifiant CUID de la collection partagée COL à partir de laquelle est émise la demande asynchrone AD est ici l'information de contexte CINF qui conformément à l'invention est associée à cette demande AD.
L'identifiant CUID est représentatif de la collection COL affichée sur l'écran du système client 110 lors de l'émission de la demande asynchrone AD. L'identifiant CUID représente donc un état de l'écran lors de l'émission de la demande asynchrone AD, ou d'une partie de celui-ci lorsque la collection COL est affichée par exemple dans une fenêtre réduite. Plus généralement, l'identifiant CUID représente un état d'au moins une partie du système client, à savoir ici, l'affichage d'écran, mais aussi l'exécution par l'unité centrale de traitement du dispositif de traitement d'information 111 du logiciel produisant un tel affichage d'écran.
Conformément à l'invention, d'autres éléments d'information peuvent bien entendu être introduits dans la demande asynchrone AD en tant qu'information de contexte CINF afin de mieux représenter un état du système client 110 ou d'une partie de celui-ci lors de l'émission de la demande asynchrone AD. Ainsi, par exemple, dans certains modes de réalisation de l'invention, l'identifiant de fichier de présentation MPID est par exemple associé aux identifiants IUID, CUID, UUID en tant qu'information de contexte CINF supplémentaire.
2863127 19 Lorsque la demande asynchrone AD n'est pas émise depuis un navigateur Internet, il est possible de faire appel à des protocoles de communication connus, tel que SOAP par exemple, entre le serveur local de fichiers 114 et le système serveur 120, afin de relayer la demande asynchrone AD vers le système serveur 120.
En référence à la Fig.4, il est maintenant décrit un algorithme général montrant des grandes étapes fonctionnelles du procédé de demande I réception de données numériques selon l'invention mis en oeuvre dans un système client 110.
Les étapes sont ici volontairement séparées temporellement les unes des autres de manière à faire apparaître clairement les différentes fonctions réalisées par le procédé de demande / réception de données numériques selon l'invention.
Dans une réalisation pratique, comme celle présentée ci-dessus 15 dans le domaine HTML et dont la description se poursuivra avec les Figs.5 à 8, certaines étapes sont éventuellement imbriquées.
Ainsi, par exemple dans la réalisation pratique mentionnée ci-dessus dans le domaine HTML, l'information de contexte CINF=CUID est associée à une demande d'une image HR dès la formulation de la demande, avant qu'il soit certain que la demande sera traitée comme asynchrone.
De manière différente, les étapes 404 et 405 décrites ci-dessous de l'algorithme de la Fig.4 correspondent à une association postérieure de l'information de contexte CINF à la demande. L'information de contexte CINF est ici associée à la demande une fois déterminé le fait que la demande sera effectivement traitée comme une demande asynchrone.
Dans une partie d'émission de l'algorithme de la Fig.4, il est prévu des étapes 401 à 405 pour gérer la génération et l'émission d'une demande asynchrone AD dans un système client 110.
A l'étape 401, une demande pour une image HR est effectuée 30 dans le système client 110 par un utilisateur en cliquant sur l'une des imagettes affichées dans la page d'en-tête d'une collection COL.
A l'étape 402, le logiciel 112 du système serveur 110 détermine si l'image HR demandée est directement disponible ou pas.
Dans l'affirmative, l'image HR est disponible localement dans le serveur local de fichiers 114 du système client 110, dans le système serveur 120 ou dans un autre système client 110 pair connecté au système de télécommunications 1. L'étape 403 est alors effectuée afin d'afficher l'image 2863127 20 HR demandée lorsque celle-ci est disponible localement dans le serveur 114, ou de la délivrer par téléchargement à partir du système serveur 120 ou d'un système client 110 pair. Dans le cas cidessus, la délivrance de l'image HR intervient rapidement et la gestion d'une information de contexte conformément à l'invention présente moins d'intérêt.
Dans le cas inverse, c'est-à-dire, lorsque l'image HR demandée n'est pas disponible, la demande effectuée à l'étape 401 est gérée comme étant une demande asynchrone AD par les étapes suivantes 404 et 405.
L'étape 404 génère l'information de contexte CINF représentative d'un état de demande du système client 110 lors de la demande de l'image HR à l'étape 401, c'est-à-dire, dans ce mode particulier de réalisation, l'affichage de la collection COL sur l'écran du système client 110.
L'étape 405 associe l'information de contexte CINF générée à la demande de l'étape 401 afin de produire une demande asynchrone AD. La demande AD est ensuite émise vers le système serveur 120 à travers le réseau 100.
Dans une partie de réception de l'algorithme de la Fig.4, il est prévu des étapes 406 à 408 pour recevoir une réponse à une demande asynchrone AD dans le système client 110 et gérer un contexte de consultation de la réponse.
L'étape 406 est une étape d'attente d'une réponse, en provenance du système serveur 120, à une demande asynchrone AD émise.
Cette étape est une étape non active, dans le sens où le système client 110 n'a plus à se préoccuper de la suite des opérations.
Le système client 110 sera averti de la reprise de la procédure lors de la réception d'une notification comportant la réponse telle que décrite dans l'étape 709 de la Fig. 7.
Lorsqu'une réponse est reçue, laquelle conformément à l'invention comprend l'information de contexte CINF, l'étape 407 est exécutée pour extraire l'information de contexte CINF de la réponse reçue.
L'étape 408 utilise l'information de contexte CINF extraite à l'étape 407 pour gérer le contexte dans lequel la réponse reçue est consultée dans le système client 110.
Plus précisément, dans ce mode particulier de réalisation, l'information de contexte CINF apporte à l'étape 408 une connaissance de la collection COL à partir de laquelle la demande asynchrone AD correspondante a été émise, c'est-à-dire, de l'état du système client 110 à l'étape 401. Cette 2863127 21 connaissance permet au système client 110 de se placer dans un état de consultation de réponse analogue à son état lors de l'étape 401. En d'autres termes, le système client 110 présente alors un écran d'affichage de consultation de réponse qui rappelle à l'utilisateur par sa présentation la collection COL à partir de laquelle il a émis sa demande asynchrone AD. De préférence, un accès direct à cette collection COL est autorisé à partir de l'écran d'affichage de consultation de réponse.
En référence à la Fig.5, il est maintenant décrit une organisation structurelle particulière de la base de données 122 installée dans le système serveur 120.
Comme cela apparaîtra plus clairement dans la suite de la description, la base de données 122 participe, dans ce mode particulier de réalisation du système de télécommunications selon l'invention, à la mise en oeuvre du procédé de demande asynchrone de données numériques selon l'invention dans le système serveur 120. On notera que la base de données 122 n'est pas un composant indispensable dans la présente invention.
La base de données 122 comprend essentiellement une table de demande asynchrone 500, une table de client 501, une table de contenu 502, une table de collection 503 et une table de machine 504 entre lesquelles sont établies différentes relations 510 à 514.
La table de demande asynchrone 500 a essentiellement pour fonction de conserver, relativement à chaque demande asynchrone AD reçue par le système serveur 120, des éléments d'information nécessaires au traitement de la demande AD par le système serveur 120.
Un identifiant ADID est attribué par le système serveur 120 à chaque demande asynchrone AD reçue en provenance d'un système client 110.
Pour chaque demande asynchrone AD reçue, les éléments d'information suivants sont notamment conservés dans des champs correspondants de la table de demande asynchrone 500: l'identifiant IUID de l'image HR demandée, l'identifiant UUID du système client 110 demandeur, l'information de contexte CINF(CUID), la date DATE de la demande asynchrone AD et l'état STATUS de la demande asynchrone AD.
Afin de simplifier la description de cette organisation structurelle particulière de la base de données 122, il est considéré ici que l'information de contexte CINF se limite à l'identifiant CUID de la collection COL à partir de laquelle est effectuée la demande asynchrone AD.
Pour des raisons de commodité, les champs des tables 500 à 504 et leurs contenus sont désignés de la même manière dans la suite. Ainsi, par exemple, le champ DATE est le champ contenant l'élément d'information DATE.
Dans ce mode de réalisation, les champs DATE et STATUS peuvent être simplement des chaînes de caractères. Le champ DATE autorise notamment une vérification régulière des demandes asynchrones AD en attente et une re-validation éventuelle auprès du système client 110 demandeur. Le champ STATUS indique si la demande asynchrone AD correspondante est en attente de traitement, en cours de traitement, en cours de notification de réponse au système client 110 demandeur ou est traitée.
Les champs IUID, UUID et CUID de la table 500 constituent des références internes à la base de données 122 qui permettent de pointer très efficacement sur des éléments d'information des autres tables.
La table de client 501 a essentiellement pour fonction de conserver les paramètres des comptes des systèmes clients 110 sur le réseau. La table 501 est par exemple utilisée lors d'une connexion d'un système client 110 pour une authentification de celui-ci.
La table de contenu 502 gère localement les ressources telles que les images, les collections et les présentations ( stylesheets en anglais) disponibles sur le système serveur 110. Une entrée dans la table 502 se présente sous la forme: identifiant (ID), type (IMAGE, COLLECTION...), LOCALISATION dans la mémoire cache 121.
La relation 510 entre les tables 500 et 501 permet de connaître les demandes asynchrones AD en cours pour chaque système client 110. De plus, lorsque le traitement d'une demande asynchrone AD est achevé, les coordonnées de l'utilisateur, par exemple, son adresse de courrier électronique EMAIL, sont aisément localisées à l'aide des tables 500 et 501 et de la relation 510.
La table de collection 503 conserve les données des collections COL. Les données d'une collection COL sont celles décrites plus haut en référence à la Fig.3A, à savoir, l'identifiant CUID et le titre TLC de la collection COL ainsi que les identifiants IUID des images de la collection COL.
Selon une variante de réalisation, les données d'une collection COL ne sont pas stockées dans la base de données 122 mais sont conservées 2863127 23 dans la mémoire cache 121 sous la forme du fichier de collection décrit en référence à la Fig.3A. Les liens entre une collection COL et les images appartenant à cette collection COL ne pourront pas alors être retrouvés dans la base de données 122 mais directement à partir du fichier de collection correspondant.
La relation 512 permet de relier une entrée de la table 502, par exemple, l'entrée COLLECTION, à une entrée de la table 503. Au moyen de la relation 512, il est possible d'obtenir toutes les entrées IMAGE d'une collection COL. L'association entre les relations 511 et 512 sera employée par exemple pour obtenir la liste des images HR d'une collection COL pour lesquelles le système serveur 120 a transmis aux systèmes clients 110 des réponses aux demandes asynchrones AD de ceux-ci. L'intérêt de l'association ci-dessus des relations 511 et 512 apparaîtra plus clairement par la suite dans la partie de la description relative à la Fig. 7 (étape 707).
La table de machine 504 conserve les paramètres des systèmes clients 110 qui se sont connectés en mode pair-à-pair au système de télécommunications 1 par l'intermédiaire de leur serveur local de fichiers 114. Ces paramètres sont de manière non-limitative: un nom de la machine hôte NOM_HâTE, une adresse Internet IP ADRESSE IP, un port de communication PORT, une information de connexion EN_LIGNE de la machine, etc. Dans le mode pair-à-pair, le système serveur 120 est plus ou moins sollicité par les systèmes clients 110 selon le niveau de connaissance de celui-ci des données transitant sur le réseau.
Ainsi, selon un premier mode de réalisation, le système serveur 120 conserve en permanence la localisation de l'ensemble des données dans le système de télécommunications 1. Dans un tel cas, la relation 513 entre les tables 502 et 504 est utilisable à tout moment pour déterminer la localisation des images HR dans le système de télécommunications 1. Lorsqu'un système client 110 se déconnecte du système de télécommunications 1, les informations relatives au stockage des images dans le serveur local de fichiers 114 de ce système client 110 sont conservées et sont mises à jour lors de la prochaine reconnexion du système client 110 au système de télécommunications 1.
Selon un autre mode de réalisation possible, le système serveur 120 n'a pas la connaissance complète de l'architecture du système de télécommunications 1. Par exemple, dans le cas le plus limitatif, le système serveur 120 ne connaît que les données présentes dans sa mémoire cache 2863127 24 121. Le système serveur 120 doit alors effectuer une recherche sur le réseau afin de connaître les systèmes clients 110 non connectés qui disposent des images HR demandées. La relation 513 entre les tables 502 et 504 n'est pas présente dans ce mode de réalisation.
La relation 514 entre les tables 502 et 504 autorise une optimisation du système de télécommunications 1.
La relation 514 sert à conserver la notion de lien entre un système client 110 et une image HR demandée, ce qui permet à chaque reconnexion du système client 110 de vérifier rapidement si une image HR doit être transférée ou pas vers le système serveur 120.
La relation 514 optimise donc le traitement de la base de données 122 car il n'est alors pas nécessaire de lancer une recherche sur toute la table 500 et de comparer les demandes asynchrones AD en attente avec une liste de données que fournit le serveur local de fichiers 114 lors d'une reconnexion.
La relation 514 est intéressante même si le système serveur 120 doit effectuer une recherche sur le réseau, lorsque la relation 513 n'existepas. En effet, cette recherche ne présente pas un caractère d'urgence car le système client 110 susceptible de fournir l'image HR demandée est en principe déconnecté. De plus, avec la relation 514, le système de télécommunications 1 est davantage décentralisé et le nombre des connexions au système serveur 120 à travers le réseau 100 est inférieur. De préférence, le nombre des relations 514 dans la base de données 122 sera cependant limité au strict nécessaire afin de ne pas alourdir la gestion de la base de données 122.
On notera que les relations 513 et 514 ne sont pas équivalentes et que la relation 514 ne remplace pas la relation 513.
L'emploi de la relation 514 est compatible avec les deux modes de réalisation mentionnés ci-dessus et correspondant respectivement au cas où le système serveur 120 conserve en permanence la localisation de l'ensemble des données dans le système de télécommunications 1 et au cas où le système serveur 120 n'a pas la connaissance complète de l'architecture du système de télécommunications 1, respectivement.
En référence à la Fig.6, il est maintenant décrit un algorithme montrant le fonctionnement du système serveur 120 lorsqu'une demande asynchrone AD pour une image IUID est émise par un utilisateur parcourant une collection COL dans un système client 110.
2863127 25 Les différentes étapes de l'algorithme de la Fig. 6 mettent en oeuvre dans le système serveur 120 le procédé de délivrance de données numériques selon l'invention.
Des étapes 600 et 601 permettent de recevoir la demande asynchrone AD et de vérifier, avec l'aide des tables 500 à 504, les paramètres transmis au système serveur 120. Si une erreur est détectée à l'étape 601, un message d'erreur, étape 607, est envoyé au système client 110 demandeur.
A une étape 602, il est déterminé si la demande asynchrone AD reçue par le système serveur 120 fait suite ou pas à une demande asynchrone AD précédente toujours en cours du même système client 110. Pour cela les identifiants UUID sont comparés.
En cas de résultat négatif à l'étape 602, la demande asynchrone AD reçue est enregistrée directement dans une nouvelle entrée de la table 500, avec comme référence la date de la demande asynchrone AD reçue, étape 606.
En cas de résultat positif à l'étape 602, une étape 603 est réalisée.
A l'étape 603, il est déterminé si l'image HR faisant l'objet de la demande asynchrone AD reçue est déjà demandée par le même système client 110. Pour cela, les identifiants IUID sont comparés.
En cas de résultat négatif à l'étape 603, c'est-à-dire, si l'image de haute résolution ne fait pas l'objet d'une demande asynchrone AD précédente en cours du même système client 110, l'étape 606 est réalisée et une demande asynchrone AD supplémentaire pour le même système client 110, mais pour une image différente, est enregistrée dans la table 500.
En cas de résultat positif à l'étape 603, une étape 604 est effectuée afin de compléter l'analyse de la demande asynchrone AD reçue.
L'étape 604 permet de déterminer si la demande asynchrone AD reçue du système client 110 est bien différente de la demande asynchrone AD précédente en cours pour la même image HR. Pour cela, les identifiants CUID sont comparés.
En cas de résultat négatif à l'étape 604, cela signifie que le système client 110 demande une même image HR depuis une collection COL différente. Une étape 605 est alors réalisée pour mettre à jour la table 500 notamment en ajoutant le nouveau CUID dans la demande asynchrone AD précédente. Il est ainsi réalisé un regroupement de deux demandes 2863127 26 asynchrones AD successives émanant du même système client 110 à partir de la même collection COL.
Conformément à l'invention, après la recherche effectuée par le système serveur 120, il est transmis au système client 110 une réponse pour chacune des collections COL à partir desquelles l'image HR a été demandée. Cette caractéristique est détaillée dans la partie de la description relative à la Fig.7.
En cas de résultat positif à l'étape 604, la demande asynchrone AD reçue est identique à une demande asynchrone AD précédente en cours et elle n'est alors pas enregistrée dans la table 500. Un message d'erreur, étape 607, est envoyé au système client 110 demandeur.
Pour chaque demande asynchrone AD enregistrée dans la table 500, il est ensuite effectué une étape 608 pour rechercher des systèmes clients 110 pouvant servir l'image HR demandée. L'étape de recherche 608 est effectuée soit directement à partir des relations 513 de la base de données 122 si celles-ci existent, soit par une recherche sur le réseau.
A l'issue de l'étape de recherche 608, les relations 514 sont de préférence mises à jour.
De plus, une étape de mise à jour (non représentée) des relations 514 est également effectuée. Une telle étape de mise à jour intervient par exemple lorsque le système serveur 120 est alerté de l'apparition de modifications dans les systèmes clients 110 ou lorsque le système serveur 120 décide à intervalles de temps réguliers d'effectuer de nouvelles recherches de systèmes clients 110 disposant des images HR demandées.
En référence à la Fig.7, il est maintenant décrit la délivrance d'une réponse à une demande asynchrone AD par le système serveur 120 lorsqu'un système client 110 se reconnecte en mode pair-à-pair au système de télécommunications 1.
Les étapes 700 à 704 traitent successivement chacune des 30 demandes asynchrones AD à servir du système client 110 qui se reconnecte au système de télécommunications 1.
Les étapes 705 à 710 traitent les demandes asynchrones AD en fonction des informations de contexte CINF=CUID inscrites dans les demandes asynchrones AD de façon à regrouper par collection COL les réponses à délivrer au système client 110.
A l'étape 700, le système client 110 qui souhaite se reconnecter au système de télécommunications 1 informe le système serveur 120 de sa 2863127 27 reconnexion au réseau 100 et de modifications éventuelles intervenues dans les images HR et collections COL qu'il contient.
L'étape 700 est donc une étape d'initialisation de la reconnexion.
L'étape 700 fait appel à des procédés connus dans les réseaux pair-à-pair notamment pour vérifier la validité des paramètres de connexion (ADRESSE_IP, PORT) proposés par le serveur local de fichiers 114 du système client 110 et pour mettre à jour la table 504. Dans le cas où le système serveur 120 conserve la connaissance de toutes les images HR présentes dans le système de télécommunications 1, le serveur local de fichiers 114 indique au système serveur 120 les images HR disponibles dans le système client 110 afin que le système serveur 120 actualise la relation 513 entre les tables 502 et 504.
A l'étape 701, le système serveur 120 obtient une liste LI des images HR nouvellement disponibles (relations 514) dans le système client 110, du fait de la reconnexion du système client 110 au système de télécommunications 1.
Dans le cas où la liste LI est vide, l'algorithme se termine.
Dans le cas inverse, les étapes 703 et 704 ont pour objet de récupérer les images HR nouvellement disponibles dans le serveur local de fichiers 114 afin de les télécharger dans la mémoire cache 121 du système serveur 120. Une fois les images HR téléchargées dans la mémoire cache 121, les champs STATUS des demandes asynchrones AD correspondantes de la table 500 sont actualisés, STATUS = téléchargement effectué , et les entrées des relations 514 concernées peuvent être supprimées.
II est alors possible de délivrer des réponses aux systèmes clients demandeurs.
On notera que les champs STATUS et DATE peuvent être employés pour gérer efficacement la mémoire cache 121 du système serveur 120. Ainsi, une image HR ne sera supprimée dans la mémoire cache 121 qu'une durée déterminée après que toutes les demandes asynchrones AD relatives à cette image HR aient donné lieu à une visualisation ou consultation de l'image HR dans les systèmes clients 110 demandeurs. Eventuellement, lorsque les demandes asynchrones AD ne sont pas supprimées dans les systèmes clients 110 après consultation des images HR correspondantes, il peut être prévu un service dans le système serveur 120 afin d'avertir les systèmes clients 110 concernés de l'imminence de la destruction des images HR dans la mémoire cache 121.
2863127 28 L'étape 705 consiste à déterminer à partir de la liste LI une sous-liste L2 de collections COL auxquelles ne correspondent que des demandes asynchrones AD pour lesquelles des réponses peuvent être notifiées aux systèmes clients 110 demandeurs. Les images HR à délivrer en réponse aux demandes asynchrones AD des collections COL de la sous- liste L2 sont toutes disponibles dans la mémoire cache 121.
Les étapes 707 à 709 sont ensuite exécutées pour chaque collection COL de la liste L2.
A l'étape 707, il est déterminé une liste L3 des images HR de la 10 collection COL considérée pour lesquelles STATUS = téléchargement effectué dans la table 500.
Lors d'une notification de réponse à un système client 110, l'étape 707 autorise un regroupement d'une image HR courante avec des images HR de la même collection COL en instance de notification. La liste L3 est obtenue par un utilisateur en employant en association les relations 511 et 512 dans la base de données 122.
L'étape 708 est prévue afin de déterminer une liste L4 des systèmes clients 110 ayant demandé une image HR de la collection COL en cours.
A l'étape 709, pour chaque système client 110 de la liste L4, il est créé une page de notification NP pour les images HR demandées de la collection COL. Les pages de notification NP sont ensuite envoyées respectivement aux systèmes clients 110 répertoriés dans la liste L4.
Conformément à l'invention, il est ainsi délivré au système client demandeur 110 une réponse incorporant l'information de contexte CINF=CUID. Dans ce mode particulier de réalisation, la réponse du système serveur 120 prend la forme de la page de notification NP.
Conformément à l'invention, le système client demandeur 110 est apte à extraire l'information de contexte CINF=CUID dans la page NP reçue. Le système client 110 réagit ensuite à cette information CINF pour se mettre au moins en partie dans un état, c'est-à-dire, l'affichage sur écran d'une page NP reprenant la présentation de la collection COL, qui est analogue à l'état à partir duquel a été émise la demande asynchrone AD, c'est-à-dire, l'affichage sur écran de la collection COL.
Les pages de notification NP sont envoyées par exemple par courrier électronique aux adresses EMAIL conservées dans la table 501, à travers une messagerie instantanée ou un système de messagerie propriétaire 2863127 29 dans le système de télécommunications 1. La page de notification NP peut être le corps du message envoyé, ou une pièce jointe à un message de type texte ou autre.
Dans ce mode particulier de réalisation, la page de notification NP est une page de type HTML. La page de notification NP peut donc être affichée par le navigateur Internet du système client 110 en fonction des caractéristiques techniques de présentation décrites dans le fichier CSS associé à la collection COL correspondante. De plus, lors de la réception de la page NP par le système client 110 destinataire, le fichier CSS d'origine de la collection COL est éventuellement remplacé automatiquement par un autre fichier CSS sélectionné par l'utilisateur pour l'affichage de la collection COL.
Dans l'algorithme de la Fig.7 qui vient d'être décrit, la page de notification NP envoyée à un système client 110 peut indiquer toute la liste L3 des images HR nouvellement disponibles de la collection COL. La liste L3 comprend alors les images HR de la collection COL effectivement demandées par le système client 110, mais aussi d'autres images HR de la même collection COL demandées par d'autres systèmes clients 110 notifiés de manière concomitante. Les images HR réellement demandées par le système client 110 recevant la page de notification NP sont de préférence différenciées des autres images HR dans l'affichage de la liste L3.
La Fig.8 représente un exemple d'écran d'affichage correspondant à la page de notification NP dans un système client 110.
Conformément à l'invention, du fait d'un affichage de la page de notification NP analogue à l'affichage de la collection COL (Fig. 4) à partir de laquelle a été émise la demande asynchrone AD, l'utilisateur, lorsqu'il reçoit une page NP, est amené dans un environnement qu'il perçoit comme celui de la collection COL. Des titres, des commentaires, des images de fond et des décors analogues facilitent une telle perception.
De plus, la perception de l'utilisateur est confirmée par l'accès qui lui est offert à des ressources auxquelles il avait accès dans le contexte de la demande AD. Par exemple, dans ce mode particulier de réalisation, l'utilisateur a accès à la collection globale COL à travers l'exécution d'un logiciel dédié ou pas.
Dans l'exemple montré à la Fig.8, la page de notification NP 35 comprend une zone de titre 800, une zone d'affichage complémentaire 801 et des zones d'affichage d'imagette 802, 803 et 804.
2863127 30 Deux imagettes correspondant à deux images HR faisant l'objet de deux demandes asynchrones AD respectives sont affichées dans les zones 802 et 803. Dans la zone 804 sont affichées des imagettes pour les autres images HR de la liste L3.
La zone 800 affiche le titre TLC de la collection COL auquel est associé ici un lien direct GCL vers la collection COL globale.
Dans le cas d'un affichage de la page NP dans un navigateur Internet, le lien GCL se présente par exemple sous la forme: http:l/localhost:80/CUID. html, lorsque la page HTML supportant la collection COL est stockée dans le serveur local de fichiers 114 ayant l'adresse localhost .
Les imagettes dans les zones 802, 803 et 804 comportent des liens URL associés, LHRmI, LHRm2 et LHRm3, vers les images HR correspondantes.
Dans l'algorithme décrit en référence à la Fig.7, les images HR faisant l'objet des demandes asynchrones AD sont téléchargées dans le système serveur 120 préalablement à la notification des systèmes clients 110 demandeurs et sont donc disponibles de manière certaine dans le système serveur 120 lors de la notification.
Dans le cas ci-dessus, un lien URL, LHRm, se présentera par exemple sous la forme: http:/llocalhost:80/gethighres?iuid=lUlD&cuid=CUID, avec une redirection automatique de la commande gethighres vers le système serveur 120: http://www.centralhost.com/gethighres?iuid=lUID&cuid=CUID.
Selon d'autres modes de réalisation de l'invention, les images HR faisant l'objet des demandes asynchrones AD peuvent ne pas être téléchargées systématiquement dans le système serveur 120 préalablement à l'envoi des notifications correspondantes aux systèmes clients 110. Les liens LHRm autoriseront alors des accès à des emplacements, dans des serveurs locaux de fichiers 114, où les images HR sont disponibles.
Selon encore un autre mode de réalisation de l'invention, une image HR faisant l'objet d'une demande asynchrone AD peut être délivrée directement, en totalité ou partiellement, avec la notification au système client 110 demandeur.
Selon encore un autre mode de réalisation de l'invention, les images HR ne sont pas seulement accessible à travers la page de notification 15 2863127 31 NP. L'utilisateur peut par exemple prendre d'abord connaissance des nouvelles images HR disponibles en visualisant la page de notification NP, cliquer ensuite sur le lien GCL du titre de la collection et sélectionner les imagettes appropriées sur la page d'en- tête de la collection (Fig.4) afin d'obtenir les images HR demandées.
Bien entendu, la présente invention ne se limite pas aux détails des modes de réalisation décrits ici à titre d'exemple, mais s'étend au contraire aux modifications à la portée de l'homme du métier, sans sortir du cadre de l'invention.
Ainsi, par exemple, dans des modes de réalisation du type de ceux qui ont été décrits ci-dessus mais adaptés à la délivrance de données vidéo, le début du flux vidéo représentera par exemple une version minimale de la vidéo complète. L'utilisateur demandera la vidéo complète à partir de la visualisation de la version minimale.
Dans d'autres modes de réalisation pour la délivrance de documents numériques d'application bureautique, une image réduite de la première page du document sera par exemple utilisée comme version minimale à partir de laquelle pourra être demandé le document complet.

Claims (6)

  1. 32 REVENDICATIONS
    1. Procédé de délivrance asynchrone de données numériques mis en oeuvre dans au moins un système serveur et au moins un système client reliés à travers un réseau de télécommunications, ledit système client étant susceptible de recevoir en temps différé des données numériques demandées auprès dudit système serveur, caractérisé en ce qu'il comprend des étapes de: - association (405) à une demande de données (AD) émanant dudit système client (110) d'une information de contexte (CINF, CUID) représentative d'un premier état (SD, COL) d'au moins une partie dudit système client demandeur (110) lors de l'émission de ladite demande de données (AD) ; - recherche (608, 701 à 703), à partir de ladite demande (AD), de certaines au moins des données demandées (HR) dans au moins un desdits systèmes (120, 110) reliés audit réseau de télécommunications (100) ; et - délivrance (408, 709) audit système client demandeur (110) d'une réponse (NP, LHRm) incorporant ladite information de contexte (CINF, CUID) , ledit système client demandeur (110) étant apte à extraire ladite information de contexte (CINF, CUID) et à réagir à celle-ci pour se mettre au moins en partie dans un second état (NP, COL) analogue audit premier état (SD, COL).
    2. Procédé de délivrance asynchrone de données numériques mis en oeuvre dans un système serveur apte à coopérer avec au moins un système client relié audit système serveur à travers un réseau de télécommunications, ledit système client étant susceptible de recevoir en temps différé des données numériques demandées auprès dudit système serveur, caractérisé en ce qu'il comprend des étapes de - réception (600) d'une demande de données (AD) émanant dudit système client (110) et comportant une information de contexte (CINF, CUID) représentative d'un premier état (SD, COL) d'au moins une partie dudit système client demandeur (110) lors de l'émission de ladite demande de données (AD) ;
  2. 15 2863127 33 - recherche (608, 701 à 703), à partir de ladite demande (AD), de certaines au moins des données demandées (HR) dans au moins un desdits systèmes (120, 110) reliés audit réseau de télécommunications (100) ; et - délivrance (709) audit système client demandeur (110) d'une réponse (NP, COL) incorporant ladite information de contexte (CINF, CUID).
    3. Procédé selon la revendication 2, caractérisé en ce qu'il comprend aussi, préalablement à ladite étape de recherche, une étape de: regroupement (605) de demandes de données successives (AD) émanant d'un même système client (110) dans un même premier état (SD, COL) en une seule demande de données (AD) à partir de laquelle est exécutée ladite étape de recherche (608, 701 à 703) ; et préalablement à ladite étape de délivrance, une étape de: - regroupement (707 à 709) de plusieurs réponses à une ou plusieurs demandes de données (AD) émanant d'un même système client (110) dans un même premier état (SD, COL) en une seule réponse (NP, COL) à délivrer audit même système client (110).
    4. Procédé selon la revendication 3, caractérisé en ce que ladite étape de regroupement (605) de demandes de données successives (AD) comprend une sous-étape de: - suppression d'une redondance éventuelle (604, 607) dans 25 lesdites demandes de données successives (AD).
    5. Procédé selon l'une quelconque des revendications 2 à 4, caractérisé en ce que ladite étape de recherche (608, 701 à 703) comprend une sous- étape de: - recherche de certaines au moins desdites données demandées (HR) dans une base de données (122) comprise dans ledit système serveur (120).
    6. Procédé selon l'une quelconque des revendications 2 à 5, 35 caractérisé en ce que ladite étape de recherche (608, 701 à 703) comprend une sous-étape de: 15 2863127 34 - recherche de certaines au moins desdites données demandées (HR) dans au moins un serveur local de fichiers (114) compris dans un système client (110) autre que ledit système client demandeur (110).
    7. Procédé selon l'une quelconque des revendications 2 à 6, caractérisé en ce que ladite étape de délivrance (408, 709) comprend une sous-étape de: envoi de ladite réponse ou d'une partie de celle-ci sous la forme d'une notification (NP) indiquant une disponibilité desdites données 10 demandées (HR).
    8. Procédé selon la revendication 7, caractérisé en ce que ladite notification (NP) comporte une partie ou toutes (802, 803) les données demandées (HR).
    9. Procédé selon la revendication 7 ou 8, caractérisé en ce que ladite notification (NP) comporte au moins un lien (LHRm) vers un emplacement (120, 110) où lesdites données demandées (HR) sont disponibles ou partiellement disponibles et/ou au moins un lien (GCL) vers un ensemble d'ordre supérieur (COL) dont font partie lesdites données demandées (HR).
    10. Procédé selon l'une quelconque des revendications 2 à 9, caractérisé en ce que ladite étape de délivrance (408, 709) comprend une 25 sousétape de: - chargement (LHRm) dans ledit système client demandeur (110) desdites données demandées ou d'une partie de celles-ci (HR) à partir d'un ou plusieurs emplacements dans ledit système serveur (120) et/ou ledit au moins un système client (110).
    11. Procédé de demande / réception de données numériques mis en oeuvre dans un système client relié à au moins un système serveur à travers un réseau de télécommunications, ledit système client étant susceptible de demander des données numériques audit système serveur et de recevoir en temps différé lesdites données numériques demandées après une recherche de celles-ci effectuée par ledit système serveur, caractérisé en ce qu'il comprend des étapes de: 2863127 35 à l'émission de ladite demande de données (AD) : - génération (404) d'une information de contexte (CINF, CUID) représentative d'un premier état (SD, COL) d'au moins une partie dudit système client (110) lors de l'émission de ladite demande de données (AD) et association de ladite information de contexte (CINF, CUID) à ladite demande de données (AD) émise; et à la réception d'une réponse (NP, COL) incorporant ladite information de contexte (CINF, CUID) en provenance dudit système serveur (120) : - extraction (407) de ladite information de contexte (CINF, CUID) de ladite réponse (NP, COL), et - gestion de contexte (408) en mettant au moins une partie dudit système client (110) dans un second état (NP, COL) analogue audit premier état (SD, COL) en réaction à ladite information de contexte (CINF, CUID) extraite.
    12. Procédé selon la revendication 1, dans lequel lesdites données peuvent être organisées en des ensembles d'ordre supérieur (COL), tels que des albums, des collections et/ou des catalogues, caractérisé en ce que lesdits premier et second états comprennent au moins un affichage d'écran (SD, NP) associé auxdites données et/ou l'exécution d'au moins un logiciel informatique (112, 113) associé auxdites données demandées (HR) et/ou au moins un affichage d'écran (SD, NP) associé auxdits ensembles d'ordre supérieur et/ou l'exécution d'au moins un logiciel informatique (112, 113) associé auxdits ensembles d'ordre supérieur (COL).
    13. Procédé selon la revendication 12, caractérisé en ce que ledit logiciel informatique comprend une interface logicielle de visualisation (113), ladite interface logicielle ayant éventuellement la forme d'un logiciel dédié ou d'un navigateur de type Internet.
    14. Procédé selon la revendication 1 ou 12, caractérisé en ce que lesdites données sont des données de type multi-résolutions comprenant des données d'image et/ou des données vidéo et/ou des données audio et/ou des données de texte.
  3. 2863127 36 15. Dispositif de délivrance asynchrone de données numériques incorporé de manière répartie dans au moins un système serveur et au moins un système client reliés à travers un réseau de télécommunications, ledit système client étant susceptible de recevoir en temps différé des données numériques demandées auprès dudit système serveur, caractérisé en ce qu'il comprend: - des moyens d'association (111, 112), incorporés dans ledit au moins un système client (110), pour associer à une demande de données (AD) émanant d'un système client demandeur (110) une information de contexte (CINF, CUID) représentative d'un premier état (SD, COL) d'au moins une partie dudit système client demandeur (110) lors de l'émission de ladite demande de données (AD) ; - des moyens de recherche (PROG, 200, 121, 122), incorporés dans ledit système serveur (120), pour rechercher, à partir de ladite demande (AD), certaines au moins des données demandées (HR) dans au moins un desdits systèmes (120, 110) reliés audit réseau de télécommunications (100) ; et - des moyens de délivrance (PROG, 200, 121, 122), incorporés dans ledit système serveur (120), pour délivrer audit système client demandeur (110) une réponse (NP, COL) incorporant ladite information de contexte (CINF, CUID), ledit système client demandeur (110) étant apte à extraire ladite information de contexte (CINF, CUID) et à réagir à celle-ci pour se mettre au moins en partie dans un second état (NP, COL) analogue audit premier état (SD, COL).
    16. Dispositif de traitement d'information apte à fonctionner comme un système serveur capable de coopérer avec au moins un système client relié audit système serveur à travers un réseau de télécommunications, ledit système client étant susceptible de recevoir en temps différé des données numériques demandées auprès dudit système serveur, caractérisé en ce qu'il comprend: - des moyens de réception (PROG, 200, 121, 122) pour recevoir une demande de données (AD) émanant dudit système client (110) et comportant une information de contexte (CINF, CUID) représentative d'un premier état (SD, COL) d'au moins une partie dudit système client demandeur (110) lors de l'émission de ladite demande de données (AD) ;
  4. 2863127 37 - des moyens de recherche (PROG, 200, 121, 122) pour rechercher, à partir de ladite demande (AD), certaines au moins des données demandées (HR) dans au moins un desdits systèmes (120, 110) reliés audit réseau de télécommunications (100); et - des moyens de délivrance (PROG, 200, 121, 122) pour délivrer audit système client demandeur (110) une réponse (NP, COL) incorporant ladite information de contexte (CINF, CUID).
    17. Dispositif selon la revendication 16, caractérisé en ce que lesdits moyens de recherche (PROG, 200, 121, 122) comprennent: - des moyens de regroupement (PROG, 605) pour regrouper des demandes de données successives (AD) émanant d'un même système client (110) dans un même premier état (SD, COL) en une seule demande de 15 données (AD); et lesdits moyens de délivrance (PROG, 200, 121, 122) comprennent: - des moyens de regroupement (PROG, 707 à 709) pour regrouper plusieurs réponses à une ou plusieurs demandes de données (AD) émanant d'un même système client (110) dans un même premier état (SD, COL) en une seule réponse à délivrer audit même système client (110).
    18. Dispositif selon la revendication 17, caractérisé en ce que lesdits moyens de regroupement (PROG, 605) des demandes de 25 données successives (AD) comprennent: - des moyens de suppression (PROG, 604) pour supprimer une redondance éventuelle dans lesdites demandes de données successives (AD).
    19. Dispositif selon l'une quelconque des revendications 16 à 18, caractérisé en ce que lesdits moyens de recherche (PROG, 200, 121, 122) sont adaptés à effectuer une recherche dans une base de données (122) comprise dans ledit système serveur (120).
    20. Dispositif selon l'une quelconque des revendications 16 à 19, caractérisé en ce que lesdits moyens de recherche (PROG, 200, 121, 122) sont adaptés à effectuer une recherche dans au moins un serveur local de fichiers 10 35 2863127 38 (114) compris dans un système client (110) autre que ledit système client demandeur (110).
    21. Dispositif selon l'une quelconque des revendications 16 à 20, 5 caractérisé en ce que lesdits moyens de délivrance (PROG, 200, 121, 122) comprennent: - des moyens d'envoi (PROG, 709) pour envoyer ladite réponse ou une partie de celle-ci sous la forme d'une notification indiquant une disponibilité desdites données demandées (HR).
    22. Dispositif selon la revendication 21, caractérisé en ce que lesdits moyens d'envoi (PROG, 709) comprennent: - des moyens d'insertion (PROG, 709) pour insérer une partie ou toutes les données demandées (HR) dans ladite notification (NP). 15 23. Dispositif selon la revendication 21 ou 22, caractérisé en ce que lesdits moyens d'envoi (PROG, 709) comprennent: - des moyens d'insertion supplémentaires (PROG, 709) pour insérer dans ladite notification (NP) au moins un lien (LHRm) vers un emplacement (120, 110) où lesdites données demandées (HR) sont disponibles ou partiellement disponibles et/ou au moins un lien (GCL) vers un ensemble d'ordre supérieur (COL) dont font partie lesdites données demandées (HR).
    24. Dispositif selon l'une quelconque des revendications 16 à 23, caractérisé en ce que lesdits moyens de délivrance (PROG, 200, 121, 122) comprennent: - des moyens de chargement (PROG, 200, LHRm) pour charger dans ledit système client demandeur (110) lesdites données demandées (HR) ou une partie de celles-ci à partir d'un ou plusieurs emplacements (120, 110) dans ledit système serveur (120) et/ou ledit au moins un système client (110).
    25. Dispositif de traitement d'information apte à fonctionner comme système client relié à au moins un système serveur à travers un réseau de télécommunications, ledit système client étant susceptible de demander des données numériques audit système serveur et de recevoir en temps différé 2863127 39 lesdites données numériques demandées après une recherche de celles-ci effectuée par ledit système serveur, caractérisé en ce qu'il comprend du côté émission: - des moyens de génération (111, 112, 404) pour générer, à l'émission de ladite demande de données (AD), une information de contexte (CINF, CUID) représentative d'un premier état (SD, COL) d'au moins une partie dudit système client (110) lors de l'émission de ladite demande de données (AD), et - des moyens d'association (111, 112, 405) pour associer ladite information de contexte (CINF, CUID) à ladite demande de données (AD) émise; et du côté réception: - des moyens d'extraction (111, 112, 407) pour extraire ladite information de contexte (CINF, CUID) d'une réponse reçue en provenance dudit système serveur (120), et - des moyens de gestion de contexte (111, 112, 408) pour mettre au moins une partie dudit système client (110) dans un second état (NP, COL) analogue audit premier état (SD, COL) en réaction à ladite information de contexte (CINF, CUID) extraite.
    26. Dispositif selon la revendication 15, dans lequel lesdites données peuvent être organisées en des ensembles d'ordre supérieur (COL), tels que des albums, des collections et/ou des catalogues, caractérisé en ce que lesdits moyens de gestion de contexte (111, 112, 408) comprennent des moyens pour produire, en tant que partie desdits premier et second états, au moins un affichage d'écran (SD, NP, COL) associé auxdites données et/ou pour exécuter, en tant que partie desdits premier et second états, au moins un logiciel informatique (112) associé auxdites données et/ou pour produire, en tant que partie desdits premier et second états, au moins un affichage d'écran (SD, NP, COL) associé auxdits ensembles d'ordre supérieur (COL) et/ou pour exécuter, en tant que partie desdits premier et second états, au moins un logiciel informatique (112) associé auxdits ensembles d'ordre supérieur (COL).
    27. Dispositif selon la revendication 26, caractérisé en ce que ledit logiciel informatique (112) comprend une interface logicielle de visualisation (113), ladite interface logicielle ayant éventuellement la forme d'un logiciel dédié ou d'un navigateur de type Internet.
  5. 2863127 40 28. Dispositif selon la revendication 15 ou 26, caractérisé en ce que lesdites données sont des données de type multi-résolutions (HR) comprenant des données d'image et/ou des données vidéo et/ou des données audio et/ou des données de texte.
    29. Dispositif de traitement d'information apte à fonctionner comme système serveur dans un réseau de télécommunications, caractérisé en ce qu'il comprend des moyens adaptés à la mise en oeuvre du procédé
    selon l'une quelconque des revendications 2 à 10.
    30. Dispositif de traitement d'information apte à fonctionner comme système client (110) dans un réseau de télécommunications, caractérisé en ce qu'il comprend des moyens adaptés à la mise en oeuvre du procédé selon la revendication 11.
    31. Dispositif de traitement d'image numérique apte à fonctionner comme système client (110) dans un réseau de télécommunications, caractérisé en ce qu'il comprend des moyens adaptés à la mise en oeuvre du procédé selon la revendication 11.
    32. Système de télécommunications comprenant un réseau de télécommunications et au moins un dispositif (110, 120) selon la revendication 15.
    33. Système de télécommunications selon la revendication 32, caractérisé en ce que ledit réseau de communication (100) est de type pair-àpair (P2P) .
    34. Moyen de stockage d'information, caractérisé en ce qu'il mémorise un programme (112, PROG) mettant en oeuvre le procédé selon la revendication 1.
    35. Moyen de stockage d'information, caractérisé en ce qu'il est 35 lisible par un dispositif (110, 120) selon la revendication 15.
  6. 2863127 41 36. Moyen de stockage d'information selon la revendication 34 ou 35, caractérisé en ce qu'il comprend une mémoire volatile et/ou une mémoire non-volatile et/ou un disque dur et/ou une disquette et/ou un CD-ROM.
    37. Programme d'ordinateur sur un moyen de stockage, comportant une ou plusieurs séquences d'instructions exécutables par ordinateur mettant en oeuvre le procédé selon la revendication 1.
FR0314147A 2003-12-02 2003-12-02 Procedes et dispositifs pour la delivrance asynchrone de donnees numeriques Pending FR2863127A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR0314147A FR2863127A1 (fr) 2003-12-02 2003-12-02 Procedes et dispositifs pour la delivrance asynchrone de donnees numeriques
EP04292848A EP1538808A1 (fr) 2003-12-02 2004-12-01 Procédés et dispositifs pour la délivrance de données numériques
US11/002,400 US7711804B2 (en) 2003-12-02 2004-12-02 Methods and devices for the asynchronous delivery of digital data

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0314147A FR2863127A1 (fr) 2003-12-02 2003-12-02 Procedes et dispositifs pour la delivrance asynchrone de donnees numeriques

Publications (1)

Publication Number Publication Date
FR2863127A1 true FR2863127A1 (fr) 2005-06-03

Family

ID=34451710

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0314147A Pending FR2863127A1 (fr) 2003-12-02 2003-12-02 Procedes et dispositifs pour la delivrance asynchrone de donnees numeriques

Country Status (3)

Country Link
US (1) US7711804B2 (fr)
EP (1) EP1538808A1 (fr)
FR (1) FR2863127A1 (fr)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005048565A1 (fr) * 2003-11-14 2005-05-26 Canon Kabushiki Kaisha Systeme, procede et dispositifs permettant de consulter ou de partager un document numerique dans un reseau de communication point a point
US7584382B2 (en) * 2004-02-19 2009-09-01 Microsoft Corporation Method and system for troubleshooting a misconfiguration of a computer system based on configurations of other computer systems
FR2868896B1 (fr) * 2004-04-13 2008-03-14 Canon Kk Procede et dispositif de controle d'acces a un document numerique partage dans un reseau de communication de type poste a poste
FR2870022B1 (fr) 2004-05-07 2007-02-02 Canon Kk Procede et dispositif de distribution de donnees numeriques notamment pour reseau pair-a-pair
FR2886494B1 (fr) * 2005-05-24 2007-06-29 Canon Kk Procede et dispositif d'echange de donnees entre des stations mobiles dans un reseau pair a pair
US9069870B2 (en) * 2006-07-12 2015-06-30 International Business Machines Corporation Client-side aggregation of context-sensitive request results where results for aggregation are asynchronously produced by multiple servers
CN101136911B (zh) * 2006-08-31 2010-12-15 腾讯科技（深圳）有限公司 一种采用p2p技术下载文件的方法和p2p下载系统
US20080127234A1 (en) * 2006-09-19 2008-05-29 International Business Machines Corporation Methods, systems, and computer program products for a remote request dispatcher extension framework for container based programming models
FR2906950B1 (fr) * 2006-10-05 2008-11-28 Canon Kk Procede et dispositifs pour adapter le debit de transmission d'un flux de donnees en presence d'interferences.
FR2908576A1 (fr) 2006-11-14 2008-05-16 Canon Kk Procede,dispositif et application logicielle d'ordonnancement d'une transmission de paquets d'un flux de donnees
FR2909241B1 (fr) * 2006-11-27 2009-06-05 Canon Kk Procedes et dispositifs de gestion dynamique des erreurs de transmission par des points d'interconnexion de reseaux.
TW200841738A (en) * 2007-04-03 2008-10-16 Awind Inc Display apparatus having function of network link
FR2916600B1 (fr) * 2007-05-24 2013-11-22 Canon Kk Procede et dispositif de transmission de donnees
US20090049491A1 (en) * 2007-08-16 2009-02-19 Nokia Corporation Resolution Video File Retrieval
US7698411B2 (en) * 2007-08-22 2010-04-13 International Business Machines Corporation Selectively delivering cached content or processed content to clients based upon a result completed percentage
US8032587B2 (en) * 2007-08-28 2011-10-04 International Business Machines Corporation Method and apparatus for client-side aggregation of asynchronous fragmented requests
US9432243B2 (en) * 2007-08-22 2016-08-30 International Business Machines Corporation Re-using asynchronous server-side results generated for a request context of one client to satisfy a request context of a different client
US20090064202A1 (en) * 2007-09-04 2009-03-05 Apple, Inc. Support layer for enabling same accessory support across multiple platforms
FR2926939A1 (fr) 2008-01-30 2009-07-31 Canon Kk Procede de transmission de donnees avec anticipation des acquittements, dispositif d'entree, produit programme d'ordinateur et moyen de stockage correspondants
FR2927749B1 (fr) * 2008-02-14 2010-12-17 Canon Kk Procede et dispositif de transmission de donnees, notamment video.
FR2933834A1 (fr) * 2008-07-11 2010-01-15 Canon Kk Procede de gestion d'une transmission de flux de donnees sur un canal de transport d'un tunnel, tete de tunnel, produit programme d'ordinateur et moyen de stockage correspondants.
FR2935862B1 (fr) * 2008-09-08 2014-09-05 Canon Kk Procede de prediction du taux d'erreurs de transmission dans un reseau de communication et serveur mettant en oeuvre un tel procede
US9241190B2 (en) * 2010-08-24 2016-01-19 Cisco Technology, Inc. Generating a response to video content request including dynamically processed video content
US20130007106A1 (en) * 2011-07-01 2013-01-03 Salesforce. Com Inc. Asynchronous interaction in the report generator
US9473668B2 (en) * 2011-11-01 2016-10-18 Siemens Industry, Inc. Distributed storage and processing of mail image data

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6070184A (en) * 1997-08-28 2000-05-30 International Business Machines Corporation Server-side asynchronous form management
EP1133104A2 (fr) * 2000-03-07 2001-09-12 Hewlett-Packard Company, A Delaware Corporation Transfer d'images dans un réseau mobile à radio
US20020033844A1 (en) * 1998-10-01 2002-03-21 Levy Kenneth L. Content sensitive connected content
US20030063771A1 (en) * 2001-10-01 2003-04-03 Morris Robert Paul Network-based photosharing architecture for search and delivery of private images and metadata
US6577311B1 (en) * 1999-12-16 2003-06-10 Picture Iq Corporation Techniques for automatically providing a high-resolution rendering of a low resolution digital image in a distributed network

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9908631D0 (en) * 1999-04-15 1999-06-09 Canon Kk Search engine user interface
US7130068B1 (en) * 1999-10-05 2006-10-31 Canon Kabushiki Kaisha Print server apparatus, information processing apparatus, print job reservation management method, reservation job generation method and memory medium
US20020033884A1 (en) * 2000-05-03 2002-03-21 Schurr George W. Machine vision-based sorter verification
FR2851866B1 (fr) * 2003-02-27 2005-10-28 Procede d'allocation par un premier pair d'un service a un second pair d'un reseau de communication
FR2855691B1 (fr) * 2003-06-02 2005-11-11 Canon Kk Securisation de la distribution de documents numeriques dans un reseau pair a pair
FR2857763A1 (fr) * 2003-07-18 2005-01-21 Canon Kk Procede d'acces et de partage d'un document numerique dans un reseau de communication p2p
FR2860935B1 (fr) * 2003-10-09 2006-03-03 Canon Kk Procede et dispositif de traitement de donnees numeriques
FR2868896B1 (fr) * 2004-04-13 2008-03-14 Canon Kk Procede et dispositif de controle d'acces a un document numerique partage dans un reseau de communication de type poste a poste
DE602007013652D1 (de) * 2006-08-04 2011-05-19 Canon Kk Kommunikationsvorrichtung und Kommunikationssteuerungsverfahren

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6070184A (en) * 1997-08-28 2000-05-30 International Business Machines Corporation Server-side asynchronous form management
US20020033844A1 (en) * 1998-10-01 2002-03-21 Levy Kenneth L. Content sensitive connected content
US6577311B1 (en) * 1999-12-16 2003-06-10 Picture Iq Corporation Techniques for automatically providing a high-resolution rendering of a low resolution digital image in a distributed network
EP1133104A2 (fr) * 2000-03-07 2001-09-12 Hewlett-Packard Company, A Delaware Corporation Transfer d'images dans un réseau mobile à radio
US20030063771A1 (en) * 2001-10-01 2003-04-03 Morris Robert Paul Network-based photosharing architecture for search and delivery of private images and metadata

Also Published As

Publication number Publication date
US7711804B2 (en) 2010-05-04
US20050198118A1 (en) 2005-09-08
EP1538808A1 (fr) 2005-06-08

Similar Documents

Publication Publication Date Title
FR2863127A1 (fr) Procedes et dispositifs pour la delivrance asynchrone de donnees numeriques
US8001187B2 (en) Peer-to-peer active content sharing
FR2886494A1 (fr) Procede et dispositif d'echange de donnees entre des stations mobiles dans un reseau pair a pair
US9686259B2 (en) System and method for efficient replication of and access to application specific environments and data
EP1911207B1 (fr) Controle d'un equipement multimedia a partir d'un terminal mobile
US20080032739A1 (en) Management of digital media using portable wireless devices in a client-server network
FR2868896A1 (fr) Procede et dispositif de controle d'acces a un document numerique partage dans un reseau de communication de type poste a poste
EP1943639A1 (fr) Procede de gestion de polices de caracteres a l'interieur de scenes multimedia, programme d'ordinateur et terminal correspondants
EP2643961B1 (fr) Communication entre deux applications web
JP2005251194A (ja) アクセスを管理する方法、プログラム、及びシステム、及び、電子メール・メッセージを送信する方法、及びプログラム
EP1204044A1 (fr) Procédé et système d'optimisation de consultations d'ensembles de données par une pluralité de clients
FR2870022A1 (fr) Procede et dispositif de distribution de donnees numeriques notamment pour reseau pair-a-pair
FR2842057A1 (fr) Procede et dispositif de traitement de donnees dans un reseau de communication
FR2893470A1 (fr) Procede et dispositif de creation d'une sequence video representative d'une sequence video numerique et procedes et dispositifs de transmission et reception de donnees video associes
FR2853788A1 (fr) Procede et dispositif d'acces a un document numerique dans un reseau de communication du type poste a poste
FR2918241A1 (fr) Procede, serveur et application pour le partage de contenus personnels entre terminaux d'usager(s)
WO2011110767A1 (fr) Procede et systeme de prise de controle a distance d'un ecran d'affichage
FR2901381A1 (fr) Systeme informatique a gestion universelle et collaborative de fichiers utilisateurs
FR2864283A1 (fr) Procede et dispositif de controle d'acces a un document partage dans une reseau de communication poste a poste
FR2826213A1 (fr) Procede et systeme de diffusion d'images numeriques
FR2908251A1 (fr) Procede et systeme de synchronisation de repertoires
EP1494419A1 (fr) Système de transmission de paramètres caractéristiques d'une session de communication d'un terminal vers un serveur distant
EP1906625B1 (fr) Procédé et système de partage de fichiers sur un réseau, utilisant des capacités de stockage d'un boîtier de connexion au réseau
FR2862460A1 (fr) Procede d'acces a un document numerique dans un reseau de communication
FR2901386A1 (fr) Support personnel de memoire de masse portatif et systeme informatique d'acces securise a un reseau par des utilisateurs.