FR2857763A1 - Procede d'acces et de partage d'un document numerique dans un reseau de communication p2p - Google Patents

Procede d'acces et de partage d'un document numerique dans un reseau de communication p2p Download PDF

Info

Publication number
FR2857763A1
FR2857763A1 FR0308807A FR0308807A FR2857763A1 FR 2857763 A1 FR2857763 A1 FR 2857763A1 FR 0308807 A FR0308807 A FR 0308807A FR 0308807 A FR0308807 A FR 0308807A FR 2857763 A1 FR2857763 A1 FR 2857763A1
Authority
FR
France
Prior art keywords
local
server
document
page
address
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
FR0308807A
Other languages
English (en)
Inventor
Frederic Maze
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 FR0308807A priority Critical patent/FR2857763A1/fr
Priority to EP04291807.8A priority patent/EP1499089B1/fr
Priority to US10/893,012 priority patent/US7716302B2/en
Priority to JP2004210101A priority patent/JP2005122693A/ja
Publication of FR2857763A1 publication Critical patent/FR2857763A1/fr
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/55Push-based network services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • H04L67/1087Peer-to-peer [P2P] networks using cross-functional networking aspects
    • H04L67/1091Interfacing with client-server systems or between P2P systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)

Abstract

Le procédé d'accès comprend les étapes suivantes :- i) recevoir une notification indiquant la présence d'au moins un document numérique disponible sur le réseau, ladite notification comprenant au moins une commande exécutable apte à détecter si le dispositif client destinataire comprend une application locale susceptible de traiter le document numérique,-ii) exécuter la ou les commandes afin de détecter la présence et l'activation de l'application locale, et-iii) en cas d'application locale présente et active, accéder au document numérique à partir d'un serveur local tandis qu'en cas d'absence ou d'inactivité de l'application locale, accéder au document à partir de l'adresse d'un serveur distant.

Description

