WO2015181462A1 - Procédé de synchronisation de données entre différents équipements par l'intermédiaire d'un serveur - Google Patents

Procédé de synchronisation de données entre différents équipements par l'intermédiaire d'un serveur Download PDF

Info

Publication number
WO2015181462A1
WO2015181462A1 PCT/FR2015/051250 FR2015051250W WO2015181462A1 WO 2015181462 A1 WO2015181462 A1 WO 2015181462A1 FR 2015051250 W FR2015051250 W FR 2015051250W WO 2015181462 A1 WO2015181462 A1 WO 2015181462A1
Authority
WO
WIPO (PCT)
Prior art keywords
equipment
server
data
memory
update
Prior art date
Application number
PCT/FR2015/051250
Other languages
English (en)
Inventor
Loris BARNASSON
Edouard AGUILLAUME
Original Assignee
Preezms
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 Preezms filed Critical Preezms
Publication of WO2015181462A1 publication Critical patent/WO2015181462A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/273—Asynchronous replication or reconciliation

Definitions

  • the field of the invention is that of the automatic processing of local databases stored in a plurality of devices, in order to automatically update the modified data on certain equipment and update on all the equipment. linked.
  • It can for example be databases of coordinates between different users.
  • a first family of solutions is known in the state of the art of synchronizing the local databases with a central reference base.
  • US Pat. No. 7,757,282 discloses a technique for updating an address book of a terminal that maintains coordinate information on other processing terminals, in the most recent state, in a system. communication device in which a plurality of processing terminals are communicating connected to one another.
  • the method describes a data management method for updating the contact lists stored in a plurality of local equipment, through a communication network, in which the information of the contact lists is stored only in the local personal devices of the users. .
  • This method of the prior art comprises the following steps:
  • the present invention aims to remedy these disadvantages by proposing a solution ensuring a seal between the users, avoiding the conservation of data on a permanent central basis and limiting the computing resources necessary for the exploitation by a large number of users.
  • the invention relates, in its most general sense, to a method for automatically processing the update of a database BDDi stored in the memory JX ⁇ of a device E 1 as a function of the modifications of the information that has been inputted. for at least one recorded data in the memory M ⁇ at least one other equipment E l comprising:
  • the method further comprises - during the subscription of a new equipment, a step of creating, in the memory of a server, a table of linked equipment comprising, for each equipment E ⁇ d ' an identifier ld ⁇ of said equipment E ⁇ as well as identifiers Id j of equipment E j associated with the equipment E ⁇
  • One of the essential features of the invention concerns the absence of a centralized permanent database, that is to say a database controlled by the server and containing more than 75% of the useful data.
  • the useful data is active data, up to date, for at least two devices.
  • the invention is characterized in that the server retains only a very minor part of the active data, in particular less than 20% of the active data.
  • This minor proportion of active data concerns only the data that are transiently recorded in the database of the server, between the moment when a new data is downloaded by a transmitting equipment, and the moment when all the linked equipments have downloaded this data, the flow of a period of provision of the new data.
  • the aim is to avoid the accessibility of all the data in the same place of storage, or of a sufficiently substantial part of data, and thus prevent the hacking of data or the corruption of a centralized database.
  • said erasure is triggered by the downloading of the data by all the recipients.
  • said erasure is triggered after a predefined delay D eff from the initial recording of said datum.
  • the method comprises a restoration step, triggered during a reconnection after a predetermined delay D rest greater than the delay D eff , consisting in automating the sending to each linked equipment of a request to update. total day.
  • each of the data is further associated with an identifier of the version of the modification, said version identifier being calculated by the equipment at the origin of the modification.
  • the server proceeds, upon receipt of a modification data, to a comparison between the version identifier associated with said received data item and the version identifier stored in the server memory, and to replace the data stored in the server memory only when the version identifiers are different.
  • the invention allows the transmission of data created on the equipment E 1 and present on the memory M 2 of a device E 2 to the memory M 3 of a device E 3 via the equipment E 2 even if equipment E2 and E3 are not connected via the service from the moment E3 is authorized by El to hold these data (fig 2)
  • FIG. 1 represents a schematic view of the architecture implemented by the invention
  • FIG. 2 represents a diagram of the exchanges of information between the equipment and the server.
  • Figure 1 shows an example of architecture for the implementation of the invention.
  • User John has equipment (1), for example a cell phone.
  • the general architecture of such equipment comprises:
  • a central unit (10) associated with a certain number of memory including:
  • RAM RAM used for intermediate storage during communications and user interaction with the telephone. It can be implemented either as a separate integrated circuit on the motherboard or as a component placed with the CPU
  • a flash memory (30) with capacities greater than megabytes. It allows persistent storage of items such as: directory, missed and received calls, call history, calendar, received and sent text and multimedia messages, multimedia files;
  • ROM and OTP 40 for storing the phone's operating system and for services dedicated to security.
  • a database for example an address book, is stored in a portion of memory ⁇ (2) of the flash memory (30).
  • John's personal data such as his name, first name, home address, business address, etc. are stored in a memory space (3) of the flash memory (30).
  • This information may be grouped into business cards (for example "private” profile, "professional” profile, “association” profile, etc.). These sub- Sets can be used to generate electronic business cards (vcf, vcard, etc.) containing the personal data that he has chosen to share with each of the contacts.
  • the invention relates to a plurality of users, including Jessica, each having one or more devices (4, 5) having the same configuration as John.
  • the invention implements a server (6) comprising means of communication with the client equipment, as well as a memory (7) for temporarily storing data necessary for updating the equipment databases. clients.
  • the server (6) also comprises a computer performing the processing for the recording of the modified data and the distribution to the related equipment recipients of these data.
  • FIG. 2 shows the data exchange between the different devices.
  • the initial step is for John (Cl) to register with the service operator.
  • John will create a user account, which will result in the registration on the server:
  • the personal data are saved in the equipment's memory (3).
  • John will enter his address book saved in the memory (2). Alternatively, this operation is performed automatically by the address book management application.
  • the next step is for John to invite contacts by sending them an electronic business card
  • This invitation is sent, for example, as an email.
  • Jessica (C3) recipient of such a message, can record in a known manner the information of the virtual card in his own address book on his own equipment (4).
  • She may also choose to register for the service either by registering a unique identifier and registering as John did, to whom she will in turn send a direct exchange invitation.
  • the Jessica coordinate entered by John is either his unique exchange ID or a contact email / mobile number linked to the creation of Jessica's user account.
  • Jessica can accept the exchange by selecting in return at least one business card to exchange with John.
  • John's virtual card Upon acceptance the information of John's virtual card is added in his equipment in the service as well as in his own address book on his own equipment (4).
  • the server identifies the contacts holding the profile in an earlier version, and issues in the queue of each of these contacts a copy of the data of the modified profile.
  • the server then sends each of the contacts a message notifying the existence of a modification.
  • Jessica receives this message.
  • the message is processed either automatically in the background or at the next display of the application. This process consists in downloading the new version of the modified profile data and replacing the previously saved data in the memory (2) of Jessica's equipment.
  • the modified profile is deleted on the server, in the linked space associated with Jessica's equipment. After a determined delay, the modified profile is systematically erased on the server.
  • John may at any time change the information he exchanges with one of these contacts through the service.
  • contacts are subscribed to the service
  • a local application proceeds to a treatment consisting of:
  • the server delivers to Jessica's queue a copy of the profile data now exchanged by John.
  • the message is processed either automatically in the background or at the next display of the application. This process consists of downloading the new version of the exchanged data and replacing the previously saved data in the memory (2) of Jessica's equipment.
  • the modified profile is systematically erased on the server.
  • John has already invited Jessica who is not a subscriber to the service by sending him an electronic business card (Vf, var, etc.) containing the profiles he has chosen to share and a link to allow recipient to connect to a home page of the service, as well as the unique exchange ID to connect to John on the service.
  • Vf electronic business card
  • var var
  • This invitation has been sent as an email.
  • a local application proceeds to a treatment consisting of:
  • the local application detects the absence of the link table either automatically in the background or at the next display of the application.
  • the treatment involves changing the status of the contact in the Jessica and John equipment app by displaying it as "not connected”.
  • a local application in John's equipment proceeds with treatment consisting of: open a communication session with the server
  • the local application of John's equipment detects the absence of the link table either automatically in the background or at the next display of the application.
  • the treatment involves changing the status of Jessica's contact in John's equipment app by displaying it as "not connected".
  • John's equipment application When registering for the service, John's equipment application sends the server all address book details that can be used to detect a service member: email and mobile.
  • the server compares these coordinates with the registration details linked to the exchange identifiers.
  • the server identifies Jessica's registration email.
  • the server sends a message to Jessica and John informing them of their mutual presence on the service.
  • the application opens a connection to the server and checks the tables containing John's exchange ID links with other exchange IDs.
  • a message containing all the identifiers to which John is connected in the service is then sent by the server to John's equipment.
  • the contacts will change status to "connected", their business cards will be accessible in the application, the coordinates contained in these cards will be written in the memory of John's equipment.
  • the application opens a connection to the server and sends a request to check the tables containing John's exchange ID links with other exchange IDs to find the contacts connected to the server. served and holding the most recent versions of John's business cards
  • a message is then sent by the server to the equipment of the identified contacts to request the automatic sending of business cards from John to his own equipment.
  • John's business cards will be written and accessible in the application, the contact information contained in these cards will be written in the memory of his equipment.
  • Figure 2 shows the data exchange between the different devices in a restore situation of the C3 address book.
  • C3 When C3 requests a restore, it connects to the server (50), which returns profiles P lfj that are available in the server database, at the time of the restore request.
  • the index i designates a given contact, and j the order number of the profile of this contact i.
  • the server (50) launches the procedures defined below:
  • the server identifies the access rights between the user pairs.
  • C3 has a right of access to the profiles of Cl, but not of C2.
  • the server sends a request to another user C2 having an authorized relationship with Cl, to execute on the terminal C2 a process consisting in reading the local information concerning the profiles Pi, jf to be transmitted to the server. information and then to save them in the space reserved for C3, to allow the equipment of C3 to recover this information in its address book, although:

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Procédé de synchronisation de données entre différents équipements par la mise à jour d'une base de données BDD1 enregistré dans la mémoire M1 d'un équipement E1 en fonction des modifications des informations intervenues pour au moins une donnée enregistrée dans la mémoire Mi d'au moins un autre équipements Ei par l'intermédiaire d'un serveur d'échange de modifications. Le procédé ne met pas en œuvre une copie de la base de données BDD1 sur le serveur. Lors de l'ajout d'un nouvel équipement recevant une copie de la base de données BDD1, il met en œuvre une étape de création, dans la mémoire d'un serveur, d'une table des équipements liés comprenant, pour chaque équipement Ei d'un identifiant Idi dudit équipement Ei ainsi que les identifiants Idj des équipements Ej associés à l'équipement Ei.