<Desc/Clms Page number 1>
La présente invention se rapporte à l'accès et/ou au partage d'un document numérique disponible dans un réseau de communication reliant des dispositifs clients entre eux, ledit procédé utilisant une notification indiquant la présence d'un document numérique disponible sur le réseau, la notification étant apte à s'adapter et à exploiter la présence ou non d'une application locale susceptible de traiter le document numérique.
Elle trouve une application générale dans le traitement des documents numériques disponibles dans un réseau de communication, notamment dans les réseaux de communication de type pair à pair, appelés encore poste à poste, peer to peer, et désignés ci-après par l'acronyme P2P.
Les systèmes de communication P2P ont émergé ces dernières années constituant une révolution dans le partage de fichier en comparaison du modèle traditionnel client serveur. Dans les systèmes P2P, chaque machine (on parle aussi de node ou peer) constituant le réseau de communication se comporte aussi bien en dispositif client qu'en dispositif serveur. Ainsi, dans un réseau P2P, les équipements mettent en commun des ressources selon une philosophie de partage d'égal à égal, chaque machine d'un réseau P2P se comportant aussi bien en client qu'en serveur. De tels réseaux se distinguent ainsi des réseaux clients serveurs classiques dans lesquels les ressources sont archivées dans un dispositif serveur central.
Actuellement, la distribution des données fait de plus en plus appel aux réseaux P2P en raison de leur mise en place peu coûteuse, de la présence de très nombreux ordinateurs connectés sur les réseaux, ainsi que du développement des connexions haut débit.
Cependant, les réseaux P2P sont instables. En effet, les dispositifs clients (et par conséquent des dispositifs serveurs) se connectent ou se déconnectent périodiquement sur le réseau, rendant ainsi la présence des données très aléatoires. De plus, les adresses des dispositifs clients et/ou serveurs sont imprédictibles et susceptibles d'être différentes à chaque connexion.
De par leur spécificité, les systèmes P2P impliquent généralement l'utilisation d'une application cliente, locale, dédiée, appelée encore application
<Desc/Clms Page number 2>
locale P2P. Une telle application locale P2P assure le partage du contenu numérique, ainsi que la recherche et l'accès au contenu numérique disponible sur les réseaux P2P.
Par exemple, l'application locale P2P peut offrir un mécanisme de notification basé sur l'échange de messages suivant un protocole propriétaire afin de permettre à un dispositif client de notifier une ou plusieurs personnes qu'il vient de partager de nouveaux contenus numériques sur le réseau.
L'application locale P2P peut également utiliser le courrier électronique comme mécanisme principal d'une notification ou comme un complément au système de notification propriétaire. Dans ce cas, le courrier électronique peut éventuellement contenir en attachement un ou plusieurs fichiers spécifiques qui pourront être interprétés par l'application locale P2P chez le ou les destinataires.
On connaît aussi des systèmes P2P qui permettent à des utilisateurs ne possédant pas d'application locale P2P, d'accéder au contenu sur le réseau à l'aide d'outils d'accès à l'Internet plus traditionnels et répandus tels que les explorateurs, butineurs, ou navigateurs Internet.
Dans de tels systèmes, certains dispositifs clients ou dispositifs serveurs spécifiques dans le réseau se comportent comme des dispositifs serveurs jouant le rôle de passerelle entre l'outil d'accès à Internet (butineur, explorateur, navigateur) et le réseau P2P. Ces machines peuvent être vues comme des dispositifs serveurs mandataires (Proxy en anglais) qui se chargent de récupérer la ressource recherchée sur le réseau P2P pour le compte de l'outil Internet. Dans ces systèmes, le courrier électronique est classiquement utilisé comme mécanisme de notification. Le courrier électronique peut alors contenir une page en langage de balisage ou un lien (appelé aussi URL de l'anglais "Uniform Ressource Locator") vers une page permettant à l'utilisateur destinataire d'accéder aux ressources.
Ainsi, dans un système P2P, un utilisateur peut utiliser une application locale P2P pour partager des contenus numériques sur le réseau, parcourir et accéder au contenu disponible sur le réseau P2P.
<Desc/Clms Page number 3>
L'utilisateur ne possédant pas l'application locale P2P ou celui ne souhaitant pas utiliser l'interface proposée peut également utiliser des outils capables de visualiser des pages en langage de balisage pour accéder au contenu numérique (Navigateur Web, lecteur de courrier électronique, ou tout autre application capable d'afficher des pages en langage de balisage).
Par exemple, l'utilisateur peut partager des collections de contenus numériques avec un ensemble de personnes, ces personnes pouvant posséder ou non l'application locale P2P.
Le Demandeur s'est posé le problème de fournir un procédé permettant de notifier les dispositifs clients destinataires d'une manière uniforme sans savoir à priori si lesdits destinataires possèdent une application locale P2P dédiée au traitement des documents numériques.
La présente invention apporte justement une solution à ce problème.
Elle porte sur un procédé d'accès à au moins un document numérique disponible dans un réseau de communication reliant des dispositifs clients entre eux, ledit procédé d'accès étant mis en oeuvre au sein d'un dispositif client destinataire.
Selon une définition générale de l'invention, le procédé comprend les étapes suivantes : - i) recevoir une notification indiquant la présence d'au moins un document numérique disponible sur le réseau, ladite notification comprenant au moins une commande exécutable apte à détecter si le dispositif client destinataire comprend une application locale susceptible de traiter le document numérique ; - ii) exécuter la ou les commandes afin de détecter la présence et l'activation de l'application locale ; et - iii) en cas d'application locale présente et active, accéder au document numérique à partir d'un serveur local tandis qu'en cas d'absence ou d'inactivité de l'application locale, accéder au document à partir d'un serveur distant.
Ainsi, le procédé notifie de manière uniforme les utilisateurs d'un réseau qui possèdent ou non l'application locale. Plus particulièrement, le
<Desc/Clms Page number 4>
procédé optimise l'usage du réseau au travers de la notification en cherchant à permettre l'usage de l'application locale pour la visualisation des documents numériques dès que cette application est disponible chez l'utilisateur tout en restant compatible avec ceux ne possédant pas cette application locale.
Ainsi, il est prévu de modifier l'information contenue dans la notification lors de sa visualisation en fonction de la présence ou non de l'application locale chez le destinataire.
En pratique, la notification comprend, en outre, une page en langage de balisage contenant au moins un identifiant désignant le document numérique, et une adresse distante désignant un serveur distant.
Selon une réalisation, le procédé comprend en outre, à l'issue de l'étape ii) et avant l'étape iii), l'étape iia) dans laquelle, en cas d'application locale présente et inactive, il est prévu de procéder à l'activation de l'application locale à la suite d'une autorisation de l'utilisateur du dispositif client destinataire accordée en réponse à une commande exécutable choisie.
En variante, à l'issue de l'étape ii) et avant l'étape iii), le procédé comprend en outre l'étape iib) dans laquelle, en cas d'application locale présente et inactive, il est prévu de procéder automatiquement à l'activation de l'application locale conformément à une commande exécutable choisie.
Selon une autre réalisation, le procédé comprend en outre, après l'étape iii), l'étape iv) dans laquelle, en cas d'application locale présente et active, il est prévu de vérifier la présence du document dans un serveur local, et en cas de vérification négative de rechercher ledit document dans le réseau, de le télécharger en cas de recherche positive, et de le sauvegarder localement avant de le servir en réponse à la requête d'accès.
Selon une autre réalisation, en cas d'application locale présente et active, il est prévu d'adapter localement la page en langage de balisage de manière à accéder au document à partir de l'adresse d'un serveur local. En pratique, l'adaptation de la page comprend le positionnement d'une variable de pointage en langage de balisage sur l'adresse d'un serveur local.
Selon encore une autre réalisation, en cas d'application locale absente ou inactive, il est prévu d'adapter localement la page en langage de
<Desc/Clms Page number 5>
balisage de manière à accéder au document à partir de l'adresse d'un serveur distant. En pratique, l'adaptation de la page comprend le positionnement d'une variable de pointage en langage de balisage sur l'adresse d'un serveur distant.
En pratique, le réseau de communication est de type poste à poste, centralisé, décentralisé ou hybride.
Par exemple, la page est écrite en langage de balisage de type HTML ou analogue, la ou les commandes incluses dans la page en langage de balisage faisant appel à un programme local du type activeX ou analogue, apte à déterminer la présence et l'activation d'un serveur local, ainsi qu'à récupérer les paramètres de configuration dudit serveur local.
Par exemple, la ou les commandes exécutables sont de type programme Script tel que Java Script ou VB Script, la ou lesdites commandes étant embarquées dans la page ainsi notifiée.
Par exemple, l'adresse locale désignant un serveur local est déterminée par le programme Script apte à récupérer les paramètres de configuration dudit serveur local.
La commande comprend en outre une fonction apte à pointer une adresse locale ou distante permettant d'accéder au document.
En pratique, la page est notifiée en attachement avec un courrier électronique.
Selon une variante de réalisation, la page est téléchargée sur un serveur distant choisi et une référence à cette page est envoyée à tout destinataire à notifier, la référence de la page étant, par exemple, de type URL, incluse dans un courrier électronique.
La présente invention a également pour objet un procédé de partage d'un document numérique dans un réseau de communication reliant des dispositifs clients entre eux, ledit procédé étant mis en oeuvre au sein d'un dispositif client émetteur.
Selon un autre aspect de l'invention, le procédé comprend l'étape suivante : - émettre à destination d'au moins un dispositif client destinataire une notification indiquant la présence d'au moins un document numérique
<Desc/Clms Page number 6>
disponible sur le réseau, ladite notification comprenant au moins une commande exécutable apte à détecter si le dispositif client destinataire comprend une application locale susceptible de traiter le document numérique, et en cas d'application locale présente et active, à accéder au document à partir de l'adresse d'un serveur local sinon à accéder au document à partir de l'adresse d'un serveur distant.
La présente invention a également pour objet un dispositif d'accès à au moins un document numérique apte à mette en #uvre le procédé d'accès selon l'invention.
De même, la présente invention a également pour objet un dispositif de partage d'un document numérique apte à mettre en #uvre le procédé de partage mentionné ci avant.
La présente invention a également pour objet un support d'informations lisible par un système informatique, éventuellement amovible totalement ou partiellement, notamment CD-ROM ou support magnétique, tel un disque dur ou une disquette, ou support transmissible, tel un signal électrique ou optique, caractérisé en ce qu'il comporte des instructions d'un programme d'ordinateur permettant la mise en #uvre du procédé conforme à l'invention, lorsque le programme est chargé et exécuté par un système informatique.
Enfin, la présente invention a également pour objet un programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant la mise en #uvre d'un procédé au traitement conforme à l'invention, lorsque ce programme est chargé et exécuté par un système informatique.
D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description détaillée ci-après et des dessins dans lesquels : - la figure 1 représente schématiquement les éléments essentiels d'un dispositif client destinataire apte à mettre en #uvre le procédé d'accès selon l'invention ; - la figure 2 représente schématiquement un réseau de communication reliant des dispositifs clients entre eux selon l'invention ;
<Desc/Clms Page number 7>
- la figure 3 est un organigramme illustrant les étapes relatives à la visualisation d'une page en langage de balisage selon l'invention ; - la figure 4 est un organigramme illustrant les étapes relatives à la vérification de l'activation de l'application locale selon l'invention ;et - la figure 5 est un organigramme illustrant le comportement d'un serveur local selon l'invention.
En référence à la figure 1, un appareil mettant en #uvre l'invention est par exemple un micro ordinateur 10 ou une station de travail connectée à différents éléments périphériques tels que par exemple une caméra numérique 11 (ou un scanner, ou tout autre moyen d'acquisition ou de stockage de documents numériques tels que par exemple des images) relié à une carte d'entrée/sortie (non représentée) et fournissant à l'appareil des données multimédia.
L'appareil 10 comporte un bus de communication 101 auquel sont reliés plusieurs éléments tels que : - une unité centrale de traitement 102 (microprocesseur, noté CPU sur la figure 1) ; - une mémoire morte 103 pouvant comporter des programmes suivant l'invention ; - une mémoire vive 104, qui après la mise sous tension, contient le code exécutable du procédé suivant l'invention ainsi que des registres adaptés à enregistrer des variables et paramètres nécessaires à la mise en #uvre de l'invention ; - un écran 105 permettant de visualiser des données et/ou de servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier 106 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 107 ou un crayon optique (non représenté) ; - un disque dur 108 pouvant comporter les programmes selon l'invention ainsi que des données utilisées ou produites lors de la mise en #uvre de l'invention ;
<Desc/Clms Page number 8>
- un lecteur de disquettes 109 adapté à recevoir une disquette 12 et à lire ou à y écrire des données traitées ou à traiter selon l'invention ; et - une interface de communication 110 reliée à un réseau de communication 13, l'interface étant apte à transmettre et à recevoir des données.
Dans le cas de données audio, l'appareil 10 peut comprendre en outre une carte entrée/sortie (non représentée) reliée à un microphone 14.
Le bus de communication 101 permet la communication et l'interopérabilité entre les différents éléments inclus dans l'appareil 10 ou relié à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément de l'appareil 10 directement ou par l'intermédiaire d'un autre élément de l'appareil 10.
Les disquettes 12 peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) réinscriptible ou non, un disque ZIP ou une carte mémoire.
D'une manière générale, un moyen de stockage d'information, lisible par un micro-ordinateur ou par un microprocesseur, intégré ou non à l'appareil, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en #uvre du procédé selon l'invention.
Le code exécutable, permettant à l'appareil la mise en #uvre de l'invention, peut se trouver indifféremment stocké en mémoire morte 103, sur le disque dur 108 ou sur un support numérique amovible tel que par exemple une disquette 12 telle que décrite précédemment.
Selon une variante, le code exécutable des programmes peut être reçu par l'intermédiaire du réseau de communication 13, via l'interface 110, pour être stocké dans un des moyens de stockage de l'appareil 10 avant d'être exécuté (tel que le disque dur 108 par exemple).
L'unité centrale 102 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programmes selon
<Desc/Clms Page number 9>
l'invention, instructions qui sont stockées dans l'un des moyens de stockage précités.
Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 108 ou la mémoire morte 103, sont transférés dans la mémoire vive 104 (RAM) qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en #uvre de l'invention.
Il convient de noter que l'appareil comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique (ASIC).
En référence à la figure 2, un réseau de communication 13 relie entre eux plusieurs dispositifs clients ou terminaux, individualisés en client1 21, client2 22, et client3 23. Chaque dispositif client peut être relié au réseau 13 par des moyens de communications différents tels que des moyens de communication haut débit ou bas débit (modem xDSL, PSTN ou câble). Le réseau 13 peut tout aussi bien être constitué au-dessus du réseau Internet qu'au-dessus d'un réseau local privé (de l'anglais Local Area Network (LAN) ) ou d'une combinaison des deux.
Les terminaux des dispositifs clients se décomposent en deux catégories distinctes. Il s'agit soit de terminaux munis de l'application P2P pair-à-pair dédiée (client2 et client1 ) soit de terminaux non munis de cette application P2P pair-à-pair dédiée (client3).
Les terminaux munis de l'application P2P pair-à-pair dédiée forment entre eux un réseau de communication de type P2P pair-à-pair au travers du réseau de communication 13 et suivant une des topologies connus de l'homme du métier (centralisé, décentralisé avec ou sans serveur central superpeers ou encore hybrides).
L'application P2P pair-à-pair comporte au moins un module serveur portant la référence 218 dans le dispositif client 21 ou la référence 228
<Desc/Clms Page number 10>
dans le dispositif client 22. L'application P2P comprend en outre un moyen de stockage ou cache 217, 226.
Le module serveur 218 ou 228 est chargé de répondre aux requêtes d'accès aux ressources pair-à-pair . Les requêtes peuvent provenir aussi bien d'applications distantes que d'applications présentes sur la même machine que le serveur.
Les requêtes peuvent être aussi bien reçues suivant un protocole propriétaire propre à l'application pair-à-pair que suivant le protocole HTTP (de l'anglais Hyper Text Transfer Protocol ) communément utilisé sur l'Internet.
Le moyen de stockage 217, 226 contient les contenus numériques partagés sur le réseau pair-à-pair à l'aide du module serveur 218,228.
L'application pair-à-pair peut également être complétée par une application locale cliente, dédiée, P2P (219,229) offrant une interface à l'utilisateur lui permettant de rechercher, d'accéder, de visualiser et de partager des contenus numériques sur le réseau pair-à-pair .
Tous les terminaux, qu'ils soient munis ou non de l'application pair-à-pair dédiée, peuvent également utiliser des outils (227,237) capables de visualiser des pages en langage de balisage de type HTML pour accéder aux contenus numériques à l'aide du protocole de communication HTTP.
Un ou plusieurs serveurs proxy/passerelle spécifiques 24 peuvent également être connectés au réseau 13, ces serveurs offrent un point d'entrée sur le réseau pair-à-pair pour les clients ne possédant pas de clients pair-à-pair dédiés et utilisant le protocole de communication HTTP.
Quand ils reçoivent une requête pour une ressource du réseau pair-à-pair , les serveurs proxy 24 déterminent une ou plusieurs machines du réseau pair-à-pair susceptible d'avoir la ressource demandée et se chargent soit de rediriger le demandeur vers une de ces machines, soit de récupérer la ressource auprès d'une de ces machines pour le compte du demandeur pour ensuite la lui servir tel un serveur de type proxy.
<Desc/Clms Page number 11>
Il est à noter que ce rôle de serveur proxy/passerelle peut également être tenu par les dispositifs clients eux-mêmes s'ils ont l'application dédiée pair-à-pair comme, par exemple, les dispositifs clients 1 et 2 respectivement numérotés 21 et 22.
Suivant l'invention, si l'utilisateur connecté sur la machine 21 souhaite partager une nouvelle collection de contenus numériques composée des images individualisées en image1, image2 et image3 présentes sur son disque 217 avec les clients 22 et 23, il utilise l'application locale P2P 219 pour créer et partager une nouvelle collection composée de ces trois images.
Durant le partage, l'application locale P2P 219 associe à chaque image un identifiant unique Imagel ID, Image2 ID, Image3 ID. Des outils bien connus de l'homme de l'art permettent de générer des identifiants avec une infime probabilité de duplication.
Après l'opération de partage proprement dite et propre à l'application pair-à-pair , l'application locale P2P 219 génère une page en langage de balisage HTML 25 décrivant la nouvelle collection afin de notifier les clients 22 et 23 qu'une nouvelle collection de contenus numériques est disponible sur le réseau. Cette page HTML contient au moins des scripts 252 tels que par exemple des javaScripts et une référence pour chacun des identifiants de contenus numériques nouvellement partagés 253.
Une fois que la page HTML 25 a été générée, l'utilisateur peut envoyer cette page à toutes les personnes qu'il souhaite notifier de l'existence des nouveaux contenus numériques partagés (dans notre exemple le client2 et client3).
Dans le mode de réalisation préféré, l'utilisateur envoie la page HTML 25 en la mettant en attachement à un courrier électronique.
Dans un autre mode de réalisation, l'utilisateur télécharge la page HTML 25 sur un serveur tel que le serveur 24. En outre, l'utilisateur envoie une référence désignant cette page HTML sur ledit serveur à toutes les personnes qu'il souhaite notifier, par exemple sous la forme d'une URL incluse dans un
<Desc/Clms Page number 12>
courrier électronique. Les destinataires téléchargent la page HTML 25 à partir du serveur 24 à l'aide de la référence (ladite URL) reçue en notification.
L'utilisateur peut aussi bien utiliser tout autre moyen permettant de transmettre la page HTML à des destinataires (par exemple en utilisant un système d'échange de fichier pair-à-pair , en envoyant par la poste une disquette contenant la page HTML, ...).
Quand la page HTML 25 est reçue et affichée par les destinataires à l'aide des applications 227 et 237, c'est-à-dire un navigateur Internet, un lecteur de courrier électronique ou toute autre application capable d'interpréter et d'afficher une page HTML, le contenu de la page est interprété et les codes exécutables (scripts) contenu dans la page sont exécutés.
Un premier code est chargé de déterminer si l'application locale P2P pair-à-pair dédiée est installée.
Si l'application dédiée est installée, le premier code récupère à l'aide d'un deuxième code externe à la page HTML (ex : activeX) des informations de configuration sur l'application pair-à-pair telles que par exemple les numéros de ports réseaux utilisés par l'application. Puis, le premier code initialise des variables qui sont utilisées par un troisième code embarqué dans la page HTML 25 et chargé de générer les adresses URL à utiliser pour accéder aux contenus numériques.
Le troisième code est appelé lors de l'interprétation de la page HTML pour chacune des références sur les contenus numériques partagés. Si le serveur local pair-à-pair 228 a été détecté par le premier code comme installé et actif, le troisième code retourne du code HTML dont les URLs sont dirigées vers le serveur local pair-à-pair (cas C1 pour le client 2 sur la figure 2). Les URLs retournées pourront être de la forme http://localhost:80/RUID où RUID représente l'identifiant unique de la ressource partagée.
Si le serveur local pair-à-pair 228 n'est pas présent sur la machine 22 ou n'est pas actif, le troisième code retourne du code HTML dont les URLs sont dirigées vers un serveur distant prédéfini offrant une passerelle
<Desc/Clms Page number 13>
entre des requêtes web http et le réseau pair-à-pair tel que par exemple le serveur proxy/passerelle web/ pair-à-pair 24 (cas du client 3 et cas C2 pour le client 2 sur la figure 2).
Les URLs retournées peuvent être de la forme http://www.server.com/RUID où www. server.com représente l'adresse web du serveur 24 et RUID représente l'identifiant unique de la ressource partagée.
L'invention permet ainsi d'adapter le contenu de la notification (page HTML 25) selon que le destinataire possède ou non l'application pair-àpair .
Dans notre exemple, le dispositif client3 23 ne possède pas l'application pair-à-pair . Dans son cas, tous les accès sur les contenus numériques partagés sont donc dirigés vers le serveur proxy 24.
Par contre, pour le dispositif client2 22 les accès aux contenus numériques sont dirigés vers son serveur pair-à-pair 228 s'il est actif (cas C1) et vers le serveur proxy 24 s'il est inactif (cas C2).
Les avantages d'utiliser le serveur pair-à-pair dès qu'il est disponible sont notamment le fait de ne pas faire des accès réseaux si les données sont déjà présentes dans le cache du serveur pair-à-pair . De plus, si les contenus numériques sont accédés au travers du serveur local pair-àpair , lesdits contenus sont alors présents dans le cache du serveur et peuvent ainsi être servis à des machines distantes en retour. On augmente ainsi le nombre de machines dans le réseau pair-à-pair pouvant servir un contenu numérique donné. Les machines pouvant être à tout moment déconnectées, on augmente ainsi la probabilité de trouver un contenu numérique donné dans le réseau à tout instant.
En référence à la figure 3, on a représenté un organigramme illustrant le comportement du script chargé de déterminer si un serveur local pair-à-pair est présent et actif sur la machine.
Ce script est intégré à la page HTML 25 soit sous la forme d'un script 252 délimité par les balises HTML <SCRIPT LANGUAGE=###> et
<Desc/Clms Page number 14>
</SCRIPT> où ### indique le langage utilisé ou soit sous la forme d'une référence à un fichier externe.
Le script est interprété et exécuté à chaque affichage de la page HTML.
A l'étape E302, le script commence par vérifier si l'application pair-à-pair est installé ou non sur la machine. Pour cela, il cherche à détecter la présence d'un programme activeX ou d'un module d'extension (plug-in) faisant partie de l'application pair-à-pair .
Par exemple, si le programme à détecter est un activeX, il peut appeler la fonction définie par le programme VBscript suivant : <SCRIPT LANGUAGE="VBscript"> <!-Function detectActiveXControl(activeXControlName) on error resume next detectActiveXControl = False detectActiveXControl = isObject (CreateObject (activeXControlName)) End Function rem --> </SCRIPT>
Cette fonction detectActiveXControl prend en paramètre le nom de l'activeX et retourne True si l'activeX est présent sur la machine et False sinon.
A l'étape E303, si l'application a été détectée comme non présente sur la machine, l'algorithme passe à l'étape E308 et positionne une variable indiquant qu'il faut utiliser dans la suite du traitement de la page HTML des URLs dirigées vers le serveur distant 24.
Si au contraire, l'application P2P a été détectée, le script détermine à l'étape E304 si le serveur local pair-à-pair 228 est actuellement actif (c'est-à-dire en cours d'exécution) ou non. Pour cela, il utilise le programme activeX détecté à l'étape précédente pour récupérer la configuration courante du serveur pair-à-pair 228 en consultant soit les registres soit un fichier de configuration.
<Desc/Clms Page number 15>
Par exemple, le programme activeX récupère le numéro de port réseau sur lequel le serveur 228 est en écoute. Si celui-ci est inactif, le port vaut zéro. Si la valeur est différente de zéro, à l'étape E309, il positionne une variable contenant le numéro de port sur lequel le serveur 228 est en écoute.
A l'étape E310, le script positionne une variable indiquant qu'il faut utiliser dans la suite du traitement de la page HTML 25 des adresses URLs dirigés vers le serveur local 228 pour accéder aux contenus numériques.
Par exemple si GetRegValue est une fonction de l'activeX MpActiveXVB permettant d'accéder au registre, le programme suivant peut être utilisé pour déterminer si le serveur local est actif ou non et récupérer son numéro de port (étape E304 et E309).
<SCRIPT LANGUAGE="JavaScript"> <!-var IsLocalServerActive = false; var LocalServerPort = 80; function CheckLocalServer() {
LocalServerPort = MpActiveXVB.GetRegValue("SOFTWARE\\LocalServer\\Config\\Lis tenPort}"); if(LocalServerPort ! = 0) { return true; } return false; } IsLocalServerActive = CheckLocalServer(); // --> </SCRIPT>
Si le serveur 228 est détecté comme inactif à l'étape E304, le programme peut inviter l'utilisateur à lancer le serveur local pair-à-pair 228 en lançant une fenêtre de dialogue à l'aide d'une fonction de l'activeX.
<Desc/Clms Page number 16>
Si l'utilisateur accepte la proposition, une fonction de l'activeX est appelée pour lancer le serveur local à l'étape E307.
A l'étape E311, on procède à la suite de l'interprétation de la page HTML 25.
En référence à la figure 4, à chaque fois que la page HTML 25 est analysée par une application telle qu'un navigateur Internet ou un lecteur de courrier électronique (227,237), une fonction javascript embarquée dans la page est appelée pour chaque référence à un contenu numérique afin de retourner l'adresse URL à utiliser pour accéder audit contenu numérique.
L'appel à cette fonction dans la page HTML peut prendre la forme suivante : <SCRIPT LANGUAGE="JavaScript"> GetRessourceAddress('abcde23404-3143492ef-23232', 'blue~mountain.jpg'); </SCRIPT>
La balise (de l'anglais tag ) <SCRIPT LANGUAGE= ###> marque le début d'un code à exécuter dans la page HTML où la valeur ### mentionne la nature du langage utilisé (JavaScript ou VBScript par exemple).
La balise </SCRIPT> indique la fin du code à exécuter.
GetRessourceAddress correspond ici au nom de la fonction JavaScript à appeler. Cette fonction doit être préalablement définie, soit dans un fichier externe dont le nom se termine avec l'extension .js et lui-même référencé dans la page HTML, soit directement en début de page HTML (c'est- à-dire dans l'entête délimité par les balises <HEAD> et </HEAD> dans une section de code JavaScript délimitée par les balises <SCRIPT LANGUAGE="JavaScript"> et </SCRIPT .
Dans le premier cas, si le nom du serveur hébergeant le script est www.server.com et que le fichier contenant la définition de la fonction s'appelle mp.js et se trouve dans le répertoire script sur le serveur, la commande incluant le fichier mp.js dans la page HTML est :
<Desc/Clms Page number 17>
<SCRIPT LANGUAGE="JavaScript" src="http://www.server.com/script/mp.js"></SCRIPT>
La figure 4 décrit le comportement de la fonction javascript GetRessourceAddress chargée de retourner l'adresse URL.
Le code correspondant en JavaScript peut être le suivant : function GetRessourceAddress(resID, title) { if(isLocalServerActif == false) { document.write("<A HREF=http://www.server.com/"); document.write(resID); } else { document.write("<A HREF=http://localhost:"); document.write(localServerHTTPPort); document.write("/"); document.write(resID); } document.write(">"); document.write(title); document.write("</A>"); }
Le mot clé function indique la création d'une nouvelle fonction ayant ici pour nom GetRessourceAddress et ayant pour paramètres deux variables resID et title. JavaScript possède une commande appelée document. write (#) permettant d'afficher des informations en passant cette information notée ici dièse au programme en train d'interpréter la page HTML.
L'information passée doit donc être au format HTML pour être compréhensible par l'interpréteur.
Les mots isLocalServerActif et localServerHTTPPort représente des variables JavaScript préalablement initialisées (figure 3). La première variable indique un serveur local pair-à-pair est actuellement installé et actif sur la machine et la seconde variable indique le numéro de port sur lequel le serveur local pair-à-pair est en attente.
Selon l'invention l'algorithme est donc le suivant :
<Desc/Clms Page number 18>
La fonction JavaScript ici notée GetRessourceAddress avec au moins en paramètres l'identifiant unique de la ressource notée resID est appelée (étape E401) pour chacune des références aux ressources dans la page HTML 25.
A l'étape E402, la fonction vérifie si un serveur local pair-à-pair a été détecté par l'algorithme de la figure 3 en vérifiant la valeur d'une variable notée ici isLocalServerActif.
A l'étape E403, si la variable indique qu'il n'y a pas de serveur local pair-à-pair actuellement actif (la valeur de la variable vaut false), alors la fonction retourne à l'étape E404 une URL permettant d'accéder à la ressource via une adresse prédéfinie correspondant à un serveur de type proxy/passerelle 24 dont le nom pour l'exemple serait www.server.com.
A partir du code de la fonction JavaScript et de l'exemple d'appel décrit précédemment, le code HTML retourné par la fonction est le suivant : <A HREF=http://www.server.com/abcde23404- 3143492ef-23232> 'blue~mountain.jpg'</A>
Ce code représente un lien hypertexte ayant pour nom blue~mountain.jpg et pointant vers l'adresse http://www.server.com/abcde23404-3143492ef-23232.
A l'étape E403, si la variable indique qu'il existe un serveur local pair-à-pair actif sur la machine (la valeur de la variable vaut true), alors la fonction retourne à l'étape E405 une URL permettant d'accéder à la ressource via le serveur local qui joue ici le rôle de proxy (figure 5). Le code HTML retourné par la fonction serait alors : <A HREF=http ://localhost:90/abcde23404-3143492ef- 23232>'blue~mountain.jpg'</A> en supposant que la variable localServerHTTPPort vaut 90.
Dans une autre variante, plutôt que d'appeler la fonction javascript GetRessourceAddress pour chacune des références à un contenu
<Desc/Clms Page number 19>
numérique, ces références peuvent être écrites sous la forme d'une URL relative. Un exemple de code HTML pour une référence peut être alors de la forme suivante : <A HREF=abcde23404-3143492ef-23232> 'blue~mountain.jpg'</A>
L'appel répétitif à la fonction javascript GetRessourceAddress pour chacune des références à un contenu numérique est alors avantageusement remplacé par un appel unique à une routine javascript chargée de définir une balise <BASE> dans l'entête de la page HTML 25. Cette balise définit une URL absolue utilisée comme URL de base pour résoudre les URLs relatives.
La fonction javascript retourne une balise <BASE> pointant sur un serveur de type proxy/passerelle 24 s'il n'y a pas de serveur local pair-à-pair actif sur la machine (la valeur de la variable isLocalServerActif vaut false). Le code HTML retourné par la fonction est alors : <BASE HREF=http://www.server.com/>
La fonction javascript retourne une balise <BASE> pointant sur un serveur local 228 s'il existe un serveur local pair-à-pair actif sur la machine (la valeur de la variable isLocalServerActif vaut true). Le code HTML retourné par la fonction est alors : <BASE HREF=http://localhost:90/> en supposant que la variable localServerHTTPPort vaut 90.
En référence à la figure 5, on a décrit le comportement des serveurs locaux 228 et 218.
Selon l'invention quand le serveur local pair-à-pair reçoit une requête pour un contenu numérique R (E511), il détermine à l'étape E512 si la requête provient d'une application distante (présente sur une autre machine du réseau de communication) ou si la requête provient d'une application locale (s'exécutant sur la même machine que le serveur). Il détermine cette
<Desc/Clms Page number 20>
nformation en examinant l'adresse IP du demandeur et en la comparant à ;hacune de ses propres adresses IP. Si deux adresses sont identiques ou si 'adresse du demandeur est 127. 0.0.1 (adresse loopback), c'est que le jemandeur est local, autrement il s'agit d'un demandeur distant.
Si le demandeur est local, le serveur passe à l'étape E513 et vérifie si la donnée recherchée R n'est pas présente localement sur le disque.
3i la donnée est présente localement, alors elle est envoyée au demandeur étape E517). Si la donnée n'est pas présente localement alors le serveur effectue une recherche de la ressource sur le réseau pair-à-pair suivant des echniques connus de l'homme du métier (étape E514). A l'étape E515, si la tonnée est trouvée sur le réseau alors le serveur télécharge la donnée R à 'étape E516, la sauvegarde localement dans son cache sur le disque et la "etourne au demandeur à l'étape E517. Dans le cas contraire, le serveur ^etourne une erreur à l'étape E518 au demandeur pour lui signaler que la tonnée n'est pas disponible.
Si le demandeur est distant, le serveur vérifie à l'étape E519 si la 'essource est disponible localement sur son disque.
Si la donnée est disponible, elle est retournée au demandeur à 'étape E520. Dans le cas contraire, il vérifie à l'étape E521 si la requête est une 'equête WEB provenant par exemple d'un navigateur Internet (sous la forme j'une URL http://y/x où [x] est le chemin d'accès à la ressource sur la machine dentifiée par [y], ou encore sous la forme d'un en-tête particulier dans la ^equête) ou s'il s'agit d'une requête suivant un protocole propriétaire :< pair-à-pair .
S'il s'agit d'une requête WEB, le serveur procède alors à une ^echerche de la donnée sur le réseau pair-à-pair à l'étape E522. On ^etrouve ici le comportement de proxy/passerelle de la machine 24.
A l'étape E523, si la ressource est localisée dans le réseau pair- à-pair le serveur ne télécharge pas la ressource mais au contraire redirige à 'étape E524 le demandeur vers la machine ayant la ressource recherchée à
<Desc/Clms Page number 21>
l'aide d'un ordre de redirection ( forward en anglais) dont une forme simple avec le protocole HTTP serait :
HTTP/1.1 302 See other URI
Location : http://nnn/zzz
Le premier mot clé http/1.1 permet d'indiquer le type et la version du protocole. 302 est une valeur d'erreur particulière indiquant que la ressource n'est pas disponible temporairement sur le serveur. Un commentaire pouvant être affiché suit ce code d'erreur. Location : est le deuxième mot clé indiquant au navigateur Internet de se rediriger sur un autre URI. [nnn] est l'adresse de la machine à contacter pour obtenir la ressource et [zzz] est le chemin d'accès à la ressource sur la machine [nnn].
A l'étape E523, si la ressource n'est pas localisée dans le réseau pair-à-pair , le serveur redirige à l'étape E525 le demandeur vers une machine prédéterminée à l'aide d'un ordre de redirection similaire au précédent.
Cette machine prédéterminée est chargée de traiter les cas où la ressource demandée n'est pas disponible en retournant par exemple une réponse prédéterminée invitant l'utilisateur à renouveler sa requête ultérieurement par exemple.
Si à l'étape E521, il ne s'agit pas d'une requête WEB provenant d'un navigateur Internet mais d'une requête provenant d'une application pair-à-pair dédiée alors le serveur retourne une erreur au demandeur.
Par exemple la page HTML peut avoir la teneur suivante : <HTML> <HEAD> <SCRIPT LANGUAGE="VBscript"> <!-detectableWithVB = False If ScriptEngineMajorVersion ≥ 2 then detectableWithVB = True End If Function detectActiveXControl(activeXControlName) on error resume next detectActiveXControl = False
<Desc/Clms Page number 22>
If detectableWithVB Then detectActiveXControl = IsObject(CreateObject(activeXControlName))
End If End Function rem --> </SCRIPT> <SCRIPT LANGUAGE="JavaScript"> <!-- var pluginFound = false; pluginFound = detectActiveXControl('MpActiveXVB.MpRegistry'); alert('MpActiveXVB found = ' + pluginFound); if (pluginFound) { // Insert référence to activeX in HTML page document.write("<OBJECT ID="); document.write('\"MpActiveXVB\"'); document.write("CLASSID="); document.write('\"CLSID:443E61FC-4AC1-49EC-A89AF99EA5EE72A2\">'); document.writeln("</OBJECT>");
Figure img00220001

// --> </SCRIPT> </HEAD> <BODY> <SCRIPT LANGUAGE="JavaScript"> <!-- var isLocalServerActif = false; var localServerHTTPPort = 80 ; function CheckServer() { if (pluginFound) { isLocalServerActif = MpActiveXVB.GetRegValue("SOFTWARE\\Classes\\CLSID\\{443E61F C-4AC1-49EC-A89A-F99EA5EE72A2}"); if(isLocalServerActif == false) { alert('Server Not Found'); } else { localServerHTTPPort = MpActiveXVB.GetRegValue("SOFTWARE\\localserver\\config\\por t"); alert('Server Port Value : ' localServerHTTPPort); }
<Desc/Clms Page number 23>
function GetRessourceAddress (imageID, title) { document.writeln(""); document.writeln("Process the image ID..."); if(isLocalServerActif == false) { document.write("<A HREF=http://www.server.com/"); } else { document.write("<A HREF=http://localhost:"); document.write(localServerHTTPPort); document.write("/"); } document.write(imageID); document.write("><IMG SRC=") ; document.write(title); document.write("BORDER=0 ALT="); document.write(title); document.writeln("></A>"); } CheckServer (); // --> </SCRIPT> <NOSCRIPT> <Hl>No JavaScript</Hl> You see this text if JavaScript is disabled or unimplemented.
</NOSCRIPT> <SCRIPT LANGUAGE="JavaScript"> GetRessourceAddress ('abcde23404-3143492ef-23232', 'blue~mountain.jpg'); GetRessourceAddress ('fffffeeeaa-bbe478999-aaaaa', 'red~mountain.jpg'); </SCRIPT> </BODY> </HTML>
Parmi les nombreux avantages conférés par la présente invention, il est possible de mettre en exergue qu'il n'est pas nécessaire d'adapter le contenu de la notification selon les capacités des destinataires, c'est-à-dire selon qu'il possède ou non l'application locale P2P dédiée. De plus, l'accès local ou distant est totalement transparent pour l'utilisateur. De même, il n'est
<Desc/Clms Page number 24>
pas nécessaire de modifier la configuration Internet de l'utilisateur (en l'occurrence les adresses du dispositif serveur mandataire ou proxy). Enfin, les dispositifs clients possédant l'application P2P n'ont pas l'obligation de garder leur serveur local actif pour pouvoir afficher le contenu d'une notification reçue par courrier électronique, l'affichage de la notification s'adaptant automatiquement en fonction de la présence/absence d'un serveur local.

Claims (35)

REVENDICATIONS
1. Procédé d'accès à au moins un document numérique disponible dans un réseau de communication (13) reliant des dispositifs clients (21, 22,23) entre eux, ledit procédé d'accès étant mis en oeuvre au sein d'un dispositif client destinataire (22,23) ledit procédé comprenant les étapes suivantes : -i) recevoir une notification (25) indiquant la présence d'au moins un document numérique disponible sur le réseau (13), ladite notification (25) comprenant au moins une commande exécutable apte à détecter si le dispositif client destinataire comprend une application locale susceptible de traiter le document numérique, -ii) exécuter la ou les commandes afin de détecter la présence et l'activation de l'application locale, et -iii) en cas d'application locale présente et active, accéder au document numérique à partir d'un serveur local (228) tandis qu'en cas d'absence ou d'inactivité de l'application locale, accéder au document à partir de l'adresse d'un serveur distant (24).
2. Procédé selon la revendication 1, caractérisé en ce que la notification (25) comprend, en outre, au moins une page en langage de balisage contenant au moins un identifiant désignant le document numérique, et une adresse distante désignant un serveur distant (24).
3. Procédé selon la revendication 1 ou la revendication 2, caractérisé en ce qu'il comprend en outre, à l'issue de l'étape ii) et avant l'étape iii), l'étape iia) dans laquelle, en cas d'application locale présente et inactive, il est prévu de procéder à l'activation de l'application locale à la suite d'une autorisation de l'utilisateur du dispositif client destinataire accordée en réponse à une commande exécutable choisie.
<Desc/Clms Page number 26>
4 Procédé selon la revendication 1 ou la revendication 2, caractérisé en ce qu'il comprend en outre, à l'issue de l'étape ii) et avant l'étape iii), l'étape iib) dans laquelle, en cas d'application locale présente et inactive, il est prévu de procéder automatiquement à l'activation de l'application locale conformément à une commande exécutable choisie.
5 Procédé selon la revendication 1 ou la revendication 2, caractérisé en ce qu'il comprend en outre, après l'étape iii), l'étape iv) dans laquelle, en cas d'application locale présente et active, il est prévu de vérifier la présence du document dans un serveur local (228), et en cas de vérification négative de rechercher ledit document dans le réseau (13), de le télécharger en cas de recherche positive, et de le sauvegarder localement avant de le servir.
6. Procédé selon la revendication 2, caractérisé en ce que lors d'une application locale présente et active, il est prévu d'adapter localement la page (25) en langage de balisage de manière à accéder au document à partir de l'adresse d'un serveur local (228).
7. Procédé selon la revendication 6, caractérisé en ce que l'adaptation de la page (25) comprend le positionnement d'une variable de pointage en langage de balisage sur l'adresse d'un serveur local (228).
8. Procédé selon la revendication 2, caractérisé en ce que lors d'une application locale absente ou inactive, il est prévu d'adapter localement la page (25) en langage de balisage de manière à accéder au document à partir de l'adresse d'un serveur distant (24).
<Desc/Clms Page number 27>
9. Procédé selon la revendication 8, caractérisé en ce que 'adaptation de la page (25) comprend le positionnement d'une variable de pointage en langage de balisage sur l'adresse d'un serveur distant (24).
10 Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que le réseau de communication (13) est de type pair à pair, centralisé, décentralisé ou hybride.
11 Procédé selon la revendication 2, caractérisé en ce que le langage de balisage de la page (25) est de type HTML ou analogue.
12. Procédé selon la revendication 11, caractérisé en ce que la ou les commandes exécutables sont de type programme Script tel que java script ou VBscript, la ou les commandes exécutables étant embarquées dans la page ainsi notifiée, et ladite page étant interprétée lors de l'étape ii).
13. Procédé selon la revendication 12, caractérisé en ce que l'adresse locale désignant un serveur local (228) est déterminée par le programme Script apte à récupérer les paramètres de configuration dudit serveur local.
14. Procédé selon la revendication 12, caractérisé en ce que la ou les commandes incluses dans la page (25) en langage de balisage font appel à un programme local du type activeX ou analogue, apte à déterminer la présence et l'activation du serveur local, ainsi qu'à récupérer les paramètres de configuration dudit serveur local.
15. Procédé selon la revendication 13 ou la revendication 14, caractérisé en ce que la ou les commandes comprennent en outre une fonction
<Desc/Clms Page number 28>
apte à pointer une adresse locale (228) ou distante (24) permettant d'accéder au document.
16. Procédé selon la revendication 12, caractérisé en ce que la page (25) est notifiée en attachement avec un courrier électronique.
17. Procédé selon la revendication 2, caractérisé en ce que la page (25) est téléchargée sur un serveur distant choisi (24), et en ce qu'une référence à cette page est envoyée à tout destinataire à notifier.
18. Procédé selon la revendication 16 et la revendication 17, caractérisé en ce que la référence de la page (25) est de type URL, incluse dans un courrier électronique.
19. Procédé de partage d'un document numérique dans un réseau de communication (13) reliant des dispositifs clients (21,22, 23) entre eux, ledit procédé étant mis en #uvre au sein d'un dispositif client émetteur (21), ledit procédé comprenant l'étape suivante : émettre à destination d'au moins un dispositif client destinataire (22,23) une notification indiquant la présence d'au moins un document numérique disponible sur le réseau, ladite notification comprenant au moins une commande exécutable apte à détecter si le dispositif client destinataire comprend une application locale susceptible de traiter le document numérique, et en cas d'application locale présente et active, à accéder au document à partir de l'adresse d'un serveur local (228) sinon à accéder au document à partir de l'adresse d'un serveur distant (24).
20. Procédé de partage selon la revendication 19, caractérisé en ce que la notification comprend, en outre, une page (25) en langage de
<Desc/Clms Page number 29>
balisage contenant au moins un identifiant désignant le document numérique et une adresse distante désignant un serveur distant (24).
21. Dispositif d'accès à au moins un document numérique disponible dans un réseau de communication (13) reliant des dispositifs clients entre eux (21,22, 23), ledit dispositif d'accès étant intégré au sein d'un dispositif client destinataire (22,23), ledit dispositif d'accès étant caractérisé en ce qu'il comprend : des moyens de réception (227), aptes à recevoir une notification indiquant la présence d'au moins un document numérique disponible sur le réseau, ladite notification comprenant au moins une commande exécutable apte à détecter si le dispositif client destinataire comprend une application locale susceptible de traiter le document numérique, - des moyens d'exécution (227) aptes à exécuter la commande afin de détecter la présence et l'activation de l'application locale, et - des moyens de traitement (227,228) aptes, en cas d'application locale présente et active, à accéder au document numérique à partir d'un serveur local, tandis qu'en cas d'absence ou d'inactivité de l'application locale, à accéder au document à partir d'un serveur distant.
22. Dispositif selon la revendication 21, dans lequel la notification comprend, en outre, au moins une page (25) en langage de balisage contenant au moins un identifiant désignant le document numérique et une adresse distante désignant un serveur distant (24).
23. Dispositif selon la revendication 22, caractérisé en ce que lors d'application locale présente et active, les moyens de traitement (227,228) sont aptes à adapter localement la page (25) en langage de balisage de manière à accéder au document à partir de l'adresse du serveur local (228).
<Desc/Clms Page number 30>
24. Dispositif selon la revendication 22, caractérisé en ce que les moyens de traitement (227,228) sont aptes à positionner une variable de pointage en langage de balisage sur l'adresse du serveur local (228).
25. Dispositif selon les revendications 22 à 24, caractérisé en ce qu'en cas d'application locale (229) absente ou inactive, les moyens de traitement (227,228) sont aptes à adapter localement la page (25) en langage de balisage de manière à accéder au document à partir de l'adresse du serveur distant (24).
26. Dispositif selon la revendication 25, caractérisé en ce que les moyens de traitement (227,228) sont aptes à positionner une variable de pointage en langage de balisage sur l'adresse du serveur distant (24).
27. Dispositif selon l'une quelconque des revendications 21 à 26, caractérisé en ce que le réseau de communication (13) est de type pair à pair, centralisé, décentralisé ou hybride.
28. Dispositif selon la revendication 22, caractérisé en ce que la page (25) est en langage de balisage de type HTML.
29. Dispositif selon la revendication 28, caractérisé en ce que la ou les commandes sont de type programme script tel que javascript ou VBscript, la ou lesdites commandes étant embarquées dans la page (25) ainsi notifiée et ladite page étant interprétée.
<Desc/Clms Page number 31>
30. Dispositif selon la revendication 29, caractérisé en ce que la commande comprend en outre une fonction apte à pointer une adresse locale (228) ou distante (24) permettant d'accéder au document.
31. Dispositif selon la revendication 22, caractérisé en ce que la page (25) est notifiée en attachement avec un courrier électronique, le dispositif étant en outre équipé d'un logiciel de traitement de courrier électronique (227).
32 Dispositif de partage d'un document numérique dans un réseau de communication (13) reliant des dispositifs clients (21,22, 23) entre eux, ledit dispositif de partage étant intégré au sein d'un dispositif client émetteur (21), caractérisé en ce qu'il comprend des moyens d'émission aptes à émettre à destination d'au moins un dispositif client destinataire (22,23) une notification indiquant la présence d'au moins un document numérique disponible sur le réseau, ladite notification comprenant au moins une commande exécutable apte à détecter si le dispositif client destinataire comprend une application locale (229) susceptible de traiter le document numérique, et en cas d'application locale présente et active, à accéder au document à partir de l'adresse d'un serveur local sinon à accéder au document à partir de l'adresse d'un serveur distant.
33. Dispositif de partage selon la revendication 32, caractérisé en ce que la notification comprend, en outre, une page (25) en langage de balisage contenant au moins un identifiant désignant le document numérique et une adresse distante désignant un serveur distant (24).
34. Support d'informations lisible par un système informatique, éventuellement amovible, totalement ou partiellement, notamment CD-ROM ou support magnétique, tel un disque dur ou une disquette, ou support transmissible, tel un signal électrique ou optique, caractérisé en ce qu'il
<Desc/Clms Page number 32>
comporte des instructions d'un programme d'ordinateur permettant la mise en #uvre du procédé selon l'une quelconque des revendications 1 à 18, ou 20 à 21, lorsque ce programme est chargé et exécuté par un système informatique.
35. Programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant la mise en #uvre d'un procédé de traitement selon l'une quelconque des revendications 1 à 18, ou 20 à 21, lorsque le programme est chargé et exécuté par un système informatique.
FR0308807A 2003-07-18 2003-07-18 Procede d'acces et de partage d'un document numerique dans un reseau de communication p2p Pending FR2857763A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR0308807A FR2857763A1 (fr) 2003-07-18 2003-07-18 Procede d'acces et de partage d'un document numerique dans un reseau de communication p2p
EP04291807.8A EP1499089B1 (fr) 2003-07-18 2004-07-15 Procédé d'accès et partage d'un document numérique dans un réseau de communication pair à pair
US10/893,012 US7716302B2 (en) 2003-07-18 2004-07-16 Method of accessing and sharing a digital document in P2P communication network
JP2004210101A JP2005122693A (ja) 2003-07-18 2004-07-16 P2p通信ネットワーク上におけるデジタル文書アクセス方法及びシェア方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0308807A FR2857763A1 (fr) 2003-07-18 2003-07-18 Procede d'acces et de partage d'un document numerique dans un reseau de communication p2p