Description

PROCÉDÉ DE SYNCHRONISATION DE DONNÉES ENTRE DIFFÉRENTS ÉQUIPEMENTS PAR L'INTERMÉDIAIRE D'UN SERVEUR
Domaine de 1 ' invention
Le domaine de l'invention est celui du traitement automatique de bases de données locales enregistrées dans une pluralité d'équipements, afin de procéder à une mise à jour automatique des données modifiées sur certains équipements et la mise à jour sur l'ensemble des équipements liés.
Il peut par exemple s'agir de bases de coordonnées entre différents utilisateurs.
Etat de la technique
On connaît dans l'état de la technique une première famille de solutions consistant à synchroniser les bases de données locales avec une base de référence centrale.
Le brevet américain US7752282 décrit par exemple une technique pour la mise à jour d'un carnet d'adresses d'un terminal qui conserve des informations de coordonnées sur d'autres terminaux de traitement, à l'état le plus récent, dans un système de communication dans lequel une pluralité de terminaux de traitement sont communicante reliée à une autre.
Une telle solution est connue par exemple sous le nom commercial de PLAXO et décrite dans le brevet européen délivré sous le numéro EP23215133. Ce brevet décrit un procédé pour le maintien et la mise à jour des informations de contact .
II propose la recherche d'un contact dans un carnet d'adresses universel en réponse à une demande d'un membre de l'utilisateur de mettre à jour les informations de contact et générer des messages appropriés de demande de mise à jour pour les contacts. Il permet aussi de recevoir des informations de contact mises à jour en réponse aux demandes de mise à jour et de synchronisation et des informations de mise à jour reçu. Le brevet américain US7818382 décrit une autre solution pour mettre à jour une base de contacts comprenant :
a) une étape de transmission d'une pluralité de messages électroniques, chaque message étant transmis à un contact parmi une pluralité de contacts
b) une étape de réception d'un message électronique de retour renvoyée en réponse à l'émission d'un message électronique parmi la pluralité de messages de courrier électronique et une indication d'un changement de l'information d'au moins un contact destinataire,
c) l'analyse automatique des messages et, le cas échéant, la détermination des modifications dans les informations de contact mises à jour par rapport aux informations de contact stocké dans la base de données d'informations de contact électronique et la mise à jour automatique de la base de contacts.
Ces solutions ne sont pas satisfaisantes car elle implique la conservation de données parfois sensibles, notamment des données personnelles, sur un serveur pouvant faire l'objet d'attaques mettant alors en péril l'intégrité et la confidentialité de la totalité des données de tous les utilisateurs .
Par ailleurs, le nombre de traitements croit exponentiellement en fonction du nombre d'utilisateurs, et nécessite des ressources informatiques très élevées, à la fois en terme de capacité de mémoire et en terme de puissance de calcul .
On connaît aussi une solution décrite dans la demande de brevet américaine US20060236089 décrivant un procédé consistant à créer des canaux virtuels entre deux utilisateurs permettant d'échanger des données modifiées.
Ce procédé décrit une méthode de gestion des données permettant de mettre à jour les listes de contacts stockés dans plusieurs équipements locaux, à travers un réseau de communication, dans lequel l'information des listes de contacts sont stockées uniquement dans les équipements personnels locaux des utilisateurs. Ce procédé de l'art antérieur comprend les étapes suivantes :
- identification de l'association entre utilisateurs inscrits, en fonction des similitudes existant entre les valeurs calculées de la fonction de hachage unidirectionnel de identifiants des usagers;
- réception de messages informant les utilisateurs des données personnelles modifiées à travers le réseau de communication ;
- création d'un canal de communication directe et temporaire entre les utilisateurs associés; et
- transfert des données personnelles mises à jour entre les utilisateurs associés par l'intermédiaire du canal de communication directe, ou un cache temporaire crypté.
L'inconvénient est que ce procédé est limité à des communautés relativement réduites. Dès que le nombre d'utilisateurs augmente, les infrastructures nécessaires sont élevées. Par ailleurs cette solution introduit des failles de sécurité par la recommandation de contact par recoupement social inapproprié et rend les différents utilisateurs directement visibles les uns par les autres.
D'autre part avec les solutions existantes la communication de données directe entre utilisateurs est limitée à un échange entre deux comptes utilisateurs connectés via service. Ceci oblige le propriétaire des données cibles à se connecter au serveur pour permettre la réception des données et limite grandement la réactivité de l'aboutissement de la requête.
Solution apportée par l'invention
La présente invention vise à remédier à ces inconvénients en proposant une solution assurant une étanchéité entre les utilisateurs, évitant la conservation de données sur une base centrale permanente et limitant les ressources informatiques nécessaires à l'exploitation par un grand nombre d'utilisateurs.
A cet effet, l'invention concerne selon son acception la plus générale un procédé de traitement automatique de la mise à jour d'une base de données BDDi enregistré dans la mémoire JX^ d'un équipement E1 en fonction des modifications des informations intervenues pour au moins une donnée enregistrée dans la mémoire M± d'au moins un autre équipements El comportant :
- lors de la détection de la modification d'une donnée partagée avec au moins un autre équipement, une étape de transmission par l'équipement Elf d'un message électronique M±j comprenant un identifiant de l'équipement E± ainsi que la donnée modifiée et son étiquette,
caractérisé en ce que le procédé comporte en outre - lors de l'abonnement d'un nouvel équipement, une étape de création, dans la mémoire d'un serveur, d'une table des équipements liés comprenant, pour chaque équipement E± d'un identifiant ld± dudit équipement E± ainsi que les identifiants Idj des équipements Ej associés à l'équipement E±
- lors de la réception message électronique Mlj l'enregistrement de ladite donnée dans une mémoire, aux adresses-cibles déterminées en fonction des informations enregistrées dans ladite table des équipements liés ;
- puis l'envoi à chacun desdits équipements liés d'un message contenant l'identifiant de l'équipement E± ayant procédé à une modification et une information relative à la nature de la modification ;
- des étapes de connexion au serveur par lesdits équipements liés pour télécharger les données enregistrées à l'adresse cible correspondante et le remplacement dans la mémoire M de ladite données téléchargée
- des étapes d'effacement périodique des données enregistrées auxdites adresses-cibles de la mémoire du serveur.
Une des caractéristiques essentielles de l'invention concerne l'absence de base de données permanente centralisée, c'est-à-dire d'une base de données commandée par le serveur et contenant plus 75% des données utiles. Les données utiles sont les données actives, à jour, pour au moins deux équipements.
L'invention se caractérise par le fait que le serveur ne conserve qu'une partie très mineures des données actives, notamment moins de 20% des données actives. Cette proportion mineure de données actives concerne seulement les données qui sont transitoirement enregistrées dans la base de données du serveur, entre le moment où une nouvelle donnée est téléchargée par un équipement émetteur, et le moment où soit tous les équipements liés ont téléchargé cette donnée, soit l'écoulement d'une période de mise à disposition de la donnée nouvelle. Le but est d'éviter l'accessibilité en un même lieu de stockage de l'intégralité des données, ou d'une partie suffisamment substantielle de données et empêcher ainsi le piratage des données ou la corruption d'une base de données centralisée .
Selon une variante, ledit effacement est déclenché par le téléchargement des données, par l'ensemble des destinataires. Selon une autre variante, ledit effacement est déclenché après un délai Deff prédéfini à compter de l'enregistrement initial de ladite donnée. Selon un mode de réalisation particulier, le procédé comporte une étape de restauration, déclenchée lors d'une reconnexion après un délai Drest prédéterminé supérieur au délai Deff, consistant à automatiser l'envoi à chaque équipement lié d'une requête de mise à jour totale.
Avantageusement chacune des données est en outre associée à un identifiant de la version de la modification, ledit identifiant de version étant calculé par l'équipement à l'origine de la modification.
Selon une variante préférée, le serveur procède, lors de la réception d'une donnée de modification, à une comparaison entre l'identifiant de version associée à ladite donnée reçue et l'identifiant de version enregistré dans la mémoire du serveur, et à remplacer la donnée enregistrée dans la mémoire du serveur seulement lorsque les identifiants de version sont différents. En particulier, l'invention permet la transmission de données créées sur l'équipement E1 et présentes sur la mémoire M2 d'un équipement E2 vers la mémoire M3 d'un équipement E3 Via l'équipement E2 même si les équipements E2 et E3 ne sont pas connectés via le service à partir du moment au E3 est autorisé par El à détenir ces données (fig. 2)
Description détaillée d'un exemple non limitatif de
réalisation . L'invention sera mieux comprise à la lecture de la description qui suit concernant un exemple non limitatif de réalisation illustré par les dessins annexés où :
- la figure 1 représente une vue schématique de l'architecture mise en œuvre par l'invention - la figure 2 représente un diagramme des échanges d'informations entre les équipements et le serveur.
La figure 1 représente un exemple d'architecture pour la mise en œuvre de l'invention.
L'utilisateur John dispose d'un équipement (1), par exemple un téléphone cellulaire. L'architecture générale d'un tel équipement comporte :
- une unité centrale (10) associée à un certain nombre de mémoire dont :
- une mémoire vive RAM (20), utilisée pour des stockages intermédiaires lors des communications et de l'interaction de l'utilisateur avec le téléphone. Elle peut être implémentée soit comme un circuit intégré à part entière sur la carte mère, soit comme un composant placé avec le CPU
(10) au sein d'un même circuit intégré;
une mémoire flash (30) avec des capacités supérieures au Mégaoctets. Elle permet de stocker de façon persistante les éléments tels que : le répertoire, les appels manqués et reçus, l'historique d'appel, l'agenda, les messages textes et multimédia reçus et envoyés, les fichiers multimédias ;
- une mémoire morte (ROM et OTP) (40) pour stocker le système d'exploitation du téléphone et pour des services dédiés à la sécurité.
Une base de données, par exemple un carnet d'adresses, est enregistrée dans une partie de mémoire ^ (2) de la mémoire flash (30). Par ailleurs, les données personnelles de John, par exemple son nom, son prénom, son adresse personnelle, son adresse professionnelle, etc. sont enregistrées dans un espace de mémoire (3) de la mémoire flash (30).
Ces informations sont éventuellement regroupées dans des cartes de visite (par exemple profil « privé », profil « professionnel », profil « association »...). Ces sous- ensembles pourront être utilisés pour générer des cartes de visite électroniques (vcf, vcard, etc.) contenant les données personnelles qu'il a choisi de partager avec chacun des contacts .
Par ailleurs, John enregistre sur son équipement
(1) une application locale dans la mémoire (40) réalisant les traitements associés au service décrit.
L'invention concerne une pluralité d'utilisateurs, dont Jessica, disposant chacun d'un ou plusieurs équipements (4, 5) présentant la même configuration que John.
Enfin, l'invention met en œuvre un serveur (6) comportant des moyens de communication avec les équipements clients, ainsi qu'une mémoire (7) pour l'enregistrement temporaire de données nécessaires à la mise à jour des bases de données des équipements clients.
Le serveur (6) comporte par ailleurs un calculateur réalisant les traitements pour l'enregistrement des données modifiées et la distribution aux équipements liés destinataires de ces données.
La figure 2 représente l'échange des données entre les différents équipements.
L'étape initiale consiste, pour John (Cl), à s'enregistrer auprès de l'opérateur du service.
A cet effet, John va créer un compte utilisateur, qui se traduira par l'enregistrement sur le serveur :
- d'un identifiant choisi par John, qui sera un identifiant unique, dit « identifiant unique d'échange »,
- d'un moyen de communication entre le serveur et l'équipement de John, par exemple son adresse de messagerie électronique, permettant au serveur de lui adresser un message d ' authentification
- éventuellement un identifiant technique de son équipement, par exemple le numéro d'identification attribué par le système d'exploitation de l'équipement. Si l'équipement de John est vierge, on procède à l'enregistrement des données personnelles dans la mémoire (3) de l'équipement.
Par ailleurs, John va renseigner son carnet d'adresses enregistré dans la mémoire (2). Alternativement, cette opération est réalisée automatiquement par l'application de gestion du carnet d'adresses.
Cas où les contacts ne sont pas abonnés au service
L'étape suivante consiste pour John à inviter des contacts en leur envoyant une carte de visite électronique
(vcf, vcard, etc.) contenant les profils qu'il a choisi de partager ainsi qu'un lien pour permettre au destinataire (C3) de se connecter à une page d'accueil du service, ainsi que l'identifiant unique d'échange permettant de se connecter à
John sur le service.
Cette invitation est par exemple envoyée sous forme d'un courrier électronique.
Jessica (C3), destinataire d'un tel message, peut enregistrer de manière connue les informations de la carte virtuelle dans son propre carnet d'adresse sur son propre équipement ( 4 ) .
Elle peut aussi choisir de s'inscrire au service soit en enregistrant un identifiant unique et en s 'inscrivant comme l'a fait John, à qui elle enverra à son tour une invitation directe d'échange.
L'acceptation par John se traduira par la modification d'une table enregistrée dans la mémoire (7) du serveur, correspondant aux liens entre les identifiants des équipements inscrits.
Cas où un contact a été invité avant son abonnement au service John a invité Jessica en lui envoyant une carte de visite électronique (vcf, vcard, etc.) contenant les informations des profils qu'il a choisi de partager ainsi qu'un lien pour permettre a Jessica de se connecter à une page d'accueil du service, ainsi que l'identifiant unique d'échange permettant de se connecter à John sur le service.
Lorsque Jessica s'inscrit au service en enregistrant un identifiant unique et en s 'inscrivant comme l'a fait John, une procédure d'analyse des informations renseignés par Jessica permettra de lui envoyer automatiquement l'invitation de John dans le service afin de procédé à la connexion des comptes selon la procédure de connexion entre deux contacts abonnés au service. Cas où les contacts sont abonnés au service
John invite Jessica par le service en lui envoyant une carte de visite électronique contenant les informations de son choix.
La coordonnée de Jessica saisie par John est soit son identifiant unique d'échange soit une coordonnée email / N° de mobile liée à la création du compte utilisateur de Jessica.
Elle reçoit alors directement dans le service (notification) une demande d'échange contenant la nature du message (Demande d'échange) ainsi que l'identité et les informations de John.
Jessica, peut accepter l'échange en sélectionnant en retour au moins une carte de visite à échanger avec John.
A l'acceptation les informations de la carte virtuelle de John son ajouté dans son équipement dans le service ainsi que dans son propre carnet d'adresse sur son propre équipement ( 4 ) .
L'acceptation par Jessica se traduira aussi par la modification d'une table enregistrée dans la mémoire (7) du serveur, correspondant aux liens entre les identifiants des équipements inscrits.
Mise à jour d'une donnée modifiée
Lorsque John procède à une modification d'une de ses données personnelles enregistrée dans la mémoire (3) de son équipement (1), une application locale procède à un traitement consistant à :
- mettre à jour l'identifiant de version du profil qui vient d'être modifié
ouvrir une session de communication avec le serveur
- transmettre un message contenant :
- les données du profil contenant les données modifiées
- l'identifiant de version du profil modifié le cas échéant l'étiquette des données modifiées .
Le serveur identifie les contacts détenant le profil dans une version antérieur, et délivre dans la file d'attente de chacun de ces contacts une copie des données du profil modifié.
Le serveur envoie ensuite à chacun des contacts un message notifiant l'existence d'une modification.
Jessica reçoit ce message. Le traitement du message est réalisé soit de manière automatique en tâche de fond, soit au prochain affichage de l'application. Ce traitement consiste à télécharger la nouvelle version des données du profil modifié et à remplacer les données précédemment enregistrées dans la mémoire (2) de l'équipement de Jessica.
Après confirmation du traitement, le profil modifié est effacé sur le serveur, dans l'espace liée associé à l'équipement de Jessica. Après un délai déterminé, le profil modifié est systématique effacé sur le serveur.
Modification des cartes de visite échangées entre les contacts
John peut procéder à tout instant à une modification des informations qu'il échange avec l'un de ces contacts par le service. Cas où les contacts sont abonnés au service
John ajoute ou supprime l'échange d'une des cartes de visite qu'il échange avec Jessica qui est abonnée au service. Une application locale procède à un traitement consistant à :
ouvrir une session de communication avec le serveur
- Envoyé une requête de modification d'une table enregistrée dans la mémoire (7) du serveur, correspondant aux liens entre les identifiants des équipements inscrits.
Le serveur délivre dans la file d'attente de Jessica une copie des données des profils maintenant échangés par John.
Le traitement du message est réalisé soit de manière automatique en tâche de fond, soit au prochain affichage de l'application. Ce traitement consiste à télécharger la nouvelle version des données échangées et à remplacer les données précédemment enregistrées dans la mémoire (2) de l'équipement de Jessica.
Les informations contenues dans les cartes de visite qui ne sont plus échangées ne sont plus visibles dans la mémoire de l'application du service mais toujours enregistrées dans la mémoire (2) de l'équipement de Jessica. Après confirmation du traitement, les profils dorénavant échangés sont effacés sur le serveur, dans l'espace liée associé à l'équipement de Jessica.
Après un délai déterminé, le profil modifié est systématique effacé sur le serveur.
Cas où les contacts ne sont pas abonnés au service
John a déjà invité par le service Jessica qui n'est pas abonnée au service en lui envoyant une carte de visite électronique (Vf, var, etc.) contenant les profils qu'il a choisi de partager ainsi qu'un lien pour permettre au destinataire de se connecter à une page d'accueil du service, ainsi que l'identifiant unique d'échange permettant de se connecter à John sur le service.
Cette invitation a été envoyée sous forme d'un courrier électronique.
John décide de supprimer l'échange d'une des cartes de visite qu'il souhaite échanger avec Jessica.
II modifie la liste des cartes de visite qu'il échange avec Jessica.
Une application locale procède à un traitement consistant à :
ouvrir une session de communication avec le serveur
- Envoyé une requête de modification d'une table enregistrée dans la mémoire (7) du serveur, correspondant aux liens entre les identifiants des équipements inscrits.
- Envoyé a Jessica une nouvelle carte de visite électronique contenant les coordonnées dorénavant échangé par
John
Jessica peut en toute connaissance choisir d'ajouter ces nouvelles coordonnées à la mémoire de son équipement . Rupture de l'échange entre des contacts
A tout instant les abonnés aux services peuvent choisir de couper leur relation d'échange avec un autre contact.
Cas entre deux contacts abonnés au service
Lorsque John décide de ne plus partager de carte de visite avec Jessica, une application locale procède à un traitement consistant à :
ouvrir une session de communication avec le serveur
- Supprimer une table enregistrée dans la mémoire (7) du serveur, correspondant aux liens entre les identifiants des équipements de John et Jessica.
L'application locale détecte l'absence de la table de liens soit de manière automatique en tâche de fond, soit au prochain affichage de l'application. Le traitement consiste à modifier le statut du contact dans l'application de l'équipement de Jessica et de John en l'affichant comme « non connecté » .
Les cartes de visite de John et Jessica ne sont plus visibles dans l'application de leur équipement respectif, mais les informations échangées sont toujours dans la mémoire de ces équipements.
Cas entre un contact abonnés au service et un contact qui ne
l'est pas
Lorsque John abonné au service décide de ne plus partager de carte de visite avec Jessica, qui n'est pas abonnée au service, une application locale dans l'équipement de John procède à un traitement consistant à : ouvrir une session de communication avec le serveur
- Supprimer une table enregistrée dans la mémoire (7) du serveur, correspondant aux liens entre l'identifiant de équipement de John et la coordonnée qui a servie a envoyé l'invitation à Jessica.
L'application locale de l'équipement de John détecte l'absence de la table de liens soit de manière automatique en tâche de fond, soit au prochain affichage de l'application. Le traitement consiste à modifier le statut du contact de Jessica dans l'application de l'équipement de John en l'affichant comme « non connecté ».
Signalement des contacts déjà abonnés au service
Lors de son inscription au service l'application de l'équipement de John envoie au serveur l'ensemble des coordonnées du carnet d'adresse pouvant servir à détecter un membre du service : email et mobile.
Le serveur compare ces coordonnées avec les coordonnées d'inscription liées aux identifiants d'échange.
Une fois la procédure de comparaison effectuée le serveur identifie l'email d'inscription de Jessica.
Le serveur envois un message à Jessica et à John les informant de leur présence réciproque sur le service.
John reçoit la notification l'informant de la réception du message de la présence de Jessica sur le service.
Dans le message il aura la possibilité de lancer le procédé d'invitation entre deux contacts abonnés au service tout comme Jessica sur son propre appareil.
Restauration des contacts
John change d'équipement, le nouvel équipement à une mémoire vierge. John se reconnecte au service par l'installation d'une application sur son nouvel appareil.
Il s'authentifie auprès du service à l'aide de sa coordonnée d'inscription ou de son identifiant d'échange.
L'application ouvre une connexion vers le serveur et vérifie les tables contenant les liens de l'identifiant d'échange de John avec d'autres identifiants d'échange.
Un message contenant l'ensemble des identifiants auxquels John est connecté dans le service est alors envoyé par le serveur vers l'équipement de John.
Parallèlement un message contenant une demande d'envoi des cartes de visite en cours de partage est envoyé vers l'ensemble des équipements des contacts connectés de John .
Automatiquement John recevra les cartes de visite des contacts connectés avec lui dans l'application.
Les contacts changeront de statu pour passer à « connecté », leurs cartes de visite seront accessibles dans l'application, les coordonnées contenues dans ces cartes seront écrites dans la mémoire de l'équipement de John.
Restauration des Coordonnées et des Cartes de visites d'un
utilisateur John change d'équipement, le nouvel équipement à une mémoire vierge .
John se reconnecte au service par l'installation d'une application sur son nouvel appareil.
Il s'authentifie auprès du service à l'aide de sa coordonnée d'inscription ou de son identifiant d'échange.
L'application ouvre une connexion vers le serveur et envoie une requête de vérification des tables contenant les liens de l'identifiant d'échange de John avec d'autres identifiants d'échange pour trouver les contacts connectés au servie et détenant les versions les plus récentes des cartes de visite de John
Un message est alors envoyé par le serveur vers l'équipement des contacts identifiés afin de solliciter l'envoi automatique des cartes de visite de John vers son propre équipement .
Automatiquement John recevra ses cartes de visite dans l'application.
Les cartes de visites de John seront écrites et accessibles dans l'application, les coordonnées contenues dans ces cartes seront écrites dans la mémoire de son équipement.
La figure 2 représente l'échange des données entre les différents équipements dans une situation de restauration du carnet d'adresses de C3.
Lorsque C3 demande une restauration, il se connecte au serveur (50), qui retourne les profils Plfj qui sont disponibles dans la base de données du serveur, au moment de la requête de restauration. L'indice i désigne un contact donné, et j le numéro d'ordre du profil de ce contact i.
Rappelons que seul un nombre restreints de profils est disponible sur le serveur, car les profils sont régulièrement effacés sur le serveur comme exposé dans ce qui précède .
Pour les profils non disponible, le serveur (50) lance des procédures définies ci-après :
Le serveur identifie les droits d'accès entre les binômes d'utilisateur. Dans l'exemple décrit, C3 dispose d'un droit d'accès aux profils de Cl, mais pas de C2.
Si un utilisateur Cl en relation avec C3 n'est pas connecté, la procédure de restauration ne peut aboutir directement. Dans ce cas, le serveur envoie une requête à un autre utilisateur C2 disposant d'une relation autorisé avec Cl, pour exécuter sur le terminal de C2 un traitement consistant à lire les informations locales concernant les j profils Pi , j f à transmettre au serveur ces informations, puis à les enregistrer dans l'espace réservé à C3, pour permettre à l'équipement de C3 de récupérer ces informations dans son carnet d'adresse, et ce bien que :
Cl ne soit pas connecté au serveur
- C3 n'ait pas de droit d'accès aux informations de C2.

Claims

Revendications
1 — Procédé de traitement automatique de la mise à jour d'une base de données BDDi enregistré dans la mémoire JX^ d'un équipement E1 en fonction des modifications des informations intervenues pour au moins une donnée enregistrée dans la mémoire M± d'au moins un autre équipements El comportant :
- lors de la détection de la modification d'une donnée partagée avec au moins un autre équipement, une étape de transmission par l'équipement Elf d'un message électronique M±j comprenant un identifiant de l'équipement E± ainsi que la donnée modifiée et son étiquette,
caractérisé en ce que le procédé ne met en oeuvre aucune base de données permanente centralisée et en ce que le procédé comporte en outre :
- lors de l'abonnement d'un nouvel équipement, une étape de création, dans la mémoire d'un serveur, d'une table des équipements liés comprenant, pour chaque équipement E± d'un identifiant ld± dudit équipement E± ainsi que les identifiants Idj des équipements Ej associés à l'équipement E±
- lors de la réception message électronique Mlj l'enregistrement de ladite donnée dans une mémoire, aux adresses-cibles déterminées en fonction des informations enregistrées dans ladite table des équipements liés ;
- puis l'envoi à chacun desdits équipements liés d'un message contenant l'identifiant de l'équipement E± ayant procédé à une modification et une information relative à la nature de la modification ;
- des étapes de connexion au serveur par lesdits équipements liés pour télécharger les données enregistrées à l'adresse cible correspondante et le remplacement dans la mémoire M de ladite données téléchargée - des étapes d'effacement périodique des données enregistrées auxdites adresses-cibles de la mémoire du serveur. 2 - Procédé de traitement automatique de la mise à jour d'une base de données BDDi selon la revendication 1 caractérisé en ce que ledit effacement est déclenché par le téléchargement par le dernier des équipements cibles.
3 - Procédé de traitement automatique de la mise à jour d'une base de données BDDi selon la revendication 1 ou 2 caractérisé en ce que ledit effacement est déclenché après un délai Deff prédéfini à compter de l'enregistrement initial de ladite donnée. 4 - Procédé de traitement automatique de la mise à jour d'une base de données BDDi selon la revendication 3 caractérisé en ce qu'il comporte une étape de restauration, déclenchée lors d'une reconnexion après un délai Drest prédéterminé supérieur au délai Deff, consistant à automatiser l'envoi à chaque équipement lié d'une requête de mise à jour totale .
5 - Procédé de traitement automatique de la mise à jour d'une base de données BDDi selon l'une quelconque des revendications précédentes caractérisé en ce que chacune des données est en outre associée à un identifiant de la version de la modification, ledit identifiant de version étant calculé par l'équipement à l'origine de la modification. 6 - Procédé de traitement automatique de la mise à jour d'une base de données BDDi selon la revendication précédente caractérisé en ce que le serveur procède, lors de la réception d'une donnée de modification, à une comparaison entre l'identifiant de version associée à ladite donnée reçue et l'identifiant de version enregistré dans la mémoire du serveur, et à remplacer la donnée enregistrée dans la mémoire du serveur seulement lorsque les identifiants de version sont différents . 7 - Procédé de traitement automatique de la mise à jour d'une base de données BDDi selon la revendication précédente caractérisé en ce qu'il comporte en outre une étape de mise à jour de la base de données enregistrée dans la mémoire JX^ d'un équipement E1 sur lequel est installée une application pour la mise en œuvre dudit procédé, à partir des données enregistrées dans une mémoire Mx d'un équipement Ex qui n'est pas nécessairement équipement de ladite application, ladite étape consistant à transmettre à l'équipement Ex à partir de l'équipe E1 un message selon un protocole standard, ledit message contenant un code informatique INTENT commandant l'exécution d'une application de carnet d'adresse sur l'équipement Ex ainsi que les données à modifier.
8 - Procédé de traitement automatique de la mise à jour d'une base de données BDDi selon l'une au moins des revendications précédentes caractérisé en ce qu'il comporte une étape initiale de génération par chaque équipement Ex d'un couple de clés de chiffrement asymétrique publique-privée,
à enregistrer sur l'équipement Ex de ladite clé privée et
à transmettre à un serveur de chiffrement un certificat CSR contenant ladite clé publique ainsi qu'une identité numérique de l'équipement E-t en fonction d'au moins deux paramètres comprenant un identifiant unique UDID dudit équipement El son numéro de téléphone et son adresse de courrier électronique, et sa localisation
puis à procéder à une étape de vérification de ladite identité numérique CSR par l'envoi audit équipement Ex, par ledit serveur de chiffrement, d'un message contenant un code de vérification à valider le code de vérification à partir dudit équipement Ex puis à procéder par le serveur après vérification de la validation, d'une signature électronique dudit certificat CSR de l'équipement E1
a transmettre audit équipement E1 le certificat CSR d'un serveur d'application nécessaire pour échanger des informations entre l'équipement E1 et ledit serveur d ' application .
9 - Procédé de traitement automatique de la mise à jour d'une base de données BDDi selon la revendication précédente caractérisé en ce que toutes les données temporairement enregistrées sur la base de données du serveur d'application sont chiffrées avec la clé publique de l'équipement destinataire E±.
10 - Procédé de traitement automatique de la mise à jour d'une base de données BDDi selon la revendication précédente caractérisé en ce que la clé publique de l'équipement émetteur Ex n'est pas enregistrée sur l'équipement destinataire E^
11 - Procédé de traitement automatique de la mise à jour d'une base de données BDDi selon la revendication 8 caractérisé en ce que la clé publique du serveur d'application est changée périodiquement.
PCT/FR2015/051250 2014-05-28 2015-05-13 Procédé de synchronisation de données entre différents équipements par l'intermédiaire d'un serveur WO2015181462A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1454867A FR3021774B1 (fr) 2014-05-28 2014-05-28 Procede de traitement automatique de la mise a jour d'une base de donnees
FR1454867 2014-05-28