Publications (1)

Publication Number Publication Date
FR2857763A1 true FR2857763A1 (fr) 2005-01-21

Family

ID=33462563

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0308807A Pending FR2857763A1 (fr) 2003-07-18 2003-07-18 Procede d'acces et de partage d'un document numerique dans un reseau de communication p2p

Country Status (4)

Country Link
US (1) US7716302B2 (fr)
EP (1) EP1499089B1 (fr)
JP (1) JP2005122693A (fr)
FR (1) FR2857763A1 (fr)

Families Citing this family (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2860935B1 (fr) * 2003-10-09 2006-03-03 Canon Kk Procede et dispositif de traitement de donnees numeriques
JP4328806B2 (ja) * 2003-11-14 2009-09-09 キヤノン株式会社 ピアツーピア通信ネットワーク内のデジタルドキュメントにアクセスし、または共有するシステム、方法及び装置
FR2863127A1 (fr) * 2003-12-02 2005-06-03 Canon Kk Procedes et dispositifs pour la delivrance asynchrone 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
FR2870022B1 (fr) 2004-05-07 2007-02-02 Canon Kk Procede et dispositif de distribution de donnees numeriques notamment pour reseau pair-a-pair
US8316088B2 (en) * 2004-07-06 2012-11-20 Nokia Corporation Peer-to-peer engine for object sharing in communication devices
US11734393B2 (en) 2004-09-20 2023-08-22 Warner Bros. Entertainment Inc. Content distribution with renewable content protection
US20060064386A1 (en) * 2004-09-20 2006-03-23 Aaron Marking Media on demand via peering
US7664516B2 (en) * 2004-12-27 2010-02-16 Aztec Systems, Inc. Method and system for peer-to-peer advertising between mobile communication devices
US10354280B2 (en) 2004-12-27 2019-07-16 Blue Calypso, Llc System and method for distribution of targeted advertising between mobile communication devices
US8452646B2 (en) 2005-12-23 2013-05-28 Blue Calypso, Llc System and method for providing endorsed electronic offers between communication devices
US8155679B2 (en) * 2005-12-23 2012-04-10 Blue Calypso, Llc System and method for peer-to peer advertising between mobile communication devices
US9314697B2 (en) 2013-07-26 2016-04-19 Blue Calypso, Llc System and method for advertising distribution through mobile social gaming
US10755313B2 (en) 2004-12-27 2020-08-25 Andrew Levi System and method for distribution of targeted content between mobile communication devices
US20060193265A1 (en) * 2005-02-25 2006-08-31 Microsoft Corporation Peer-to-peer name resolution protocol with lightweight traffic
US20060212584A1 (en) * 2005-03-15 2006-09-21 Qian Xiang Shi Ji (Beijing) Technology Development Co. Ltd. Method and system for accelerating downloading of web page content by a peer-to-peer network
US7697520B2 (en) * 2005-04-12 2010-04-13 Tiversa, Inc. System for identifying the presence of Peer-to-Peer network software applications
US9178940B2 (en) * 2005-04-12 2015-11-03 Tiversa Ip, Inc. System and method for detecting peer-to-peer network software
USRE47628E1 (en) * 2005-04-12 2019-10-01 Kroll Information Assurance, Llc System for identifying the presence of peer-to-peer network software applications
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
US7734589B1 (en) 2005-09-16 2010-06-08 Qurio Holdings, Inc. System and method for optimizing data uploading in a network based media sharing system
US7747574B1 (en) 2005-09-19 2010-06-29 Qurio Holdings, Inc. System and method for archiving digital media
US9141825B2 (en) * 2005-11-18 2015-09-22 Qurio Holdings, Inc. System and method for controlling access to assets in a network-based media sharing system using tagging
US7836016B2 (en) * 2006-01-13 2010-11-16 International Business Machines Corporation Method and apparatus for disseminating new content notifications in peer-to-peer networks
US20110137986A1 (en) * 2009-12-08 2011-06-09 Wolf Edward O'brien Accessing content hosted on a peer device in a peer-to-peer network using a uniform resource locator (URL)
US8230098B2 (en) * 2006-05-10 2012-07-24 At&T Intellectual Property Ii, L.P. System and method for streaming media objects
GB2438258A (en) * 2006-05-16 2007-11-21 Skinkers Ltd Provision of personal data in a data communications network
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.
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.
FR2916600B1 (fr) * 2007-05-24 2013-11-22 Canon Kk Procede et dispositif de transmission de donnees
FR2922391B1 (fr) * 2007-10-15 2009-12-04 Canon Kk Procede et dispositif de transmission de donnees
EP2232899B1 (fr) * 2007-12-31 2019-03-13 Bklk Ltd. Procédé et dispositif pour un avertissement, une reconnaissance et une réponse rapides vis-à-vis de messages numériques
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
FR2944938B1 (fr) * 2009-04-28 2011-10-21 Canon Kk Procede et dispositif de correction d'erreurs.
EP2400749B1 (fr) * 2010-06-24 2013-05-01 Koninklijke KPN N.V. Contrôles de réseau d'accès distribués avec mise en cache locale pour le téléchargement d'utilisateur final
US8688734B1 (en) 2011-02-04 2014-04-01 hopTo Inc. System for and methods of controlling user access and/or visibility to directories and files of a computer
US8725168B2 (en) 2011-10-17 2014-05-13 Facebook, Inc. Content surfacing based on geo-social factors
US9397521B2 (en) 2012-01-20 2016-07-19 Salesforce.Com, Inc. Site management in an on-demand system
US9491123B2 (en) 2012-04-24 2016-11-08 Biscom Inc. Streamlined messaging client provisioning system
US8713658B1 (en) 2012-05-25 2014-04-29 Graphon Corporation System for and method of providing single sign-on (SSO) capability in an application publishing environment
US9419848B1 (en) 2012-05-25 2016-08-16 hopTo Inc. System for and method of providing a document sharing service in combination with remote access to document applications
US10095803B2 (en) * 2012-07-31 2018-10-09 Apple Inc. Delivering content to electronic devices using local caching servers
US9239812B1 (en) 2012-08-08 2016-01-19 hopTo Inc. System for and method of providing a universal I/O command translation framework in an application publishing environment
KR101422808B1 (ko) * 2012-09-21 2014-08-14 주식회사 팬택 드로잉 화면 공유 서비스의 제공 장치 및 방법과 이를 위한 휴대 단말
US10373431B2 (en) 2013-07-26 2019-08-06 Blue Calypso, Llc System and method for advertising distribution through mobile social gaming
US9814985B2 (en) 2013-07-26 2017-11-14 Blue Calypso, Llc System and method for advertising distribution through mobile social gaming
US9842095B2 (en) * 2016-05-10 2017-12-12 Adobe Systems Incorporated Cross-device document transactions
CN106470276B (zh) * 2016-08-23 2019-06-28 努比亚技术有限公司 一种实现数据交互的系统、方法及装置
CN107015870B (zh) 2016-09-19 2020-11-03 创新先进技术有限公司 实现web页面与本地应用通信的方法、装置和电子设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0993163A1 (fr) * 1998-10-05 2000-04-12 Backweb Technologies Ltd. Système et méthode de cache distribuée de données dans des terminaux Client
EP1229442A2 (fr) * 2001-01-22 2002-08-07 Sun Microsystems, Inc. Architecture de calcul point à point
US20030074403A1 (en) * 2001-07-06 2003-04-17 Harrow Ivan P. Methods and apparatus for peer-to-peer services

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6282709B1 (en) * 1997-11-12 2001-08-28 Philips Electronics North America Corporation Software update manager
US7206806B2 (en) 2001-05-30 2007-04-17 Pineau Richard A Method and system for remote utilizing a mobile device to share data objects
US6975419B2 (en) 2001-06-18 2005-12-13 Hewlett-Packard Development Company, L.P. System and method for mobile printing
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

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0993163A1 (fr) * 1998-10-05 2000-04-12 Backweb Technologies Ltd. Système et méthode de cache distribuée de données dans des terminaux Client
EP1229442A2 (fr) * 2001-01-22 2002-08-07 Sun Microsystems, Inc. Architecture de calcul point à point
US20030074403A1 (en) * 2001-07-06 2003-04-17 Harrow Ivan P. Methods and apparatus for peer-to-peer services

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CRAIGHILL N, DONOGHUE T: "WebObjects - Tools and Techniques", APPLE COMPUTER WEBOBJECTS 4.0 DOCUMENTATION, 1998, pages 57 - 58 79, XP002280382, Retrieved from the Internet <URL:http://developer.apple.com/documentation/LegacyTechnologies/WebObjects/WebObjects_4.0/System/Documentation/Developer/WebObjects/WOTools/WOToolsandTech.pdf> [retrieved on 20040514] *

Also Published As

Publication number Publication date
EP1499089A1 (fr) 2005-01-19
EP1499089B1 (fr) 2014-04-02
JP2005122693A (ja) 2005-05-12
US7716302B2 (en) 2010-05-11
US20050044483A1 (en) 2005-02-24

Similar Documents

Publication Publication Date Title
FR2857763A1 (fr) Procede d&#39;acces et de partage d&#39;un document numerique dans un reseau de communication p2p
EP2599284B1 (fr) Communication de données entre modules
FR2886494A1 (fr) Procede et dispositif d&#39;echange de donnees entre des stations mobiles dans un reseau pair a pair
FR2870022A1 (fr) Procede et dispositif de distribution de donnees numeriques notamment pour reseau pair-a-pair
FR2863127A1 (fr) Procedes et dispositifs pour la delivrance asynchrone de donnees numeriques
WO2007033814A2 (fr) Procédé d&#39;accès à des informations relatives à au moins un utilisateur permettant d&#39;entrer en contact avec lui ultérieurement
EP1515522A1 (fr) Procédé d&#39;insertion d&#39;informations de filtrage thématique de pages HTML et système correspondant
FR2853788A1 (fr) Procede et dispositif d&#39;acces a un document numerique dans un reseau de communication du type poste a poste
FR2854297A1 (fr) Procede et systeme de redirection sur detection d&#39;erreur de resolutions dns
EP1622339B1 (fr) Procédé et dispositif de distinction de requêtes HTTP utilisateur
WO2018172669A1 (fr) Procédé et dispositif de gestion du stockage de documents numériques
FR2855695A1 (fr) Procede et dispositif de diffusion cyclique radio vers des clients differents
EP1669899A1 (fr) Procédé de traitement de requêtes HTTP et de pages HTML émises ou reçues par un navigateur vers ou en provenance d&#39;au moins un serveur Web et serveur associé
EP1501248B1 (fr) Système et procédé de messagerie électronique
EP3465476B1 (fr) Procédé d&#39;invocation d&#39;un service applicatif par un navigateur
FR2918527A1 (fr) Procede et dispositif d&#39;insertion d&#39;une adresse dans une requete
WO2006016009A1 (fr) Procede et dispositif de traitement d’une requete de traduction d’un nom de domaine
EP1494419A1 (fr) Système de transmission de paramètres caractéristiques d&#39;une session de communication d&#39;un terminal vers un serveur distant
FR2854999A1 (fr) Procede et dispositif de datation d&#39;un document
FR3038092A1 (fr) Procede de telechargement accelere d&#39;une page web vers un terminal de communication
FR3078850A1 (fr) Procede, dispositif et systeme permettant l&#39;acces a une application deployee dans un conteneur
FR3094861A1 (fr) Transmission de messages dans un contexte multi-terminaux
WO2010031964A1 (fr) Procede de communication utilisant une image numerique et procede de transmission de donnees
FR2805111A1 (fr) Procede pour l&#39;execution d&#39;une tache par un serveur informatique multitache, sur requete d&#39;un terminal telephonique
EP1650684A1 (fr) Dispositif de médiation pour accéder à des applications non Internet depuis des applications Internet