Publications (1)

Publication Number Publication Date
WO2015181462A1 true WO2015181462A1 (fr) 2015-12-03

Family

ID=51168251

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2015/051250 WO2015181462A1 (fr) 2014-05-28 2015-05-13 Procédé de synchronisation de données entre différents équipements par l'intermédiaire d'un serveur

Country Status (2)

Country Link
FR (1) FR3021774B1 (fr)
WO (1) WO2015181462A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11249824B2 (en) 2017-04-25 2022-02-15 Red Hat, Inc. Balancing a recurring task between multiple worker processes
WO2023241582A1 (fr) * 2022-06-14 2023-12-21 华为技术有限公司 Procédé et système de synchronisation de données et support, produit-programme et dispositif électronique

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5862325A (en) * 1996-02-29 1999-01-19 Intermind Corporation Computer-based communication system and method using metadata defining a control structure
US20050055386A1 (en) * 2003-09-05 2005-03-10 Sierra Wireless, Inc. A Canadian Corp. Mail server based application record synchronization
US20060236089A1 (en) 2005-04-19 2006-10-19 Gal Cohen Automatic address-book updating system and method
US7752282B2 (en) 2006-03-27 2010-07-06 Fujitsu Limited Address information managing system, management apparatus, processing apparatus and address book updating method
US7818382B2 (en) 2000-12-22 2010-10-19 Mylife.Com, Inc. Method and system for automatically updating contact information within a contact database
US20100332682A1 (en) * 2009-06-30 2010-12-30 Christopher Sharp Updating multiple computing devices
EP2315133A2 (fr) 2003-11-07 2011-04-27 Plaxo, Inc. Procédé de génération des messages de demande de mise à jour, et procédé traitant des réponses auxdits messages

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5862325A (en) * 1996-02-29 1999-01-19 Intermind Corporation Computer-based communication system and method using metadata defining a control structure
US7818382B2 (en) 2000-12-22 2010-10-19 Mylife.Com, Inc. Method and system for automatically updating contact information within a contact database
US20050055386A1 (en) * 2003-09-05 2005-03-10 Sierra Wireless, Inc. A Canadian Corp. Mail server based application record synchronization
EP2315133A2 (fr) 2003-11-07 2011-04-27 Plaxo, Inc. Procédé de génération des messages de demande de mise à jour, et procédé traitant des réponses auxdits messages
US20060236089A1 (en) 2005-04-19 2006-10-19 Gal Cohen Automatic address-book updating system and method
US7752282B2 (en) 2006-03-27 2010-07-06 Fujitsu Limited Address information managing system, management apparatus, processing apparatus and address book updating method
US20100332682A1 (en) * 2009-06-30 2010-12-30 Christopher Sharp Updating multiple computing devices

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Middleware for Communications", 1 August 2005, WILEY, Hoboken, NJ, USA, ISBN: 978-0-47-086207-0, article QUSAY H. MAHMOUD: "4.4.5 Synchronization Service and P2P Synchronization", pages: 102 - 105, XP055203841 *
ANONYMOUS: "Oracle Database Lite: Synchronizing Data Between a Device and an Oracle Database An Oracle White Paper", 1 August 2007 (2007-08-01), XP055090790, Retrieved from the Internet <URL:http://www.oracle.com/technetwork/products/database-mobile-server/olsync-131762.pdf> [retrieved on 20131128] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11249824B2 (en) 2017-04-25 2022-02-15 Red Hat, Inc. Balancing a recurring task between multiple worker processes
WO2023241582A1 (fr) * 2022-06-14 2023-12-21 华为技术有限公司 Procédé et système de synchronisation de données et support, produit-programme et dispositif électronique

Also Published As

Publication number Publication date
FR3021774A1 (fr) 2015-12-04
FR3021774B1 (fr) 2017-02-24

Similar Documents

Publication Publication Date Title
US10313464B2 (en) Targeted notification of content availability to a mobile device
EP2294776B1 (fr) Procédé et système d&#39;accès par un utilisateur à au moins un service offert par au moins un autre utilisateur
KR20220066181A (ko) 임시 컨텐츠 메시지를 처리하기 위한 방법들 및 시스템들
EP2795870B1 (fr) Procede d&#39;acces par un terminal de telecommunication a une base de donnees hebergee par une plateforme de services accessible via un reseau de telecommunications
US11863645B2 (en) Targeted notification of content availability to a mobile device
EP1637989A1 (fr) Procédé et système de séparation de comptes de données personnelles
EP2360889B1 (fr) Création et utilisation d&#39;un lien de télécommunication entre deux utilisateurs d&#39;un réseau de télécommunication
WO2015181462A1 (fr) Procédé de synchronisation de données entre différents équipements par l&#39;intermédiaire d&#39;un serveur
US20150046565A1 (en) System and method for archiving messages
EP2979435B1 (fr) Procédé de traitement de donnés d&#39;utilisateur d&#39;un réseau social
WO2013076420A1 (fr) Procede de gestion de la mise en relation numerique
US20140372375A1 (en) Contact data sharing
EP2529330B1 (fr) Procédé de fourniture d&#39;un code dynamique par l&#39;intermédiaire d&#39;un téléphone
EP3391680B1 (fr) Procédé de gestion d&#39;au moins une communication, dispositif et programme de module logiciel correspondants
EP2843923A2 (fr) Dispositif et procédé d&#39;enrichissement d&#39;une communication
EP2808819B1 (fr) Procédé de mise à jour de certificats dans un dispositif portable
WO2011070241A1 (fr) Procede de sauvegarde de donnees contenues dans un terminal communiquant portable
FR3025625A1 (fr) Generation et partage d&#39;applications personnalisees de communication
FR2881591A1 (fr) Mise en oeuvre d&#39;une operation cryptographique a distance d&#39;une pki
WO2011000890A1 (fr) Méthode pour gérer l&#39;identité d&#39;utilisateurs de terminaux dans un réseau de communications
FR3064385A1 (fr) Procede d&#39;envoi de courrier recommande electronique
FR3046272A1 (fr) Procede et dispositif de connexion a un serveur distant
FR3020539A1 (fr) Procede et dispositif d&#39;etablissement d&#39;une communication
CA2387278A1 (fr) Systeme et methode de gestion de liens entre personnes
FR2880703A1 (fr) Procede d&#39;identification d&#39;utilisateur, de creation d&#39;un document de partage et de service correspondant dans un systeme de partage d&#39;un reseau pair a pair

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15728053

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205N DATED 03/02/2017)

122 Ep: pct application non-entry in european phase

Ref document number: 15728053

Country of ref document: EP

Kind code of ref document: A1