FR3055442A1 - Procede de rotation et de partage coherent de vues orientees d'un plan comportant des donnees localisees par des dispositifs informatiques collaboratifs. - Google Patents

Abstract

Un procédé de rotation et de partage cohérent de vues orientées d'un plan numérique (PLAN) comportant des données collaboratives localisées, repérées dans un référentiel (R*), par des dispositifs informatiques partenaires (M1, M2,..., Mn) communiquant au moyen de connexions ponctuelles avec un dispositif informatique principal (MO) ; le procédé comprenant : - la mémorisation d'une valeur d'orientation sélectionnée (ORIENT) caractérisant l'orientation dans le référentiel (R*) d'une vue orientée du plan numérique (PLAN) privilégiée, - la mémorisation par chaque dispositif informatique partenaire (M1, M2,..., Mn) des fichiers de visualisation destinés à l'affichage de vues orientées du plan numérique (PLAN), mis à jour en tenant compte de la valeur d'orientation sélectionnée (ORIENT), - la mise à jour des coordonnées de localisation dans le référentiel (R*) de toutes les données collaboratives en tenant compte de la valeur d'orientation sélectionnée (ORIENT), - la mémorisation par chaque dispositif informatique partenaire (M1, M2,..., Mn) de toutes les données collaboratives localisées et leurs coordonnées dans le référentiel (R*).

Description

Domaine de l'Invention :

L'invention a trait au domaine de la gestion informatique de plans numériques, et plus généralement de dessins techniques.

L'invention trouve particulièrement application à la rotation de vues orientées de plans destinés à être partagées, affichées et enrichies par une flotte de dispositifs informatiques, tels que ordinateurs portables, tablettes tactiles, smartphones, mis à disposition d'utilisateurs se déplaçant sur site, et notamment des dispositifs informatiques mobiles dans un contexte de travail collaboratif.

Etat de la technique :

Un plan, ou plus généralement un dessin technique, est par nature un document particulier : il s'agit de la modélisation graphique ou schématique, d'un objet ou d'un système (exemple : immeubles, villes, machines, etc), existant ou à créer, qui est complétée par un certain nombre d'informations que sont, par exemple, son numéro de mise à jour (usuellement nommé « version »), son nom, son échelle, ses cotations et son orientation. Des informations contextuelles, dépendant de la finalité d'utilisation du plan, sont également associées au plan, comme par exemple des annotations, des mesures de distances sur le plan, etc. L'ensemble de ces informations, le plan lui-même qui correspond à une image numérique, c'est-à-dire la version numérique d'un plan papier, et les informations qui lui sont associées, peuvent prendre informatiquement plusieurs formats (exemple : pdf « portable document format », DWG - associé au logiciel autoCAD©, etc.) en fonction des souhaits de l'utilisateur et/ou des logiciels à sa disposition pour produire un fichier informatique codant le plan et ses informations associées.

Il est très courant que les plans soient en deux dimensions, et destinés à des supports d'affichage ou de lecture rectangulaires, mais il existe aussi des plans à plus de deux dimensions, que l'on appellera plus généralement des maquettes.

Il est connu d'utiliser des plans ou des dessins techniques au sein de dispositifs informatiques mobiles collaboratifs mis à disposition de collaborateurs d'une entreprise ou d'un projet. L'une des mises en œuvre de cette technique concerne par exemple les dispositifs informatiques de « levée de réserves » utilisées dans l'industrie de la construction pour générer des listes de tâches et faciliter le suivi de l'activité. Ces dispositifs sont généralement constitués de n+1 machines (MO, Ml,..., Mn) (tablettes tactiles, ordinateurs portables, téléphones portables, serveurs), communiquant entre elles au moyen d'un réseau de

2/48 télécommunication quelconque, qui peut être de type EDGE, 3G, 4G ou Wifi, et hébergeant chacune un logiciel permettant aux utilisateurs de générer des informations en interaction avec les pages d'un plan les plus à jour que connaît le système. Les plans constituent pour ces dispositifs des données d'entrées indispensables à leur bon fonctionnement. Ce sont par ailleurs des documents de projet susceptibles d'être modifiés ou mis à jour régulièrement (montée de version).

Le degré de rotation d'un plan en deux dimensions autour d'un axe de référence qui lui est orthogonal constitue son orientation. Il est usuel de devoir modifier cette orientation pour pouvoirfaciliter la lecture du plan. En théorie, rien n'interdit d'orienter le plan selon n'importe quelle valeur s'échelonnant entre 0 degré et 360 degrés. En pratique, les orientations couramment retenues sont :

degré (position normale de lecture), +90 degrés dans le sens horaire (quart de tour à droite) +180 degrés dans le sens horaire (demi-tour) +270 degrés dans le sens horaire (quart de tour à gauche)

Un procédé usuellement utilisé pour la rotation d'une image consiste à calculer cette rotation directement au niveau du dispositif réalisant son affichage. Ce procédé usuel présente plusieurs défauts majeurs :

1. Dans le cas d'une image particulièrement complexe, comme c'est le cas pour un plan, compte tenu de sa surface et/ou de la densité d'informations qu'il contient, l'opération de rotation peut s'avérer lente, voire totalement impossible sur des dispositifs informatiques de faible puissance, ce qui est de nature à dégrader l'expérience utilisateur. Dans le cas d'une utilisation collaborative sur n+1 machines (MO, Ml, ..., Mn) mobilisant des machines de puissance variable inconnue supposées afficher des images numériques de taille quelconque (et possiblement de grande taille, comme c'est le cas pour des plans numériques), rien ne permet d'affirmer a priori que chacune des machines sera capable d'effectuer l'opération de rotation attendue. La probabilité selon laquelle au moins une machine ne disposera de la puissance de calcul nécessaire est d'autant plus importante que le nombre n+1 de machines est élevé et que la complexité de l'image considérée est importante

2. Dans le cas d'une utilisation collaborative sur n+1 machines (MO, Ml, ..., Mn), l'opération de rotation doit être effectuée, selon ce procédé usuel, sur chacun des terminaux, ce qui démultiplie :

a. Les ressources mobilisées (puissance de calcul)

b. Les délais d'attente (temps de calcul et délais de réponse)

3. Dans le cas d'une utilisation collaborative sur n+1 machines (MO, Ml,..., Mn) supposées partager des informations synchronisées, localisées sur l'image en question, les problématiques de diffusion et de cohérence entre les mémoires des différents dispositifs informatiques ne sont pas solutionnées par ce procédé usuel. Cette

3/48 problématique de diffusion est d'autant plus conséquente que la nature synchrone des dispositifs informatiques est discontinue, ou que le délai de traitement de l'opération de rotation est long.

De fait, ce procédé usuel de rotation d'images ne peut pas être appliqué dans le cadre d'un système de dispositifs informatiques (MO, Ml, M2, ..., Mn) communiquant entre eux ponctuellement, de manière discontinue, et supposés partager des plans numériques sur lesquels sont localisées des données collaboratives.

Communément, dans de telles circonstances, on ne permet pas la rotation des plans, de manière à parfaitement garantir la cohérence des données partagées.

Exposé de l'invention :

Le but de l'invention est de proposer un procédé de rotation d'un plan numérique au sein d'une flotte collaborative de dispositifs informatiques communiquant entre eux par intermittence, qui permette d'assurer l'affichage de vues orientées privilégiées sur chacun des dispositifs du système, y compris les moins puissants, tout en préservant la cohérence de données partagées localisées.

A cet effet, l'invention a pour objet un procédé de rotation et de partage cohérent de vues orientées d'un plan numérique comportant des données localisées, dites collaboratives de travail, repérées dans un référentiel R*, par des dispositifs informatiques dits « partenaires » (Ml, M2,..., Mn) où chacun des dispositifs partenaires communique au moyen de connexions ponctuelles avec un dispositif informatique dit « principal » (MO), et caractérisé en ce que :

on mémorise une valeur dite « d'orientation sélectionnée » caractérisant l'orientation dans le référentiel R* d'une vue orientée du plan numérique privilégiée, chaque dispositif informatique partenaire (Ml, M2, ..., Mn) mémorise des fichiers dits « de visualisation » destinés à l'affichage de vues orientées du plan numérique, mis à jour en tenant compte de la valeur d'orientation sélectionnée, on met à jour les coordonnées de localisation de toutes les données collaboratives de travail dans le référentiel R* en tenant compte de la valeur d'orientation sélectionnée, chaque dispositif informatique partenaire (Ml, M2,..., Mn) mémorise toutes les données collaboratives de travail et leurs coordonnées de localisation dans le référentiel R*.

Comme cela est connu, un fichier informatique est une collection d'informations numériques réunies sous un même nom, enregistrées sur un support de stockage informatique et manipulées comme une unité. En parallèle, on entend par « objet informatique dynamique » une collection d'informations numériques enregistrées de manière éphémère sur un support

4/48 de stockage informatique et manipulées comme une unité, sans qu'il soit nécessaire de lui donner un nom.

On entend par « mise à jour d'un objet informatique» l'action ou la suite d'actions qui consiste à actualiser une version de cet objet informatique par modification de tout ou partie de cette version, et/ou création d'une nouvelle version, en tenant compte de l'état connu le plus récent du système dans lequel évolue l'objet informatique en question.

On entend par « vue orientée d'un plan numérique », une représentation graphique, affichée par un dispositif informatique, qui équivaudrait à ce que percevrait un utilisateur en regardant une version papier de ce plan numérique, dans une orientation donnée, à une distance où les mentions de ce plan sont exploitables dans un mode d'utilisation normal.

On entend par « donnée localisée » sur un plan toute information qui se situe à un endroit du plan, et dont la signification est directement dépendante de cette position sur le plan.

On entend par « connexion ponctuelle » entre deux dispositifs informatiques la liaison élémentaire et limitée dans le temps à travers laquelle ces dispositifs informatiques ont la capacité d'échanger des informations.

On entend par « procédé de partage cohérent de données » l'action ou la suite d'actions par laquelle on parvient à mémoriser, au même instant et en différents points d'un système, des informations identiques ou similaires dont la signification a été préservée.

En d'autres termes, nous avons eu l'idée de mettre en place un procédé de rotation de vues orientées d'un plan numérique intégrant une stratégie de partage de données collaboratives caractérisant ces vues, et de gestion de leur cohérence, s'appuyant sur des mises à jour effectuées en lien avec un état de référence correspondant à une vue orientée privilégiée dans un référentiel spatial de référence, de manière à étendre la portée d'un procédé de rotation d'images connu, pertinent au niveau d'un seul dispositif informatique, dans le but de pouvoir couvrir les cas de n+1 dispositifs informatiques collaboratifs communiquant entre eux à travers une succession de connexions ponctuelles.

Notre procédé a l'avantage de couvrir l'ensemble des n+1 machines d'un système collaboratif et permet de faire fonctionner l'intégralité de ce système en lien avec un état de référence commun, en dépit du fait que les connexions entre ces machines ne soient pas permanentes. Chaque connexion établie tend à mettre à jour une partie du système dans le but d'atteindre en tout point de ce système cet état de référence s'il est maintenu suffisamment longtemps pour le permettre. Ce procédé permet de traiter la rotation de vues de plans numériques particulièrement grandes et/ou complexes, y compris dans les cas de figure où certains dispositifs informatiques du système, pris isolément, n'auraient pas la puissance de calcul, ou les ressources matérielles et/ou logicielles, pour le faire. Dans le même ordre d'idée, notre procédé à l'avantage de réduire les ressources matérielles et/ou logicielles globalement nécessaires au système pour l'atteinte du résultat escompté, comparativement à celles qui seraient nécessaires dans un contexte où chaque machine de ce même système aurait à

5/48 atteindre ce même résultat isolément. En d'autres termes, notre procédé permet à un système d'opérer une rotation de vues orientées de plans numériques comportant des données localisées en permettant à chacune des machines de ce système de bénéficier des ressources matérielles et/ou des ressources logicielles de la machine la plus puissante et/ou la plus adaptée à l'atteinte du résultat escompté.

Le procédé objet de la présente invention permet finalement d'automatiser le partage d'une vue orientée privilégiée d'un plan numérique comportant des données localisées au sein d'un système collaboratif où n+1 dispositifs informatiques communiquent entre eux au moyen de connexions ponctuelles, avec pour seul paramètre d'entrée la valeur d'orientation sélectionnée caractérisant l'orientation dans un référentiel connu de la vue orientée que l'on souhaite privilégier.

Selon un mode de réalisation, on intègre aux données collaboratives de travail couvertes par le procédé objet de l'invention chaque donnée collaborative de travail supplémentaire mémorisée par l'un des dispositifs informatiques (MO, Ml, M2, ..., Mn) au cours du déroulement du procédé. Ce mode de réalisation a l'avantage d'améliorer le niveau de service du procédé en augmentant sa disponibilité ; lorsque le présent procédé fait partie d'un système plus vaste au sein duquel des données collaboratives de travail sont générées à des moments quelconques, le présent procédé peut être mis en œuvre sans perturber le fonctionnement de ce système plus vaste. Ainsi, si le présent procédé s'inscrit dans un système plus vaste où les données collaboratives de travail sont créées par un utilisateur, cet utilisateur peut continuer à générer des données collaboratives de travail même après le démarrage du présent procédé.

Selon un mode de réalisation, on transmet au dispositif informatique principal MO au cours de ses connexions ponctuelles avec chacun des dispositifs informatiques partenaires Mj, appelées synchronisations de MO avec Mj, toutes les données collaboratives de travail modifiées ou nouvelles que ce dispositif informatique partenaire Mj a mémorisé pendant l'intervalle de temps séparant le début de cette synchronisation de MO avec Mj et la fin de la synchronisation de MO avec Mj précédente. Ce mode de réalisation est de nature à réduire le nombre de synchronisations de MO avec Mj nécessaires.

Selon un mode de réalisation, on transmet à chacun des dispositifs informatiques partenaires Mj au cours de ses connexions ponctuelles avec le dispositif informatique principal MO, appelées synchronisations de MO avec Mj, toutes les données collaboratives de travail modifiées ou nouvelles que le dispositif informatique principal MO a mémorisé pendant l'intervalle de temps séparant le début de cette synchronisation de MO avec Mj et la fin de la synchronisation de MO avec Mj précédente. Ce mode de réalisation est de nature à réduire le nombre de synchronisations de MO avec Mj nécessaires.

6/48

Selon un mode de réalisation, la vue orientée du plan numérique privilégiée est définie par un utilisateur. La valeur d'orientation sélectionnée correspondante est alors enregistrée dans la mémoire de stockage du dispositif informatique principal MO et sert de référence pour la mise à jour des fichiers de visualisation et des données collaboratives de travail.

Selon un mode de réalisation, on associe à chaque vue orientée du plan numérique mémorisée par au moins un des dispositifs informatiques (MO, Ml, M2, ..., Mn) une valeur dite « d'orientation maître » caractérisant l'orientation de cette vue dans le référentiel R*. Cette valeur d'orientation maître, par comparaison avec la valeur d'orientation sélectionnée, permet de connaître l'écart angulaire qui existe entre la vue orientée considérée et la vue orientée privilégiée.

Selon un mode de réalisation, on associe à chacune des données collaboratives de travail localisée sur une vue orientée du plan numérique une valeur dite « d'orientation de donnée » caractérisant l'orientation de cette vue dans le référentiel R*. Lorsque cette donnée collaborative de travail est créée et localisée sur une vue orientée du plan numérique, sa valeur d'orientation de donnée est égale à la valeur d'orientation maître de cette vue orientée.

Selon un mode de réalisation, on compare les valeurs d'orientation de donnée à la valeur d'orientation sélectionnée, ou à la valeur d'orientation maître la plus à jour que connaît le système, dans le but de déterminer la formule mathématique à appliquer pour mettre à jour les coordonnées de localisation dans le référentiel R* de chacune des données collaboratives de travail.

Selon un mode de réalisation, on effectue la mise à jour des coordonnées de localisation dans le référentiel R* des données collaboratives mémorisées par le dispositif informatique principal MO au moment où l'utilisateur valide son choix de vue orientée privilégiée, dans une transaction informatique dite « première ». Cette transaction permet de préserver la cohérence globale des données collaboratives de travail qu'elle couvre.

Selon un mode de réalisation, on effectue la mise à jour des coordonnées de localisation dans le référentiel R* des données collaboratives de travail que le dispositif informatique principal MO a mémorisé pendant la durée de la première transaction informatique, dans une transaction informatique dite « seconde » ouverte juste après validation de la première transaction informatique. Cette seconde transaction informatique couvre par exemple les données collaboratives de travail créées par l'utilisateur au niveau du dispositif principal MO pendant la durée de la première transaction, ainsi que les données collaboratives de travail diffusées à MO par les dispositifs informatiques partenaires Mj pendant la durée de la première transaction. Cette seconde transaction met en cohérence les données collaboratives qu'elle couvre avec l'ensemble des données collaboratives qui viennent d'être traitées par la première transaction.

7/48

Selon un mode de réalisation, l'utilisateur définit la vue orientée du plan numérique privilégiée en sélectionnant une représentation visuelle miniaturisée de cette vue orientée du plan numérique parmi d'autres représentations de vues orientées du plan numérique.

Selon un mode de réalisation, l'utilisateur définit la vue orientée du plan numérique privilégiée en choisissant une représentation visuelle d'un extrait de cette vue orientée du plan numérique parmi d'autres représentations de vues orientées du plan numérique.

Selon un mode de réalisation, on ne mobilise que la puissance de calcul du dispositif informatique principal MO pour déterminer les coordonnées de localisation mises à jour dans le référentiel R* des données collaboratives de travail.

Selon un mode de réalisation, le dispositif informatique principal MO diffuse à chaque dispositif informatique partenaire (Ml, M2, ..., Mn) les fichiers de visualisation codant la vue orientée privilégiée.

Selon un mode de réalisation, les dispositifs informatiques produisent des objets informatiques dynamiques, mémorisés dans leur mémoire vive, comprenant des conteneurs d'images, incorporant la ou les images matricielles affichées à leur écran.

L'invention a également pour objet un système informatique de rotation et de partage cohérent de vues orientées d'un plan numérique comportant des données localisées dites « collaboratives de travail » repérées dans un référentiel R*, comprenant des dispositifs informatiques dits « partenaires » (Ml, M2, ..., Mn), où chacun de ces dispositifs partenaires (Mj) communique au moyen de connexions ponctuelles à travers un réseau informatique avec un dispositif informatique dit « principal » formant serveur (MO), chaque dispositif informatique (MO, Ml, M2, ..., Mn) disposant ou étant relié à un module de communication avec le réseau informatique, disposant ou étant relié à un moyen de commande permettant de recueillir des informations ou des ordres émis par l'utilisateur, disposant d'une mémoire informatique pour mémoriser des fichiers dits « de visualisation » destinés à l'affichage de vues orientées du plan numérique, les données collaboratives de travail et leurs coordonnées dans le référentiel R*, ainsi qu'une valeur dite « d'orientation sélectionnée » caractérisant l'orientation dans le référentiel R* d'une vue orientée du plan numérique privilégiée, disposant ou étant relié à un dispositif d'affichage comprenant une zone d'affichage, et disposant d'une unité de traitement capable de générer et d'afficher sur son dispositif d'affichage, des objets informatiques dynamiques ou des fichiers informatiques en utilisant ou en transformant tout ou partie des fichiers de visualisation.

Au moins un des dispositifs informatiques (MO, Ml,..., Mn) étant configuré pour : la mémorisation de la valeur d'orientation sélectionnée,

8/48 la mise à jour de fichiers de visualisation destinés à l'affichage de vues orientées du plan numérique en tenant compte de la valeur d'orientation sélectionnée, la mise à jour des coordonnées de localisation des données collaboratives de travail dans le référentiel R* en tenant compte de la valeur d'orientation sélectionnée.

Chaque dispositif informatique partenaire (Ml,..., Mn) étant configuré pour :

la diffusion de données collaboratives réceptionnées par le dispositif informatique principal (MO), la réception de données collaboratives diffusées par le dispositif informatique principal (MO), la mémorisation de toutes les données collaboratives de travail et leurs coordonnées dans le référentiel R*, la mémorisation de fichiers de visualisation.

Le dispositif informatique principal (MO) étant configuré pour :

la diffusion de données collaboratives réceptionnées par les dispositifs informatiques partenaires (Ml, M2,..., Mn), la réception de données collaboratives diffusées par les dispositifs informatiques partenaires (Ml, M2,..., Mn).

Ce système est apte à mettre en oeuvre un procédé du type précité.

Brève description des figures :

L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple, et faite en relation avec les dessins annexés, dans lesquels des références identiques désignent des éléments identiques ou analogues, et dans lesquels :

La figure 1 est un organigramme d'un procédé dit « de synchronisation du dispositif central MO avec n'importe lequel des dispositifs partenaires Mj », constituant une sous-partie d'un procédé de rotation et de partage cohérent de vues orientées d'un plan comportant des données localisées par des dispositifs informatiques collaboratifs, selon l'invention.

Les figures 2A et 2B sont les deux parties d'un organigramme d'un procédé de rotation et de partage cohérent de vues orientées d'un plan comportant des données localisées par des dispositifs informatiques collaboratifs, selon l'invention.

La figure 3 est une vue schématique d'un système informatique d'un procédé de rotation et de partage cohérent de vues orientées d'un plan comportant des données localisées par des dispositifs informatiques collaboratifs, selon l'invention.

9/48

La figure 4 est une représentation schématique des principales données collaboratives intervenant dans la description détaillée qui suit.

La figure 5 est une vue orientée à observer en lien avec les données de la figure 4.

La figure 6 est une représentation schématique des principales données collaboratives intervenant dans la description détaillée qui suit, telles qu'elles peuvent se trouver modifiées par une mise en œuvre d'un procédé de rotation et de partage cohérent de vues orientées d'un plan comportant des données localisées par des dispositifs informatiques collaboratifs, selon l'invention.

La figure 7 est une vue orientée à observer en lien avec les données de la figure 6.

La figure 8 est une représentation schématique qui permettra au lecteur de mieux comprendre les objets informatiques appelés BUFFERED_PLAN_O, BUFFERED_O, BUFFERED_90, BUFFERED_180 et BUFFERED_270, dans la description détaillée qui suit.

Description détaillée de l'invention :

En se référant à la figure 3, un système (Figure 3 : renvoi 01) selon l'invention comporte une pluralité de dispositifs informatiques partenaires Ml, M2, ..., Mn, (appelés également machines Ml, M2, ..., Mn) équipés chacun d'un processeur, d'une mémoire vive, d'une mémoire de stockage de masse, d'un écran d'affichage comprenant une zone d'affichage DISPLAY, d'un dispositif de saisie destiné à l'utilisateur COMMANDE et d'un module de communication avec au moins un réseau de communication informatique RI, par exemple un réseau de communication sans fil de type WIFI, 3G, 4G, EDGE, etc, et embarquant chacun un système d'exploitation pour la gestion des différents éléments matériels et logiciels embarqués. Par exemple, les dispositifs informatiques partenaires Ml, M2, ..., Mn sont des tablettes tactiles, des ordinateurs portables et/ou des smartphones, constituant une flotte de dispositifs portables à usage de collaborateurs dans le domaine de la construction, de la maintenance, des travaux, de la gestion immobilière, de l'entretien de voiries ou de réseaux, ou plus généralement de tout métier nécessitant l'intervention sur site d'équipes techniques mobiles appartenant éventuellement à des structures ou à des entreprises différentes. Les dispositifs Ml, ..., Mn peuvent être identiques, ou différents comme cela est usuellement le cas. Les dispositifs sont notamment différents dans le cas de figure où des entreprises différentes sont amenées à échanger des informations sur un même projet. Ces entreprises n'ont pas nécessairement le même matériel informatique à disposition (hétérogénéité des machines Ml, ..., Mn). Le système (Figure 3 : renvoi 01) comporte également un dispositif informatique principal MO (appelé également machine MO), par exemple un serveur UNIX, connecté à un ordinateur équipé d'un écran d'affichage comprenant une zone d'affichage DISPLAY, d'un clavier et d'une souris destinés à l'utilisateur COMMANDE, apte à communiquer avec chaque dispositif Ml,..., Mn au travers du réseau RI, via par exemple une application de type WEB développée en JAVA. Chaque dispositif informatique MO, Ml, M2,..., Mn embarque également un logiciel capable de prendre en charge des plans numériques. Le serveur MO

10/48 dispose des ressources matérielles et logicielles appropriées pour traiter différents types de formats informatiques sous lesquels un plan peut être mémorisé, comme par exemple des fichiers vectorisés de type PDF (pour « portable document format ») ou DWG (format informatique du logiciel AutoCAD©). Le serveur MO dispose des ressources matérielles et logicielles appropriées à la rotation d'images et à la génération de versions miniatures du plan numérique (une réduction du plan numérique) dont l'orientation générale peut être reconnue par un utilisateur connaissant le plan numérique. Au titre de la réalisation préférée de la présente invention que nous avons choisi de décrire, le serveur MO dispose d'une horloge, capable de distribuer des temps.

La communication entre les dispositifs MO, Ml, ..., Mn est par défaut discontinue, de telle sorte que des données collaboratives, susceptibles d'être partagées entre MO, Ml,..., Mn pour le bon fonctionnement du système (Figure 3 : renvoi 01), ne sont pas toujours à tout instant toutes dans un même état en tous points du système (Figure 3 : renvoi 01). Lorsqu'une communication est établie entre deux machines du système (Figure 3 : renvoi 01), les données collaboratives sont comparées et éventuellement mises à jour. Dans le cadre de cette réalisation, les dispositifs informatiques partenaires Ml, M2, ..., Mn établissent des connexions ponctuelles à travers le réseau de communication informatique Rl, avec le serveur central MO (Figure 1 : renvoi 48). On note TjO la date caractérisant le début de l'échange de données collaboratives entre MO et Mj, où Mj est l'une des machines partenaires Ml, M2,..., Mn. Cette date est déterminée par le serveur MO, qui se réfère à son horloge. La date caractérisant la communication précédente entre le serveur MO et ce même dispositif partenaire Mj est notée Tj-1. Chaque dispositif informatique partenaire Mj appartenant à Ml, ..., Mn tient à jour un registre de l'ensemble des communications qu'il établit avec le serveur MO. Il s'agit d'un tableau chronologique dans lequel sont inscrites, pour chaque communication établie avec MO, les dates Tj générées par l'horloge du serveur MO. Ces données sont enregistrées dans la mémoire de stockage du dispositif informatique partenaire Mj concerné. La communication entre le serveur MO et le dispositif Mj est maintenue jusqu'à ce que les données collaboratives aient été mises à niveau ; c'est-à-dire que l'ensemble des données collaboratives modifiées ou nouvelles, connues par le serveur MO, ait été transmis à Mj et enregistré dans sa mémoire de stockage, et que l'ensemble des données collaboratives modifiées ou nouvelles, connues par Mj, ait été transmis à MO et enregistré dans sa mémoire de stockage. Au titre de cette mise à niveau, toutes les données enregistrées dans la mémoire de stockage de MO et dans la mémoire de stockage de Mj sont datées de TjO (date caractérisant la communication considérée). On entend par données collaboratives modifiées ou nouvelles connues par Mj, l'ensemble des données collaboratives qui ont fait l'objet d'une modification ou qui ont été créées, dans la mémoire de stockage de Mj, à une date comprise entre Tj-1 exclue et TjO incluse. On entend par données collaboratives modifiées ou nouvelles connues par MO, l'ensemble des données collaboratives qui ont fait l'objet d'une modification ou qui ont été créées, dans la mémoire de stockage de MO à une date comprise entre Tj-1 exclue et TjO incluse. Cela comprend notamment l'ensemble des données collaboratives communiquées au serveur MO par les autres dispositifs informatiques partenaires Ml,..., Mn,

11/48 différents de Mj, entre les dates Tj-1 exclue et TjO incluse. La première connexion entre le serveur MO et la machine partenaire Mj constitue un cas particulier pour lequel Tj-1 n'existe pas. Dans ce cas spécifique, les données collaboratives modifiées ou nouvelles connues par MO correspondent à l'ensemble des données collaboratives qui ont fait l'objet d'une modification ou qui ont été créées, dans la mémoire de stockage de MO, à une date inférieure ou égale à l'instant TjO caractérisant cette première connexion. De même, les données collaboratives modifiées ou nouvelles connues par Mj correspondent à l'ensemble des données collaboratives qui ont fait l'objet d'une modification ou qui ont été créées, dans la mémoire de stockage de Mj, à une date inférieure ou égale à l'instant TjO caractérisant cette première connexion. La garantie de maintien de la communication entre le serveur MO et le dispositif partenaire Mj est assurée par la mise en oeuvre d'un procédé exploitant, dans le cadre de cette réalisation préférée, les fonctionnalités du protocole d'échange de données http. Mj demande à MO de lui communiquer la date TjO dans une première requête REQ1 (Figure 1 : renvoi 49). En retour, MO diffuse à Mj cette date TjO, qui correspond à la date qu'indique son horloge au moment de l'envoi de cette réponse (Figure 1 : renvoi 52). Mj réceptionne la date TjO et l'enregistre dans sa mémoire vive (Figure 1 : renvoi 53); il se prépare à l'enregistrer dans sa mémoire de stockage au sein du registre chronologique évoqué ciavant, puis demande à MO de lui transmettre ses données collaboratives modifiées ou nouvelles dans une seconde requête REQ2 (Figure 1 : renvoi 54). La date Tj-1, si elle existe, est à ce stade enregistrée dans la mémoire de stockage de Mj uniquement. Elle doit donc être communiquée à MO au cours de cette seconde requête REQ2 (Figure 1 : renvoi 54). En réponse, MO diffuse à Mj les données attendues (Figure 1 : renvoi 56). Mj les réceptionne, les enregistre dans sa mémoire vive (Figure 1 : renvoi 57) et se prépare à les enregistrer dans sa mémoire de stockage en les datant de TjO, suite à quoi il diffuse à MO ses propres données collaboratives modifiées ou nouvelles dans une troisième requête REQ3 (Figure 1 : renvoi 58). MO les réceptionne et les enregistre dans sa mémoire de stockage en les datant de TjO (Figure 1 : renvoi 65), puis il envoie à Mj la réponse annonçant le succès de la troisième requête REQ3 (Figure 1 : renvoi 66). Mj réceptionne cette réponse (Figure 1 : renvoi 67) et enregistre alors dans sa mémoire de stockage les données ci-avant laissées provisoirement en attente dans sa mémoire vive (Figure 1 : renvoi 68). On appelle ce processus de mise à niveau des données collaboratives partagées entre MO et Mj la « synchronisation de MO avec Mj ». Pour le bon fonctionnement du procédé objet de la présente invention il est nécessaire que les données collaboratives partagées entre les dispositifs informatiques MO, Ml, ..., Mn puissent être mises à jour régulièrement, dans un contexte où la communication à travers le réseau de communication informatique RI est, par défaut, discontinue. Le cas de figure où la communication entre les dispositifs MO, Ml, ..., Mn à travers le réseau de communication RI serait une communication continue est un cas favorable en comparaison avec le cas d'une communication discontinue. Ce cas favorable ne serait pas de nature à remettre en cause le procédé objet de la présente invention.

Dans le cadre de la réalisation préférée du procédé objet de la présente invention décrite ciaprès, chaque dispositif partenaire Ml, ..., Mn dispose également d'une horloge, donnant à

12/48 tout instant les mêmes résultats que l'horloge du serveur MO. Ces horloges ne sont pas indispensables et il serait possible d'imaginer des variantes de la présente invention ne les faisant pas intervenir. Pour le bon fonctionnement de la présente invention, et à chaque fois que le serveur MO se synchronise avec l'un des dispositifs partenaires Ml, ..., Mn, il est nécessaire de pouvoir identifier clairement les données collaboratives qui ont été modifiées ou créées dans les mémoires de stockage de l'un et de l'autre des dispositifs informatiques, depuis leur précédente mise en relation. Côté serveur MO, ces données collaboratives modifiées ou créées dans l'intervalle sont clairement repérées par les dates distribuées par l'horloge du serveur MO. Dans le cas présent, on a choisi d'utiliser les horloges des dispositifs partenaires Ml, ..., Mn pour mettre en évidence leurs propres données collaboratives nouvelles ou modifiées. On pourrait également imaginer mettre en œuvre d'autres solutions, utilisant par exemple des indicateurs binaires à la place des horloges des dispositifs partenaires Ml, ..., Mn. Selon cette variante, et lorsqu'une donnée collaborative serait créée ou modifiée au niveau d'un dispositif informatique partenaire Mj, correspondant à l'un des dispositifs informatiques partenaires Ml, ..., Mn du système (Figure 3 : renvoi 01), puis enregistrée dans la mémoire de stockage de ce dispositif partenaire Mj, on pourrait affecter à cette donnée collaborative un marqueur binaire FLAG prenant par exemple, à ce stade, la valeur 1. Juste après une synchronisation de MO avec Mj, après que Mj eut reçu la réponse de MO à la troisième requête REQ3, on pourrait imposer que toutes les données collaboratives enregistrées dans la mémoire de Mj voient leur marqueur binaire FLAG passer à 0. Dans ce cas de figure, les données collaboratives modifiées ou nouvelles enregistrées dans la mémoire de stockage de Mj, et nécessitant d'être transmises au serveur MO au cours d'une synchronisation de MO avec Mj seraient clairement identifiées puisqu'il ne s'agirait que des données collaboratives dont le marqueur FLAG serait égal à 1. Cette variante ne ferait pas intervenir l'horloge des dispositifs informatiques partenaires Ml,..., Mn.

Dans le cadre de cette réalisation les plans numériques constituant les entrants sont des fichiers informatiques dits « sources », DOC_SOURCE, comprenant par ailleurs des données d'identification, NOM_PLAN. Ces plans numériques correspondent, dans le cas présent, à des plans réels en deux dimensions ; c'est-à-dire à des plans qui pourraient être imprimés sur un support physique en deux dimensions, par exemple une feuille de papier, comme il est usuel d'en rencontrer. On fait également référence à des versions intermédiaires qui sont des fichiers informatiques dits « de visualisation », DOC_VISUALISATION, comprenant dans le cas présent une image matricielle et des données de caractérisation éventuelles. L'affichage du plan numérique est assuré par un objet informatique dynamique. L'image matricielle du plan est attachée à un conteneur d'image (balise image « img ») de manière à constituer une représentation fidèle du plan réel dans une orientation donnée. Cet affichage constitue alors une vue orientée du plan numérique NOM_PLAN. La Figure 5 propose une vue orientée d'un plan numérique. La Figure 7 propose une autre vue orientée de ce plan numérique (quart de tour à droite). D'autres solutions d'affichage seraient possibles et pourraient être adaptées au procédé objet de la présente invention. Les fichiers informatiques de visualisation DOC_VISUALISATION permettent donc l'affichage, sur les écrans des dispositifs informatiques

13/48 concernés, d'au moins une vue orientée du plan numérique NOM_PLAN. On définit le repère R* comme étant le repère orthonormé, de norme égale à 1 pixel, prenant pour origine le coin supérieur gauche du conteneur d'image destiné à l'affichage des fichiers de visualisation. L'axe des abscisses est orienté vers la droite et se confond avec le bord supérieur de ce conteneur. L'axe des ordonnées est orienté vers le bas et se confond avec le bord gauche du conteneur. Par convention le premier pixel situé dans le coin supérieur gauche est le point de coordonnées cartésiennes (0;0) dans ce repère R*. Chaque vue orientée du plan numérique NOM_PLAN possède une orientation unique dans le repère R*.

Conformément au sens commun, on entend par fichier informatique une collection d'informations numériques réunies sous un même nom, enregistrées sur un support de stockage permanent, tel qu'un disque dur, un CD-ROM, une mémoire flash ou une bande magnétique, et manipulées comme une unité.

II va à présent être décrit un mode de réalisation d'un procédé de rotation et de partage cohérent de vues orientées d'un plan numérique comportant des données localisées par des dispositifs informatiques collaboratifs, selon l'invention, illustré à titre d'exemple en relation avec des plans numériques sources fournis sous la forme de fichiers PDF, à partir desquels sont produits et mémorisés dans la mémoire de stockage des dispositifs informatiques concernés, des versions intermédiaires du plan numérique, dites de visualisation, destinées à constituer un affichage d'une vue orientée ce plan numérique sur les écrans des dispositifs informatiques concernés par l'intermédiaire d'objets informatiques dynamiques HTML contenant des balises de type conteneurs div ou img. Ces versions intermédiaires peuvent être affichées par exemple au moyen d'un navigateur internet à partir des dispositifs informatiques (MO, Ml,..., Mn) configurés à cet effet.

Le procédé démarre lorsque le fichier source DOC_SOURCE est transmis à l'un des dispositifs informatiques MO, Ml, ..., Mn capable de générer et/ou modifier les fichiers de visualisation du plan DOC_VISUALISATION. Dans le cadre de cette réalisation préférée, le procédé démarre lorsqu'un utilisateur transmet au serveur MO un fichier PDF, DOC_SOURCE, codant le plan numérique. Le serveur MO enregistre dans sa mémoire de stockage ce fichier PDF et ses données d'identification, NOM_PLAN (Figure 2A : renvoi 10).

Un premier algorithme déclenché par l'enregistrement du fichier PDF source commande la production des fichiers de visualisation DOC_VISUALISATION du plan numérique NOM_PLAN (Figure 2A : renvoi 11). Dans le cadre de cette réalisation privilégiée, nous avons choisi de générer un fichier image bitmap de résolution élevée (une image matricielle « carte de points » ou bitmap, en anglais, est une image constituée d'une matrice de points, usuellement colorés ou en niveau de gris, c'est-à-dire, constituée d'un tableau, d'une grille, etc, ou chaque case possède une valeur de couleur ou de niveau de gris qui lui est propre et est considérée comme un point de l'image. II s'agit donc d'une juxtaposition de points de couleurs ou de niveau de gris formant, dans leur ensemble, une image) à partir du fichier PDF source, et de l'enregistrer dans la mémoire de stockage des différents dispositifs informatiques supposés

14/48 l'afficher sous la forme d'un fichier image PNG, accompagné de données de caractérisation éventuelles. Lorsque l'image PNG est affichée par une balise img sur l'écran d'un des dispositifs MO, Ml, ..., Mn, elle constitue une vue orientée du plan numérique NOM_PLAN dans le repère R*. La résolution retenue doit rester compatible avec les ressources matérielles et logicielles dont disposent les dispositifs informatiques MO, Ml, ..., Mn. Nous choisissons une résolution de 100 dpi (dot per inch) pour des plans numériques sources correspondant à des plans réels de taille raisonnable (par exemple des plans réels supposés être imprimés sur du papier A4 de 21cm de côté par 29,7cm, comme il est usuel d'en rencontrer). Ce fichier PNG est réalisé, dans le cadre de cette réalisation préférée, à partir du fichier PDF source :

En produisant un objet de type « Bufferedlmage », appelé BUFFERED_PLAN_O, à partir de la fonction « ConvertTolmage » de la bibliothèque PDFBox,

Puis en utilisant cet objet BUFFERED_PLAN_O, associé à la fonction « ImagelOUtil.writelmage » de la bibliothèque PDFBox.

L'orientation dans le repère R* de chacune des vues orientées du plan numérique NOM_PLAN encodées par des fichiers de visualisation DOC_VISUALISATION est caractérisée par une valeur dite d'orientation maître, notée ORIENT_MAITRE. A ce stade du procédé objet de la présente invention, la valeur d'orientation maître ORIENT_MAITRE associée aux fichiers de visualisation DOC_VISUALISATION qui viennent d'être générés au niveau du serveur MO est par convention égale à 0 (Figure 2A : renvoi 11). La Figure 5 représente une vue orientée d'un plan numérique encodée par des fichiers de visualisation DOC_VISUALISATION caractérisés par une valeur d'orientation maître ORIENT_MAITRE égale à zéro. A titre de comparaison, la Figure 7 représente une vue orientée du même plan numérique, tournée d'un angle de 90° vers la droite par rapport à la vue orientée de la Figure 5. La vue de cette Figure 7 est encodée par des fichiers de visualisation DOC_VISUALISATION caractérisés par une valeur d'orientation maître ORIENT_MAITRE égale à 90. Dans le cadre de cette réalisation préférée, chaque dispositif informatique MO, Ml,..., Mn ne peut afficher, à un instant donné, qu'une seule vue orientée du plan numérique NOM_PLAN, qui correspond à la vue orientée encodée par la version des fichiers de visualisation DOC_VISUALISATION la plus récente qui est enregistrée dans sa mémoire de stockage à cet instant (Figure 2A : renvois 12a et 12b). Dans le cadre de cette réalisation préférée, chaque dispositif informatique MO, Ml,..., Mn ne conserve dans sa mémoire de stockage qu'une valeur d'orientation maître ORIENT_MAITRE, au plus, pour le plan numérique NOM_PLAN considéré, qui correspond à la valeur d'orientation maître de la version des fichiers de visualisation la plus récente dont il dispose. Ces fichiers de visualisation DOC_VISUALISATION, ainsi que leur couple d'identification (ORIENT_MAITRE ; NOM_PLAN) font partie des données collaboratives partagées entre les dispositifs informatiques MO, Ml, ..., Mn du système (Figure 3 : renvoi 01), de telle sorte que, dans un état de parfaite cohérence du système (Figure 3 : renvoi 01), tous les dispositifs informatiques MO, Ml, ..., Mn ont enregistré dans leur mémoire de stockage respective la même version des fichiers de visualisation DOC_VISUALISATION du plan numérique NOM_PLAN, identifiée par la même valeur d'orientation ORIENT_MAITRE, et affichent donc la même vue orientée du plan

15/48 numérique NOM_PLAN. Le partage est assuré par la méthode de synchronisation de MO avec chacun des dispositifs informatiques partenaires Ml, ..., Mn, décrites ci-avant (Figure 2A : renvois 12a et 12b). De manière à pleinement satisfaire les conditions de fonctionnement de cette méthode de synchronisation, la date d'enregistrement dans la mémoire de stockage de MO des fichiers de visualisation DOC_VISUALISATION est bien entendu également enregistrée dans la mémoire de stockage de MO. Cette date est communiquée par l'horloge du serveur MO.

Dans le contexte de travail collaboratif de la présente description détaillée, les utilisateurs produisent des données collaboratives de travail DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILZ, depuis un ou plusieurs des dispositifs informatiques MO, Ml, ..., Mn, localisées sur une vue orientée du plan numérique NOM_PLAN. Chaque donnée collaborative de travail est ponctuellement repérée, dans le référentiel R*, par ses coordonnées cartésiennes (xi ; yi), i variant de 1 à Z. La position de ces points dans l'espace est susceptible d'être impactée par un changement d'orientation de la vue orientée sur laquelle ils sont localisés dans R* (rotation du plan), ce qui est de nature à modifier les valeurs (xi ; yi). Chaque donnée collaborative de travail est produite en lien avec les fichiers de visualisation DOC_VISUALISATION d'un couple (ORIENT_MAITRE ; NOM_PLAN) unique. Dans le cas présent, chaque donnée de travail produite à partir d'un des dispositifs informatiques MO, Ml, ..., Mn. Elle est localisée dans le repère R* par un utilisateur, sur la vue orientée du plan numérique NOM_PLAN affichée par le dispositif informatique concerné (Figue 2A : renvois 13a et 13b), puis enregistrée, avec ses coordonnées dans R*, dans la mémoire de stockage de ce dispositif informatique en étant associée au couple (ORIENT_DONNEE ; NOM_PLAN), où ORIENT_DONNEE est égale à la valeur ORIENT_MAITRE connue par le dispositif informatique en question à cet instant (Figure 2A : renvois 14a et 14b). L'utilisateur peut par exemple localiser la donnée collaborative de travail qu'il est en train de produire en inscrivant ses coordonnées dans le repère R* dans un champ de saisie prévu à cet effet, comme il est usuel de le voir, et en utilisant le moyen de commande COMMANDE du dispositif informatique mis en jeu. Ces données collaboratives de travail, ainsi que leur couple caractéristique (ORIENT_DONNE ; NOM_PLAN) et leurs coordonnées dans le repère R*, font également partie des données collaboratives partagées entre les dispositifs informatiques MO, Ml, ..., Mn par la mise en oeuvre de la méthode de synchronisation de MO avec chacun des dispositifs informatiques partenaires Ml, ..., Mn, décrite ci-avant. Pour le bon fonctionnement de la méthode de synchronisation décrite, et dans le cadre de cette réalisation préférée, on rappelle que les dispositifs informatiques partenaires Ml, ..., Mn sont chacun dotés d'une horloge, donnant à tout instant les mêmes résultats que l'horloge du serveur MO. Toutes les données collaboratives de travail DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILZ sont alors, dans le cas présent, datées au moment où elles sont produites et enregistrées sur leur dispositif informatique MO, Ml,..., Mn d'origine. Dans le cas de cette réalisation préférée, à chaque fois qu'une donnée collaborative de travail est échangée entre deux dispositifs informatiques MO, Ml, ..., Mn, ses coordonnées la localisant dans le référentiel R* l'accompagnent ; il en est de même pour le couple (ORIENT_DONNEE ; NOM_PLAN) qui lui est associé.

16/48

Au titre de cette réalisation préférée, un utilisateur peut générer au moins une donnée collaborative de travail supplémentaire (DOC_TRAVAILZ+1) à n'importe quel moment du procédé et depuis n'importe quel dispositif informatique MO, Ml, ..., Mn. Cette donnée collaborative de travail supplémentaire (DOC_TRAVAILZ+1) serait intégrée à la liste des données collaboratives de travail (DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILZ) dès l'instant où elle serait enregistrée dans la mémoire de stockage de son dispositif informatique d'origine. Une variante du procédé décrit qui consisterait à interdire aux utilisateurs de générer des données collaboratives de travail supplémentaires (DOC_TRAVAILZ+1) pendant le déroulement du procédé objet de l'invention, ou qui consisterait à ne pas les intégrer à la liste des données collaboratives de travail (DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILZ) couvertes par le procédé objet de l'invention, constituerait un cas favorable et une version dégradée de la présente réalisation préférée.

Dans le cadre de cette réalisation préférée, un autre algorithme déclenché par l'enregistrement du fichier PDF source commande la production d'un fichier codant une miniature représentant le plan numérique NOM_PLAN (Figure 2A : renvois 15). Dans le cadre de cette réalisation préférée, la miniature est produite sous la forme d'une image bitmap de faible résolution. La miniature est générée de manière à ce que, une fois affichée sur l'écran de l'ordinateur connecté au serveur MO, un utilisateur connaissant le plan numérique puisse, d'un coup d'œil, reconnaître son orientation dans le repère R*. Elle est également paramétrée dans le but de pouvoir constituer un objet informatique dynamique HTML facilement manipulable par MO et dont le niveau de consommation en ressource d'affichage est inférieur à celui nécessaire à l'affichage du plan numérique NOM_PLAN mettant en œuvre les fichiers de visualisation DOC_VISUALISATION. Dans le cadre de cette réalisation préférée, nous avons fait le choix d'une miniature au format PNG (Portable Network Graphie), de résolution 20dpi (dot per inch), s'inscrivant dans un conteneur image (balise img) rectangulaire, dont le plus grand des côtés est égal à 250 pixels. Un utilisateur peut ainsi facilement en visualiser l'intégralité sur une machine disposant d'un écran de plus de 250 pixels de côté, comme il est usuel d'en rencontrer aujourd'hui (ordinateur portable possédant une résolution de 1024 pixels par 768 pixels, par exemple). Dans le cadre de cette réalisation, l'algorithme génère puis enregistre dans la mémoire de stockage de MO un fichier image au format PNG de résolution 20dpi :

En produisant, à partir du fichier PDF source, un objet de type « Bufferedlmage » généré en utilisant la fonction « ConvertTolmage » de la bibliothèque PDFBox, que l'on appelle BUFFERED_O

Puis en utilisant la fonction « ImagelOUtil.writelmage » de la bibliothèque PDFBox, mobilisant l'objet BUFFERED_O

La miniature du plan numérique source peut être ainsi affichée, dans le cadre de cette réalisation préférée, sur l'écran de l'ordinateur connecté au serveur MO, au moyen d'un objet informatique dynamique constitué d'une balise image « img » contenant l'image PNG qui a été mémorisée par MO.

17/48

L'algorithme enregistre également un paramètre orientation qui est associé à cette miniature, ORIENTMINI, ayant pour valeur zéro. Cette miniature est donc définie par le fichier source et ses données d'identification, (DOC_SOURCE, NOM_PLAN), l'image PNG générée (MINI_0_PLAN) et une valeur orientation égale à zéro (ORIENTMINI). (Figure 2A : renvois 15)

Le procédé objet de la présente invention intègre également la préparation d'autres versions miniatures, correspondant à des rotations du plan NOM_PLAN ; c'est-à-dire à des vues orientées du plan numérique NOM_PLAN disposées dans une orientation différente dans le repère R* (Figure 2A : renvois 16, 17, 18). Dans le cadre de cette réalisation préférée, nous avons choisi de retenir les trois rotations classiquement utilisées en matière de lecture de plans en deux dimensions, qui sont :

La rotation de +90 degrés dans le sens horaire (quart de tour à droite)

La rotation de +180 degrés dans le sens horaire (demi-tour)

La rotation de +270 degrés dans le sens horaire (quart de tour à gauche)

Dans le cadre de cette réalisation préférée, chacune de ces trois versions est produite en opérant une rotation de la miniature d'orientation zéro. La solution mise en œuvre au titre de cette rotation n'a pas d'importance et peut être quelconque. Dans le cadre de cette réalisation préférée, nous avons retenu un procédé de rotation adapté aux images de type bitmap, consistant à déplacer un à un chacun des pixels de l'image initiale jusqu'à constituer l'image finale voulue.

On définit le repère RI comme étant le repère orthonormé, de norme égale à 1 pixel, prenant pour origine le coin supérieur gauche de l'image bitmap à tourner. L'axe des abscisses est orienté vers la droite et se confond avec le bord supérieur de cette image. L'axe des ordonnées est orienté vers le bas et se confond avec le bord gauche du conteneur. Par convention le premier pixel situé dans le coin supérieur gauche est le point de coordonnées cartésiennes (0;0) dans ce repère RI.

En appliquant la fonction « getHight » à l'objet BUFFERED_O, on obtient la valeur Hmini qui est égale à sa hauteur, en pixels. En appliquant la fonction « getWidth » à l'objet BUFFERED_O, on obtient la valeur Lmini qui est égale à sa largeur en pixels. Dans le repère RI, le pixel situé dans le coin supérieur gauche de BUFFERED_O est le pixel PmO de coordonnées (0 ; 0). Le pixel situé dans le coin supérieur droit de BUFFERED_O est le pixel PmO de coordonnées (Lmini-1 ; 0). Le pixel situé dans le coin inférieur droit de BUFFERED_O est le pixel PmO de coordonnées (Lmini - 1 ; Hmini -1). Le pixel situé dans le coin inférieur gauche de BUFFERED_O est le pixel PmO de coordonnées (0; Hmini - 1). D'une manière générale, un pixel quelconque de BUFFERED_O est appelé PmO (x ; y).

La miniature que l'on souhaite construire, et qui correspond à un quart de tour à droite (+90 degrés dans le sens horaire) est constituée d'un fichier image PNG appelé MINI_90_PLAN, enregistré dans la mémoire de stockage de MO, et généré à partir d'un objet de type

18/48 « Bufferedlmage » appelé BUFFERED_90. Sa valeur ORIENTMINI est égale à 90 (Figure A2 : renvois 16). Un pixel quelconque de BUFFERED_90 est noté Pm90 (X; Y). On réalise une transformation de BUFFERED_O en BUFFERED_90 en donnant au pixel Pm90 (X ; Y), pour tout x compris entre 0 et Lmini - 1 et tout y compris entre 0 et Hmini - 1, la valeur de couleur correspondant à celle du pixel PmO de coordonnées (x ; y) tel que :

X = Hmini - y- 1

Y = x

La miniature que l'on souhaite construire, et qui correspond à un demi-tour à droite (+180 degrés dans le sens horaire) est constituée d'un fichier image PNG appelé MINI_180_PLAN, enregistré dans la mémoire de stockage de MO, et généré à partir d'un objet de type « Bufferedlmage » appelé BUFFERED_180. Sa valeur ORIENTMINI est égale à 180 (Figure 2A : renvois 17). Un pixel quelconque de BUFFERED_180 est noté Pml80 (X; Y). On réalise une transformation de BUFFERED_O en BUFFERED_180 en donnant au pixel Pml80 (X; Y), pour tout x compris entre 0 et Lmini - 1 et tout y compris entre 0 et Hmini - 1, la valeur de couleur correspondant à celle du pixel PmO de coordonnées (x ; y) tel que :

X = Lmini - 1 -x

Y = Hmini - 1 -y

La miniature que l'on souhaite construire, et qui correspond à un quart de tour à gauche (+270 degrés dans le sens horaire) est constituée d'un fichier image PNG appelé MINI_270_PLAN, enregistré dans la mémoire de stockage de MO, et généré à partir d'un objet de type « Bufferedlmage » appelé BUFFERED_270. Sa valeur ORIENTMINI est égale à 270 (Figure 2A : renvois 18). Un pixel quelconque de BUFFERED_270 est noté Pm270 (X; Y). On réalise une transformation de BUFFERED_O en BUFFERED_270 en donnant au pixel Pm270 (X; Y), pour tout x compris entre 0 et Lmini - 1 et tout y compris entre 0 et Hmini - 1, la valeur de couleur correspondant à celle du pixel PmO de coordonnées (x ; y) tel que :

X = y

Y = Lmini - 1 - x

La valeur de couleur du pixel PmO (x; y) est obtenue, dans le cadre de cette réalisation, en utilisant la fonction getRGB (x ; y) appliquée à BUFFERED_O. La valeur de couleur du pixel Pm90 (X ; Y) est définie en utilisant la fonction setRGB(X ; Y) appliquée à BUFFERED_90. La valeur de couleur du pixel Pml80 (X ; Y) est définie en utilisant la fonction setRGB (X ; Y) appliquée à BUFFERED_180. La valeur de couleur du pixel Pm270 (X ; Y) est définie en utilisant la fonction setRGB (X ; Y) appliquée à BUFFERED_270.

19/48

La génération de ces miniatures nécessite du temps ; et ce délai dépend notamment de la complexité du plan numérique source, de la résolution des miniatures retenues, du nombre de rotations retenues, de l'efficacité du procédé de génération de miniatures retenu, de l'efficacité du procédé de rotation retenu. A chaque fois qu'une miniature avec une valeur ORIENTMINI différente de zéro est générée, l'algorithme commande l'enregistrement des fichiers de données codant cette miniature dans la mémoire de stockage du dispositif informatique MO et enregistre également le paramètre orientation ORIENTMINI qui lui est associé. Dans le cadre de cette réalisation préférée, les miniatures sont enregistrées au format PNG au moyen de la fonction « ImagelOUtil.writelmage » de la bibliothèque PDFBox. Dans le cadre de cette réalisation particulière, et une fois les trois rotations effectuées, on a donc en mémoire quatre versions miniatures du plan numérique source, définies par le fichier source et ses données d'indentification, (DOC_SOURCE, NOM_PLAN), un fichier image PNG généré (MINI_0_PLAN ; MINI_90_PLAN ; MINI_180_PLAN ; MINI_270_PLAN) et une valeur orientation (ORIENTMINI, respectivement égale à 0 ; 90 ; 180 ; 270).

On remarquera à ce stade que :

L'image PNG MINI_0_PLAN équivaut à une réduction de l'image PNG des fichiers de visualisation DOC_VISUALISATION codant la vue orientée du plan numérique NOM_PLAN dont l'orientation maître ORIENT_MAITRE est égale à zéro.

L'image PNG MINI_90_PLAN équivaut à une réduction de l'image PNG des fichiers de visualisation DOC_VISUALISATION codant la vue orientée du plan numérique NOM_PLAN dont l'orientation maître ORIENT_MAITRE est égale à zéro après que celle-ci ait effectué un quart de tour à droite dans le repère R*.

L'image PNG MINI_180_PLAN équivaut à une réduction de l'image PNG des fichiers de visualisation DOC_VISUALISATION codant la vue orientée du plan numérique NOM_PLAN dont l'orientation maître ORIENT_MAITRE est égale à zéro après que celle-ci ait effectué un demi-tour dans le repère R*.

L'image PNG MINI_270_PLAN équivaut à une réduction de l'image PNG des fichiers de visualisation DOC_VISUALISATION codant la vue orientée du plan numérique NOM_PLAN dont l'orientation maître ORIENT_MAITRE est égale à zéro après que celle-ci ait effectué un quart de tour à gauche dans le repère R*.

Cela est mis en évidence par la Figure 8, qui schématise par la même occasion les objets informatiques BUFFERED_PLAN_O, BUFFERD_0, BUFFERD_90, BUFFERD_180, et BUFFERD_270,

On poursuit alors le procédé objet de la présente invention en mettant à la disposition de l'utilisateur une commande lui permettant d'ordonner l'affichage des vues miniatures du plan numérique source depuis au moins l'un des dispositifs informatiques MO, Ml, ..., Mn. Cette commande n'est accessible depuis le dispositif informatique en question qu'à partir du moment où les miniatures ont toutes bel et bien été enregistrées dans sa mémoire de stockage (Figure 2A : renvoi 19). On peut par exemple mettre en oeuvre ici la méthode de

20/48 synchronisation de MO avec chacun des dispositifs informatiques partenaires Ml, Mn, de manière à partager ces miniatures et leurs informations associées entre les différentes machines du système (Figure 3 : renvoi 01). Dans le cadre de cette réalisation privilégiée, c'est le serveur MO lui-même qui permet à l'utilisateur de commander l'affichage des quatre miniatures du plan numérique source sur l'écran de l'ordinateur auquel il est connecté. La commande en question est matérialisée par un bouton affiché à l'écran de l'ordinateur, et sur lequel l'utilisateur peut cliquer en utilisant la souris de cet ordinateur (COMMANDE), comme il est usuel de le faire. Le bouton en question peut par exemple être matérialisé par un conteneur « div » de couleur unie, contenant une mention lisiblement écrite adaptée, comme par exemple « modifier l'orientation de votre plan numérique ». Cet évènement déclenche l'affichage des versions miniatures sur l'écran de l'ordinateur connecté au serveur MO (DISPLAY). Dans le cadre d'une utilisation de ce procédé mettant en œuvre plusieurs plans numériques sources, il convient de proposer à l'utilisateur un bouton de commande par plan numérique source, de manière à différencier les miniatures à afficher. Le bouton de commande peut par exemple porter le nom du plan numérique source (NOM_PLAN), conduisant à l'affichage des versions miniatures ad hoc. Au titre de la réalisation particulière qui nous concerne, il a été décidé que les miniatures de valeur ORIENTMINI égale à 90, 180, et 270 seraient générées les unes après les autres, et dans cet ordre. La miniature ayant la valeur ORIENTMINI égale à 270 sera donc nécessairement la dernière à être générée. L'algorithme ne créé le bouton de commande d'affichage des miniatures qu'une fois la miniature d'orientation 270 enregistrée dans la mémoire de stockage de MO ; de cette façon les conditions de temporalité de la présente réalisation sont respectées.

Lorsque l'utilisateur le commande, les miniatures sont donc affichées. Dans le cas présent, l'affichage est assuré, sur l'écran de l'ordinateur connecté au serveur MO, par un objet informatique dynamique HTML composé de balises images « img » contenant les images codant les miniatures. Chaque miniature est inscrite dans un conteneur dont la plus grande des dimensions est inférieure à 250pixels, de manière à ce que l'ensemble, constituant approximativement un carré de 500pixels de côté, puisse être entièrement affiché sur un écran d'ordinateur usuel d'au moins 1024 pixels par 768 pixels. D'autres solutions d'affichage sont envisageables. Le procédé objet de la présente invention a simplement besoin de permettre à l'utilisateur de visualiser les miniatures dans leur orientation native, soit ensemble, soit successivement. Nous avons choisi d'afficher les quatre miniatures en même temps, mais il est également envisageable de les afficher les unes après les autres, ou en sousgroupes.

Le procédé objet de la présente invention permet à l'utilisateur de sélectionner une orientation privilégiée en choisissant l'une de ces miniatures. Dans le cadre de cette réalisation préférée une et une seule de ces miniatures est mise en valeur par un moyen permettant à l'utilisateur de comprendre qu'il s'agit de l'orientation actuelle du plan ; c'est-àdire la vue orientée dans R* du plan numérique NOM_PLAN dont les fichiers de visualisation DOC_VISUALISATION et l'orientation maître ORIENT_MAITRE sont supposés partagés avec

21/48 l'ensemble des dispositifs informatiques MO, Ml,..., Mn. Avant que l'utilisateur ne commande une rotation, l'orientation actuelle du plan correspond à l'orientation ORIENTMINI de MINI_0_PLAN, qui par construction est une version réduite et sans rotation du plan numérique source. La valeur ORIENT_MAITRE qui est enregistrée dans la mémoire de stockage des dispositifs informatiques MO, Ml, ..., Mn vaut alors 0. Dans le cadre de cette réalisation préférée, nous avons choisi de mettre en valeur cette miniature de référence en l'encadrant de manière prononcée. Pour cela, nous nous appuyons sur l'attribut « border » du conteneur « img » contenant MINI_0_PLAN. Par exemple « border : 5pxsolid red » pour un encadrement rouge de 5 pixels d'épaisseur. Dans le même temps, les conteneurs « img » correspondant aux autres miniatures sont traités uniformément dans un autre style. Par exemple, on peut retenir pour eux un encadrement plus fin, et d'une autre couleur, tel que « border : lpx solid black » pour un encadrement noir de 1 pixel d'épaisseur. Le procédé de mise en valeur retenu n'a pas d'importance et l'on pourrait imaginer des variantes telles que :

Faire par exemple varier la taille d'affichage des miniatures Faire par exemple varier la polychromie des miniatures,

Marquer par exemple les miniatures d'un symbole caractéristique

L'utilisateur ordonne une rotation en sélectionnant l'orientation de son choix (Figure 2A : renvoi 20). Cette orientation, dite orientation sélectionnée, notée ORIENT, caractérise l'orientation dans le référentiel R* de la vue privilégiée à laquelle l'utilisateur souhaite aboutir. Dans le cadre de cette réalisation préférée, la sélection de cette orientation ORIENT se déroule comme suit :

Comme il est usuel de le rencontrer, la position de la souris de l'ordinateur connecté à MO est matérialisée à l'écran par un pointeur que l'utilisateur peut mettre librement en mouvement. L'utilisateur positionne ce pointeur au-dessus de l'image de la miniature correspondant à l'orientation désirée, affichée à l'écran, puis clique sur la souris. Cette action de clic est un évènement qui modifie les objets informatiques dynamiques HTML affichés à l'écran. L'attribut border du conteneur « img » contenant l'une des miniatures du plan au-dessus duquel est positionné le pointeur prend des valeurs correspondant à un encadrement continu rouge de 5 pixels d'épaisseur « border : 5px solid red ». Dans le même temps, tous les autres conteneurs « img » contenant d'autres miniatures du plan prennent des valeurs correspondant à un encadrement noir de 1 pixel d'épaisseur « border : lpx solid black ».

L'utilisateur peut modifier ce choix provisoire en répétant le processus de l'alinéa précédent. Il positionne son pointeur au-dessus du conteneur « img » contenant une miniature du plan, puis clique. L'attribut border du conteneur « img » contenant la miniature en question est modifié (border : 5px solid red) et tous les autres conteneurs « img » contenant d'autres miniatures voient leur attribut border reprendre la valeur de désélection, à savoir « border : lpx solid black ».

22/48

Un bouton de confirmation définitive est affiché sur l'écran de l'ordinateur connecté à MO. Il est matérialisé par un conteneur « div » de couleur unie, contenant par exemple la mention lisiblement écrite « confirmer cette orientation », distant des conteneurs « img » contenant les miniatures. L'utilisateur confirme l'orientation sélectionnée ORIENT en positionnant le pointeur de la souris au-dessus de ce conteneur « div » et en cliquant.

D'autres procédés de sélection sont également possibles. On peut par exemple imaginer que l'utilisateur se serve des flèches directionnelles « droite » et « gauche » du clavier de commande de l'ordinateur connecté à MO pour modifier le conteneur « img » contenant une miniature du plan dont l'encadrement est mis en valeur par un affichage rouge de 5 pixels d'épaisseur. L'utilisateur confirmerait son choix en appuyant sur la touche entrée de ce clavier.

Le procédé objet de la présente invention se poursuit lorsque l'utilisateur confirme l'orientation sélectionnée ORIENT (Figure 2A : renvoi 20), après avoir choisi l'une des miniatures du plan numérique identifié par la valeur NOM_PLAN. A partir de ce stade, les opérations qui vont suivre, citées aux alinéas ci-après, sont traitées comme un tout, ne donnant lieu à un enregistrement d'informations dans la mémoire de stockage des dispositifs informatiques concernées qu'au terme d'une transaction qui leur est dédiée, appelée la première transaction, TRANSI :

Ouverture de la transaction TRANSI (Figure 2A : renvoi 21).

Modification des fichiers de visualisation DOC_VISUALISATION du plan numérique NOM_PLAN, en tenant compte de l'orientation sélectionnée ORIENT, égale à l'orientation ORIENTMINI de la miniature choisie par l'utilisateur (Etape Al). (Figure 2A : renvoi 22).

Modification, en tenant compte de l'orientation sélectionnée ORIENT, égale à l'orientation ORIENTMINI de la miniature choisie par l'utilisateur, de la localisation dans le repère R* et de la valeur ORIENT_DONNEE des données collaboratives de travail DOCTRAVAILl, DOC_TRAVAIL2, ..., DOC_TRAVAILM rattachées au plan numérique NOM_PLAN et enregistrées dans la mémoire de stockage du dispositif informatique depuis lequel le choix de l'orientation est effectué au moment l'ouverture de la transaction TRANSI (dans le cadre de cette réalisation préférée, il s'agit des données collaboratives de travail concernant le plan numérique NOM_PLAN, enregistrées dans la mémoire de stockage du serveur MO au moment de l'ouverture de la transaction TRANSI) (Etape Bl) (Figure 2A : renvoi 22). Modification de la valeur ORIENT_MAITRE associée (dans le cadre de cette réalisation préférée, il s'agit de la valeur ORIENT_MAITRE concernant le plan numérique NOM_PLAN, enregistrée dans la mémoire de stockage du serveur MO au moment de l'ouverture de la transaction TRANSI), en tenant compte de

23/48 l'orientation sélectionnée ORIENT, égale à l'orientation ORIENTMINI de la miniature choisie par l'utilisateur (Etape Cl) (Figure 2A : renvoi22).

Validation de la transaction TRANSI (Figure 2B : renvoi 23) donnant lieu à l'enregistrement des données modifiées ORIENT_MAITRE, DOC_VISUALISATION (Figure 2A : renvoi 12a), DOCTRAVAILl, DOC_TRAVAIL2, ..., DOC_TRAVAILM associées à leurs coordonnées dans R* et à leur valeur ORIENT_DONNEE, relatives au plan numérique NOM_PLAN (Figure 2A : renvoi 14a), dans la mémoire de stockage du dispositif informatique depuis lequel le traitement a été fait, c'est-àdire MO. La date de modification de ces données est égale à la date de validation de la transaction TRANSI. Cette date est communiquée par l'horloge du serveur MO. Elle est enregistrée dans la mémoire de stockage du serveur MO en même temps que le sont les données modifiées de manière à pouvoir assurer la diffusion aux autres dispositifs informatiques partenaires Ml, ..., Mn, en mettant par exemple en oeuvre la méthode de synchronisation de MO avec chacun des dispositifs informatiques partenaires Ml,..., Mn, décrite ci-avant.

De manière à garantir la fiabilité du traitement souhaité, nous mettons en oeuvre, dans le cadre de cette réalisation préférée, une solution s'appuyant sur une transaction respectant les propriétés ACID (Atomicité, Cohérence, Isolation, Durabilité). On rappelle que la propriété d'Atomicité assure qu'une transaction se fait au complet ou pas du tout : si une partie d'une transaction ne peut être faite, il faut effacer toute trace de la transaction et remettre les données dans l'état où elles étaient avant la transaction. L'Atomicité doit être respectée dans toutes situations. On rappelle que la propriété de Cohérence assure qu'une transaction amènera le système d'un état valide à un autre état valide. Tout changement dans la base de données doit être valide selon toutes les règles définies. On rappelle que la propriété d'isolation assure que l'exécution simultanée de transactions produit le même état que celui qui serait obtenu par l'exécution en série des transactions. On rappelle que la propriété de Durabilité assure que lorsqu'une transaction a été confirmée, elle demeure enregistrée même à la suite d'une panne d'électricité, d'une panne du dispositif informatique ou d'un autre problème. Dans le cadre de cette réalisation préférée, nous utilisons les commandes « startTransaction » et « commit » pour définir le démarrage (appelée également ouverture) puis la validation de la transaction.

La modification des fichiers de visualisation DOC_VISUALISATION du plan numérique NOM_PLAN, en tenant compte de l'orientation sélectionnée ORIENT, qui constitue l'Etape Al (Figure 2A : renvoi 22), est réalisée, dans le cadre de cette réalisation préférée, en opérant une rotation appropriée de l'objet de type Bufferedlmage généré à partir du fichier PDF source codant le plan numérique, BUFFERED_PLAN_O. Pour cela, on commence par reproduire, sur le serveur MO, l'objet temporaire BUFFERED_PLAN_O à partir du plan PDF source, en utilisant la fonction « ConvertTolmage » de la bibliothèque PDFBox, et en visant, pour rappel, une image finale de résolution 100 dpi (dot per inch). On définit le repère R2 comme étant le repère orthonormé, de norme égale à 1 pixel, prenant pour origine le coin supérieur gauche

24/48 de cette image bitmap à tourner. L'axe des abscisses est orienté vers la droite et se confond avec le bord supérieur de cette image. L'axe des ordonnées est orienté vers le bas et se confond avec le bord gauche du conteneur. Par convention le premier pixel situé dans le coin supérieur gauche est le point de coordonnées cartésiennes (0;0) dans ce repère R2.

En appliquant la fonction « getHight » à l'objet BUFFERED_PLAN_O, on obtient la valeur Hplan qui est égale à sa hauteur, en pixels. En appliquant la fonction « getWidth » à l'objet BUFFERED_PLAN_O, on obtient la valeur Lplan qui est égale à sa largeur en pixels. Dans le repère R2, le pixel situé dans le coin supérieur gauche de BUFFERED_PLAN_O est le pixel PpO de coordonnées (0 ; 0). Le pixel situé dans le coin supérieur droit de BUFFERED_PLAN_O est le pixel PpO de coordonnées (Lplan-1 ; 0). Le pixel situé dans le coin inférieur droit de BUFFERED_PLAN_0 est le pixel PpO de coordonnées (Lplan - 1 ; Hplan - 1). Le pixel situé dans le coin inférieur gauche de BUFFERED_PLAN_0 est le pixel PpO de coordonnées (0 ; Hplan 1). D'une manière générale, un pixel quelconque de BUFFERED_PLAN_0 est appelé PpO (x ; y)·

Si la valeur ORIENT est égale à 0, les fichiers de visualisation DOC_VISUALISATION du plan numérique NOM_PLAN sont directement modifiés à partir de BUFFERED_PLAN_0. On note provisoirement Lrot la dimension Lplan. On note provisoirement Hrot la dimension Hplan. Dans le cadre de cette réalisation préférée, le fichier image bitmap qui sert à la construction de l'objet informatique dynamique de visualisation est alors remplacé par le fichier image PNG généré à partir de BUFFERED_PLAN_0 et de la fonction « ImagelOUtil.writelmage » de la bibliothèque PDFBox. Cette modification est enregistrée dans la mémoire de stockage de MO au moment de la validation de la transaction TRANSI. La dimension Lrot est enregistrée dans la mémoire de stockage de MO au moment de la validation de la transaction TRANSI ; on la renomme alors Ldoc. La dimension Hrot est également enregistrée dans la mémoire de stockage de MO au moment de la validation de la transaction TRANSI ; on la renomme alors Hdoc. Ldoc et Hdoc constituent des données de caractérisation des fichiers de visualisation DOC_VISUALISATION du plan numérique NOM_PLAN.

Si la valeur ORIENT est égale à 90, les fichiers de visualisation DOC_VISUALISATION du plan numérique NOM_PLAN sont modifiés à partir d'un objet de type « Bufferedlmage » appelé BUFFERED_PLAN_90, qui correspond à une rotation de BUFFERED_PLAN_0 d'un angle de +90 degrés dans le sens horaire (quart de tour à droite). Un pixel quelconque de BUFFERED_PLAN_90 est noté Pp90 (X ; Y). On réalise dans le cadre de cette réalisation une transformation de BUFFERED_PLAN_0 en BUFFERED_PLAN_90 en donnant au pixel Pp90 (X; Y), pour tout x compris entre 0 et Lplan- 1 et tout y compris entre 0 et Hplan - 1, la valeur de couleur correspondant à celle du pixel PpO de coordonnées (x ; y) tel que :

X = Hplan -y- 1

Y = x

25/48

On note Lrot la largeur de BUFFERED_PLAN_90 obtenue avec la fonction « getWidth ». On note Hrot la hauteur de BUFFERED_PLAN_90 obtenue avec la fonction « getHight ». Le fichier image bitmap qui sert à la construction de l'objet informatique dynamique de visualisation est alors remplacé par le fichier image PNG généré à partir de BUFFERED_PLAN_90 et de la fonction « ImagelOUtil.writelmage » de la bibliothèque PDFBox. Cette modification est enregistrée dans la mémoire de stockage de MO au moment de la validation de la transaction TRANSI. La dimension Lrot est enregistrée dans la mémoire de stockage de MO au moment de la validation de la transaction TRANSI ; on la renomme alors Ldoc. La dimension Hrot est également enregistrée dans la mémoire de stockage de MO au moment de la validation de la transaction TRANSI ; on la renomme alors Hdoc. Ldoc et Hdoc constituent des données de caractérisation des fichiers de visualisation DOC_VISUALISATION du plan numérique NOM_PLAN.

Si la valeur ORIENT est égale à 180, les fichiers de visualisation DOC_VISUALISATION du plan numérique NOM_PLAN sont modifiés à partir d'un objet de type « Bufferedlmage » appelé BUFFERED_PLAN_180, qui correspond à une rotation de BUFFERED_PLAN_O d'un angle de +180 degrés dans le sens horaire (demi-tour). Un pixel quelconque de BUFFERED_PLAN_180 est noté Ppl80 (X; Y). On réalise une transformation de BUFFERED_PLAN_O en BUFFERED_PLAN_180 en donnant au pixel Ppl80 (X ; Y), pour tout x compris entre 0 et Lplan - 1 et tout y compris entre 0 et Hplan - 1, la valeur de couleur correspondant à celle du pixel PpO de coordonnées (x ; y) tel que :

X = Lplan - 1 - x

Y = Hplan - 1 - y

On note Lrot la largeur de BUFFERED_PLAN_180 obtenue avec la fonction « getWidth ». On note Hrot la hauteur de BUFFERED_PLAN_180 obtenue avec la fonction « getHight ». Le fichier image bitmap qui sert à la construction de l'objet informatique dynamique de visualisation est alors remplacée par le fichier image PNG généré à partir de BUFFERED_PLAN_180 et de la fonction « ImagelOUtil.writelmage » de la bibliothèque PDFBox. Cette modification est enregistrée dans la mémoire de stockage de MO au moment de la validation de la transaction TRANSI. La dimension Lrot est enregistrée dans la mémoire de stockage de MO au moment de la validation de la transaction TRANSI ; on la renomme alors Ldoc. La dimension Hrot est également enregistrée dans la mémoire de stockage de MO au moment de la validation de la transaction TRANSI ; on la renomme alors Hdoc. Ldoc et Hdoc constituent des données de caractérisation des fichiers de visualisation DOC_VISUALISATION du plan numérique NOM_PLAN.

Si la valeur ORIENT est égale à 270, les fichiers de visualisation DOC_VISUALISATION du plan numérique NOM_PLAN sont modifiés à partir d'un objet de type « Bufferedlmage » appelé

26/48

BUFFERED_PLAN_270, qui correspond à une rotation de BUFFERED_PLAN_O d'un angle de +270 degrés dans le sens horaire (quart de tour à gauche). Un pixel quelconque de BUFFERED_PLAN_270 est noté Pp270 (X; Y). On réalise une transformation de BUFFERED_PLAN_O en BUFFERED_PLAN_270 en donnant au pixel Pp270 (X ; Y), pour tout x compris entre 0 et Lplan - 1 et tout y compris entre 0 et Hplan - 1, la valeur de couleur correspondant à celle du pixel PpO de coordonnées (x ; y) tel que :

X = y

Y = Lplan - 1 - x

On note Lrot la largeur de BUFFERED_PLAN_270 obtenue avec la fonction « getWidth ». On note Hrot la hauteur de BUFFERED_PLAN_270 obtenue avec la fonction « getHight ». Le fichier image bitmap qui sert à la construction de l'objet informatique dynamique de visualisation est alors remplacée par le fichier image PNG généré à partir de BUFFERED_PLAN_270 et de la fonction « ImagelOUtil.writelmage » de la bibliothèque PDFBox. Cette modification est enregistrée dans la mémoire de stockage de MO au moment de la validation de la transaction TRANSI. La dimension Lrot est enregistrée dans la mémoire de stockage de MO au moment de la validation de la transaction TRANSI ; on la renomme alors Ldoc. La dimension Hrot est également enregistrée dans la mémoire de stockage de MO au moment de la validation de la transaction TRANSI ; on la renomme alors Hdoc. Ldoc et Hdoc constituent des données de caractérisation des fichiers de visualisation DOC_VISUALISATION du plan numérique NOM_PLAN.

Dans chacun des cas la valeur de couleur du pixel PpO (x ; y) est obtenue en utilisant la fonction getRGB (x ; y) appliquée à BUFFERED_PLAN_O. La valeur de couleur du pixel Pp90 (X ; Y) est définie en utilisant la fonction setRGB(X; Y) appliquée à BUFFERED_ PLAN_90. La valeur de couleur du pixel Ppl80 (X; Y) est définie en utilisant la fonction setRGB (X; Y) appliquée à BUFFERED_ PLAN_180. La valeur de couleur du pixel Pp270 (X ; Y) est définie en utilisant la fonction setRGB (X ; Y) appliquée à BUFFERED_ PLAN_270.

L'étape Bl, qui consiste à modifier la localisation dans le repère R* des données collaboratives de travail DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILM rattachées au plan numérique NOM_PLAN et enregistrées dans la mémoire de stockage du dispositif informatique depuis lequel le choix d'orientation est effectué au moment de l'ouverture de la transaction TRANSI, se déroule, dans le cadre de cette réalisation préférée, au niveau du serveur MO (Figure 2A : renvoi 22). On rappelle que chaque donnée collaborative de travail DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILM rattachée au plan numérique NOM_PLAN est identifiée par une valeur ORIENT_DONNEE qui caractérise son orientation propre dans le repère R*. On rappelle également que ces données collaboratives de travail sont ponctuellement repérées, dans R* par leurs coordonnées cartésiennes (xi ; yi), i variant de 1 à M. L'étape Bl consiste donc à réaliser les opérations suivantes, pour chacune des données DOC_TRAVAIL1,

27/48

DOC_TRAVAIL2,DOC_TRAVAILM rattachées au plan numérique NOM_PLAN et enregistrées dans la mémoire de stockage du serveur MO au moment de l'ouverture de la transaction TRANSI :

On calcule la valeur DELTA, qui est égale à la congruence, modulo 360, de la différence entre la valeur ORIENT et la valeur ORIENT_DONNEE de la donnée DOC_TRAVAIL considérée.

ORIENT— ORIENT_DONNEE = DELTA (modulo 360)

Dans le cadre de la présente description, et dans la mesure où nous nous sommes limités à 3 possibilités de rotations, DELTA ne peut prendre que 4 valeurs différentes qui sont : 0, 90, 180, ou 270.

Si DELTA = 0, on ne modifie pas les coordonnées (xi ; yi) associées, dans R*, à la donnée DOC_TRAVAIL considérée.

Si DELTA = 90, on modifie les coordonnées (xi ; yi) associées, dans R*, à la donnée DOC_TRAVAIL considérée, qui deviennent (Ai ; Bi) dans R* tels que :

Ai = Lrot - yi -1

Bi = xi

Si DELTA = 180, on modifie les coordonnées (xi ; yi) associées, dans R*, à la donnée DOC_TRAVAIL considérée, qui deviennent (Ai ; Bi) dans R* tels que :

Ai = Lrot - xi -1

Bi = Hrot-yi-l

Si DELTA = 270, on modifie les coordonnées (xi ; yi) associées, dans R*, à la donnée DOC_TRAVAIL considérée, qui deviennent (Ai ; Bi) dans R* tels que :

Ai = yi

Bi = Hrot-xi-l

On modifie la valeur ORIENT_DONNEE de la donnée de travail DOC_TRAVAIL considérée de manière à la rendre égale à la valeur ORIENT.

L'étape Cl de la transaction TRANSI consiste à actualiser la valeur ORIENT_MAITRE. Pour cela, on modifie la valeur ORIENT_MAITRE du plan numérique NOM_PLAN de manière à la rendre égale à la valeur ORIENT (Figure 2A : renvoi 22).

28/48

Dans le cadre de cette réalisation préférée, la transaction TRANSI constitue une mise à jour, en tenant compte de la valeur d'orientation sélectionnée par l'utilisateur ORIENT :

Des fichiers de visualisation DOC_VISUALISATION du plan numérique NOM_PLAN enregistrés dans la mémoire de stockage du serveur MO,

Des coordonnées de localisation dans le repère R* des données collaboratives de travail (DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILM) enregistrées dans la mémoire de stockage du serveur MO.

Suite à la validation de la transaction TRANSI (Figure 2B : renvoi 23) mettant en oeuvre les étapes Al, Bl et Cl énoncées ci-avant, donnant lieu à l'enregistrement dans la mémoire de stockage du serveur MO des données ainsi modifiées (Figure 2A : renvois 12a et 14a), le procédé objet de la présente invention se poursuit avec l'ouverture d'une seconde transaction appelée TRANS2 (Figure 2B : renvoi 24). Cette seconde transaction TRANS2 a pour but de mettre à jour les données qui peuvent avoir été transmises au dispositif informatique effectuant la première transaction TRANSI, c'est-à-dire ici le serveur MO, par les autres dispositifs informatiques du système (Figure 3 : renvoi 01), pendant la durée de traitement de celle-ci ; c'est-à-dire entre la date d'ouverture de la première transaction TRANSI et sa date de validation. Cette seconde transaction TRANS2 couvre donc, dans le cadre de cette réalisation préférée, les cas où de nouvelles données collaboratives de travail sont communiquées au serveur MO par les autres dispositifs informatiques partenaires Ml,..., Mn, pendant le traitement de la première transaction TRANSI. De la même façon, cette seconde transaction TRANS2 permet également de mettre en conformité avec la valeur ORIENT_MAITRE maintenant mise à jour et enregistrée dans la mémoire de stockage du serveur MO les données collaboratives de travail supplémentaires (DOC_TRAVAILZ+1) générées au niveau de ce dispositif informatique MO pendant la durée de la première transaction TRANSI. Dans l'hypothèse où aucune donnée collaborative de travail n'est communiquée au serveur MO pendant la durée de la première transaction TRANSI, cette seconde transaction TRANS2 est sans effet et n'a pas d'incidence sur les données enregistrées dans la mémoire de stockage de MO.

La validation de la première transaction TRANSI déclenche donc, au titre du procédé objet de la présente invention, et sur le même dispositif informatique MO, Ml, ..., Mn, l'ouverture immédiate d'une seconde transaction TRANS2 :

Ouverture de la seconde transaction TRANS2 (Figure 2B : renvoi 24)

Etape B2 : Modification, en tenant compte de la valeur ORIENT_MAITRE du plan numérique NOM_PLAN concerné par la première transaction TRANSI, des données collaboratives de travail DOC_TRAVAIL1, DOC_TRAVAIL2, DOC_TRAVAILQ rattachées au plan numérique NOM_PLAN et enregistrées dans la mémoire de stockage du dispositif informatique ayant effectué la première transaction TRANSI pendant la durée de traitement de celle-ci (dans le cadre de cette réalisation préférée, il s'agit des données collaboratives de travail concernant

29/48 le plan numérique NOM_PLAN, enregistrées dans la mémoire de stockage du serveur MO pendant la durée de la transaction TRANSI) (Figure 2B : renvoi 25) Validation de la seconde transaction TRANS2 (Figure 2B : renvoi 26) donnant lieu à l'enregistrement des données modifiées dans la mémoire de stockage du dispositif informatique depuis lequel ce second traitement a été fait, c'est-à-dire MO (Figure 2A : renvoi 14a). La date de modification de ces données est égale à la date de validation de cette seconde transaction TRANS2. Cette date est communiquée par l'horloge du serveur MO. Elle est enregistrée dans la mémoire de stockage du serveur MO en même temps que le sont les données modifiées de manière à pouvoir assurer la diffusion aux dispositifs informatiques partenaires Ml, ..., Mn, en mettant par exemple en oeuvre la méthode de synchronisation de MO avec chacun des dispositifs informatiques partenaires Ml,..., Mn, décrite ci-avant.

De la même façon que pour la première transaction TRANSI, nous garantissons la fiabilité du traitement souhaité en mettant en oeuvre, dans le cadre de cette réalisation préférée, une solution s'appuyant sur une transaction respectant les propriétés ACID. Nous utilisons les commandes « startTransaction » et « commit » pour définir le démarrage (appelé également ouverture) puis la validation de la transaction.

L'étape B2 de cette seconde transaction TRANS2 consiste à modifier les paramètres des données collaboratives de travail DOCTRAVAILl, DOC_TRAVAIL2, ..., DOC_TRAVAILQ impactés par le changement d'orientation (Figure 2B : renvoi 25). On rappelle que ces données collaboratives de travail, localisées sur le plan numérique, sont repérées, dans R*, par leurs coordonnées cartésiennes (xi ; yi), i variant de 1 à Q. L'étape B2 consiste donc à réaliser les opérations suivantes, pour chacune des données DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILQ rattachées au plan numérique NOM_PLAN et enregistrées dans la mémoire de stockage du serveur MO pendant la durée de traitement de la première transaction TRANSI :

On calcule la valeur DELTA, qui est égale à la congruence, modulo 360, de la différence entre la valeur ORIENT_MAITRE associée au plan numérique NOM_PLAN, enregistrée dans la mémoire de stockage du serveur MO réalisant la transaction TRANS2 et la valeur ORIENT_DONNEE de la donnée DOC_TRAVAIL considérée.

ORIENT_MAITRE-ORIENT_DONNEE ΞΞ DELTA (modulo 360)

Dans le cadre de la présente description, et dans la mesure où nous nous sommes limités à 3 possibilités de rotations, DELTA ne peut prendre que 4 valeurs différentes qui sont : 0, 90, 180, ou 270.

30/48

Si DELTA = 0, on ne modifie pas les coordonnées (xi ; yi) associées, dans R*, à la donnée DOC_TRAVAIL considérée.

Si DELTA = 90, on modifie les coordonnées (xi ; yi) associées, dans R*, à la donnée DOC_TRAVAIL considérée, qui deviennent (Ai ; Bi) dans R* tels que :

Ai = Ldoc - yi -1

Bi = xi

Si DELTA = 180, on modifie les coordonnées (xi ; yi) associées, dans R*, à la donnée DOC_TRAVAIL considérée, qui deviennent (Ai ; Bi) dans R* tels que :

Ai = Ldoc - xi -1

Bi = Hdoc-yi-l

Si DELTA = 270, on modifie les coordonnées (xi ; yi) associées, dans R*, à la donnée DOC_TRAVAIL considérée, qui deviennent (Ai ; Bi) dans R* tels que :

Ai = yi

Bi = Hdoc-xi-l

On modifie la valeur ORIENT_DONNEE de la donnée collaborative de travail DOC_TRAVAIL considérée de manière à la rendre égale à la valeur ORIENT_MAITRE associée au plan numérique NOM_PLAN.

Le lecteur pourra se référer à la Figure 4 qui schématise les données collaboratives ORIENT_MAITRE et DOC_VISUALISATION, ainsi que les données collaboratives de travail DOCTRAVAILl,..., DOC_TRAVAILM, leur localisation dans R* et leur valeur ORIENT_DONNEE associée, telles qu'elles peuvent être mémorisées au niveau du dispositif central MO avant que soit ouverte la première transaction TRANSI. En comparaison, la Figure 6 schématise ces mêmes données mises à jour en fonction d'une valeur d'orientation sélection ORIENT égale à 90 (quart de tour à droite), telles qu'elles peuvent être mémorisées au niveau du dispositif central MO après que soit validée la deuxième transaction TRANS2.

Une variante du procédé décrit dans cette réalisation préférée consisterait à ne pas traiter dans cette seconde transaction TRANS2 toutes les données collaboratives de travail DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILQ rattachées au plan numérique NOM_PLAN enregistrées dans la mémoire de stockage du serveur MO pendant la durée de traitement de la première transaction TRANSI, mais plutôt toutes les données DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILR rattachées au plan numérique NOM_PLAN enregistrées dans la mémoire de stockage du serveur MO associées à une valeur ORIENT_DONNEE différente de la valeur ORIENT_MAITRE. Cette variante est de nature à

31/48 réduire la durée de traitement de la seconde transaction TRANS2 ainsi que le niveau de consommation en ressources dans la mesure où seules les données nécessitant effectivement un traitement sont prises en compte.

Une autre variante du procédé décrit dans cette réalisation préférée consisterait à ne pas réaliser cette seconde transaction TRANS2 en négligeant, de fait, le cas de données collaboratives transmises au dispositif informatique réalisant la première transaction TRANSI par d'autres dispositifs informatiques du système (Figure 3 : renvoi 01) pendant la durée du traitement. Cette variante serait plus rapide que le procédé objet de la présente invention, mais serait également moins fiable. Il s'agirait en fait d'un mode dégradé de la présente invention. Il ne permettrait pas de couvrir de manière fiable et systématique le cas de données collaboratives de travail supplémentaires (DOC_TRAVAILZ+1) générées à partir du dispositif principal MO pendant la durée de la transaction TRANSI. Notons par ailleurs que dans les cas normaux d'utilisation du procédé objet de la présente invention, la seconde transaction TRANS2 s'effectue rapidement, et en tout cas plus rapidement que la première transaction TRANSI, ce qui relativise la contrainte qu'elle pourrait représenter.

Une autre variante du procédé décrit dans cette réalisation préférée pourrait consister à ne pas rendre obligatoire cette seconde transaction TRANS2, mais à la soumettre à un indicateur de contrôle enregistré dans la mémoire de stockage du dispositif informatique réalisant le traitement, c'est-à-dire, dans le cas présent, le serveur MO. Cet indicateur, pourrait par défaut être égal à zéro, ce qui permettrait de ne pas déclencher la seconde transaction TRANS2. L'indicateur prendrait une valeur positive dans l'hypothèse où un transfert de données collaboratives de travail serait effectué pendant la durée de la première transaction TRANSI, ce qui conduirait au déclenchement de la seconde transaction TRANS2. Cette variante serait en moyenne, au final, un peu plus rapide et moins consommatrice de ressources que le présent procédé, dont elle constituerait une légère optimisation.

Le procédé objet de la présente invention intègre des dispositions permettant de préserver la cohérence des données collaboratives y compris dans les cas où l'utilisateur souhaiterait commander une ou plusieurs autres rotations dans un laps de temps très court suivant la commande de la première. Dans le cadre de cette réalisation préférée, nous avons fait le choix d'intégrer des dispositions permettant d'interdire la commande d'une nouvelle rotation à un moment critique du traitement. On rappelle que l'utilisateur confirme son choix d'orientation en utilisant un bouton affiché sur l'écran de l'ordinateur connecté à MO, matérialisé par un conteneur « div » de couleur unie, contenant par exemple la mention lisiblement écrite « confirmer cette orientation ». Lorsque l'utilisateur commande une rotation, ce bouton devient provisoirement inaccessible. Nous avons fait le choix de le rendre de nouveau accessible après validation de la seconde transaction TRANS2. Pour cela, nous utilisons l'attribut « display » du conteneur « div » matérialisant le bouton de confirmation du choix, associé à un indicateur STATUT, enregistré dans la mémoire de stockage de MO, et pouvant prendre les valeurs 0 ou 1. Par défaut, l'indicateur STATUT vaut 1. L'évènement constituant la

32/48 confirmation du choix utilisateur, qui commande l'ouverture de la première transaction TRANSI, modifie la valeur de l'indicateur STATUT de 1 à 0 et l'enregistre dans la mémoire de stockage de MO (Figure 2A : renvoi 27). Lorsque la seconde transaction TRANS2 est validée, l'indicateur STATUT passe de 0 à 1, ce qui est de nouveau enregistré dans la mémoire de stockage de MO (Figure 2B renvoi 28). Tant que STATUT vaut 1, l'attribut « display » du bouton de confirmation prend la valeur « block ». Le bouton est visible et utilisable. Lorsque l'indicateur STATUT est égal à 0, l'attribut « display » du bouton de confirmation prend la valeur « none ». Le bouton n'est pas accessible et n'est pas utilisable, ce qui empêche provisoirement l'utilisateur de commander une autre rotation (Figure 2A : renvoi 29).

Un procédé légèrement variant de la présente invention consisterait à utiliser les propriétés ACID des transactions mises en oeuvre dans le but d'interrompre le déroulement du processus décrit tout en préservant la cohérence des données collaboratives. On pourrait permettre à l'utilisateur de déclencher une nouvelle rotation pendant le temps de traitement de la première transaction TRANSI en l'annulant avant l'enregistrement des modifications dans la mémoire de stockage de MO. La commande d'annulation « rollback » serait ainsi utilisée au moment où l'utilisateur confirmerait un autre choix d'orientation. Cette solution variante améliorait le niveau de service et la disponibilité de la fonction en permettant par exemple à l'utilisateur de revenir sur son choix pendant la durée de la première transaction TRANSI. Le fonctionnement de l'indicateur STATUT serait ainsi modifiable et pourrait ne basculer de 1 à 0 que pendant la durée de traitement de la seconde transaction TRANS2.

Le procédé objet de la présente invention intègre également des dispositions particulières au niveau du processus de mise à niveau des données collaboratives partagées entre les différents dispositifs informatiques du système (Figure 3 : renvoi 01) connectés à travers le réseau de communication RI, que nous avons appelé, dans le cas présent, « synchronisation de MO avec Mj », où Mj peut être n'importe laquelle des machines partenaires Ml,..., Mn du système (Figure 3 : renvoi 01). A chaque fois qu'une mise à niveau de données collaboratives est engagée entre deux dispositifs informatiques du système (Figure 3 : renvoi 01), les valeurs ORIENT_DONNEE des données collaboratives de travail DOC_TRAVAIL1, ... DOC_TRAVAILK rattachées au plan numérique NOM_PLAN et enregistrées dans la mémoire de stockage de l'un ou l'autre des dispositifs concernés sont comparées à la valeur ORIENT_MAITRE du plan numérique NOM_PLAN la plus à jour connue par l'un ou l'autre de ces dispositifs, alors appelée valeur ORIENT_MAITRE de référence ; c'est-à-dire la valeur ORIENT_MAITRE associée au plan numérique NOM_PLAN enregistrée dans la mémoire de stockage de l'un ou de l'autre des dispositifs informatiques concernés par la mise à niveau de données, et associée à la date la plus tardive. Chaque donnée collaborative de travail DOC_TRAVAIL1, ..., DOC_TRAVAILK rattachée au plan numérique NOM_PLAN ne possédant pas une valeur ORIENT_DONNEE égale à la valeur ORIENT_MAITRE de référence est traitée de manière à être mise en conformité. Les données collaboratives de travail en question ainsi que leurs coordonnées dans le repère R* sont ainsi modifiées et enregistrées, avec une date égale à la date TjO de

33/48 synchronisation concernée, dans les mémoires de stockage des deux dispositifs informatiques en relation. Dans le cadre de cette réalisation préférée, chaque dispositif informatique partenaires Ml,..., Mn ne peut établir de connexion à travers le réseau de communication RI qu'avec le serveur MO. Dans la mesure où la valeur ORIENT_MAITRE ne peut être modifiée qu'au niveau de ce serveur MO (Etape Cl de la première transaction TRANSI), c'est nécessairement le serveur MO qui possède, pour un plan numérique NOM_PLAN donné, la valeur ORIENT_MAITRE la plus à jour connue par le système (Figure 3 : renvoi 01); c'est-à-dire la valeur ORIENT_MAITRE de référence du plan numérique NOM_PLAN. On rappelle que les données collaboratives de travail DOC_TRAVAIL1,..., DOC_TRAVAILK sont repérées, dans R*, par leurs coordonnées cartésiennes (xi ; yi), i variant de 1 à K. Pour toute machine partenaire Mj appartenant à Ml,..., Mn, et au cours de toute synchronisation de MO avec Mj, la mise en conformité des données collaboratives de travail DOC_TRAVAIL1, ..., DOC_TRAVAILK et de leurs coordonnées de localisation dans le repère R*, rattachées au plan numérique NOM_PLAN et enregistrées dans la mémoire de stockage de MO ou de Mj, se déroule comme suit :

Si la synchronisation de MO avec Mj démarre pendant la durée de la seconde transaction TRANS2, ce processus de synchronisation est mis en attente le temps que soit validée cette seconde transaction TRANS2 (Figure 1 : renvoi 50). Dans le cadre de cette réalisation préférée, nous avons recours à un indicateur spécifique, relatif au plan numérique NOM_PLAN, permettant de connaître l'état de la seconde transaction TRANS2 (Figure 1 : renvoi 51). Par défaut, cet indicateur appelé ETAT2 vaut 1. Il est enregistré en tant que tel dans la mémoire de stockage du serveur MO. Lorsque la seconde transaction TRANS2 est ouverte, cet indicateur ETAT2 prend la valeur 0, et cette valeur modifiée est enregistrée dans la mémoire de stockage de MO (Figure 2B : renvoi 30). Lorsque la seconde transaction TRANS2 est validée, l'indicateur ETAT2 reprend la valeur 1, ce qui qui donne lieu à un nouvel enregistrement dans la mémoire de stockage de MO (Figure 2B : renvoi 31). On rappelle que Mj demande à MO de lui communiquer la date TjO caractérisant la synchronisation considérée dans une première requête nommée REQ1 (Figure 1 : renvoi 49). Au titre de cette réalisation préférée, la réponse de MO à Mj à cette requête REQ1 est différée tant que l'indicateur ETAT2 est égal à 0. On intercale une temporisation entre la requête REQ1 et sa réponse, dont la condition de levée est que l'indicateur ETAT2 valle 1. On rappelle que TjO correspond à la date qu'indique l'horloge du serveur MO au moment où celui-ci répond à la requête REQ1 de Mj (Figure 1 : renvoi 52). On remarquera que le serveur MO communique ainsi à Mj une date TjO légèrement supérieure, ou à minima égale, à la date de validation de la seconde transaction TRANS2.

Si la synchronisation de MO avec Mj démarre à un autre instant (indicateur ETAT2 égal à 1), la temporisation est nulle et la date TjO est transmise à Mj en réponse à la requête REQ1 sans délai.

34/48

En réponse à la requête REQ2, le serveur MO transmet à Mj toutes les données collaboratives modifiées ou nouvelles qui ont été enregistrées dans sa mémoire de stockage entre la date Tj-1 exclue et la date TjO incluse (Figure 1 : renvoi 56). Cela comprend notamment, lorsque qu'une rotation a été traitée dans l'intervalle, les données enregistrées dans la mémoire de stockage de MO du fait des deux transactions TRANSI et TRANS2 ; à savoir : les nouveaux fichiers de visualisation DOC_VISUALISATION du plan numérique NOM_PLAN, la nouvelle valeur ORIENT_MAITRE du plan numérique NOM_PLAN, et toutes les données collaboratives de travail DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILW relatives au plan numérique NOM_PLAN et leur coordonnées dans le repère R* ainsi que leur couple associé (ORIENT_DONNEE ; NOM_PLAN), issues des transactions TRANSI et TRANS2. On remarquera, que, de fait, à ce stade, toutes les données collaboratives de travail DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILW relatives au plan numérique NOM_PLAN enregistrées dans la mémoire de stockage de MO ont une valeur ORIENT_DONNEE égale à la valeur ORIENT_MAITRE de référence, et possèdent des coordonnées de localisation dans R* en cohérence avec les fichiers de visualisation DOC_VISUALISATION du plan numérique NOM_PLAN les plus à jour.

Au cours de la requête REQ3, Mj transmet à MO ses propres données collaboratives nouvelles ou modifiées (Figure 1 : renvoi 58), et en particulier les données collaboratives de travail DOCTRAVAILl, DOC_TRAVAIL2, ..., DOC_TRAVAILX du plan numérique NOM_PLAN qui ont été enregistrées ou modifiées dans sa mémoire de stockage entre la date Tj-1 exclue et la date TjO incluse, accompagnées de leurs coordonnées de localisation dans le repère R* et de leur couple associé (ORIENT_DONNEE ; NOM_PLAN). C'est parmi ces dernières que sont contenues les données collaboratives de travail qui ne sont pas cohérentes avec les fichiers de visualisation DOC_VISUALISATION les plus à jour, du plan numérique NOM_PLAN, et qui possèdent une valeur ORIENT_DONNEE différente de la valeur ORIENT_MAITRE de référence, transmise par le serveur MO. Dans le cadre de cette réalisation préférée, la mise en cohérence de ces données collaboratives de travail DOCTRAVAILl, DOC_TRAVAIL2, ..., DOC_TRAVAILX est réalisée au niveau du serveur MO que l'on sait disposer des ressources matérielles et logicielles nécessaires. Le serveur MO reçoit, dans le cadre de cette requête REQ3, les données collaboratives de travail DOC_TRAVAIL1, DOC_TRAVAIL2, DOC_TRAVAILX diffusées par Mj, accompagnées de leurs coordonnées de localisation dans le repère R* et de leur couple associé (ORIENT_DONNEE ; NOM_PLAN). Ces éléments sont provisoirement enregistrés dans la mémoire vive du serveur MO (Figure 1 : renvoi 59) et leur cohérence est analysée. Par mesure de sécurité, on réalise dans le cadre de cette réalisation préférée cette étape de mise en cohérence dans une nouvelle transaction TRANS3 (Figure 1 : renvoi 62), pour éviter d'éventuelles configurations instables (cas d'une défaillance du système au

35/48 cours du traitement, par exemple). Cette nouvelle transaction TRANS3 est ouverte dès l'instant où MO a reçu toutes les données collaboratives diffusées par Mj au titre de la requête REQ3 (Figure 1 : renvoi 60). Pour chacune des données collaboratives de travail DOCTRAVAILl, DOC_TRAVAIL2, ..., DOC_TRAVAILX du plan numérique NOM_PLAN ainsi reçue par MO, on compare la valeur ORIENT_DONNEE de cette donnée à la valeur ORIENT_MAITRE du plan numérique NOM_PLAN enregistrée dans la mémoire de stockage de MO :

o On calcule la valeur DELTA, qui est égale à la congruence, modulo 360, de la différence entre cette valeur ORIENT_MAITRE et la valeur ORIENT_DONNEE de la donnée DOC_TRAVAIL considérée.

ORIENT_MAITRE-ORIENT_DONNEE ΞΞ DELTA (modulo 360) o Dans le cadre de la présente description, et dans la mesure où nous nous sommes limités à 3 possibilités de rotations, DELTA ne peut prendre que 4 valeurs différentes qui sont : 0, 90, 180, ou 270.

o Si DELTA = 0, on ne modifie pas les coordonnées (xi ; yi) associées, dans R*, à la donnée DOC_TRAVAIL considérée.

o Si DELTA = 90, on modifie les coordonnées (xi ; yi) associées, dans R*, à la donnée DOC_TRAVAIL considérée, qui deviennent (Ai ; Bi) dans R* tels que :

Ai = Ldoc - yi -1

Bi = xi o Si DELTA = 180, on modifie les coordonnées (xi ; yi) associées, dans R*, à la donnée DOC_TRAVAIL considérée, qui deviennent (Ai ; Bi) dans R* tels que :

Ai = Ldoc - xi -1

Bi = Hdoc-yi-l o Si DELTA = 270, on modifie les coordonnées (xi ; yi) associées, dans R*, à la donnée DOC_TRAVAIL considérée, qui deviennent (Ai ; Bi) dans R* tels que :

Ai = yi

Bi = Hdoc-xi-l

36/48 o On modifie la valeur ORIENT_DONNEE de la donnée collaborative de travail DOC_TRAVAIL considérée de manière à la rendre égale à la valeur ORIENT MAITRE.

Une fois toutes les données collaboratives de travail DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILX du plan numérique NOM_PLAN reçues par le serveur MO dans le cadre de la requête REQ3 contrôlées et, si besoin, mise en cohérence avec la valeur ORIENT_MAITRE de référence, on valide la transaction TRANS3 (Figure 1 : renvoi 63), ce qui conduit à leur enregistrement dans la mémoire de stockage du dispositif informatique MO, puis dans celle du dispositif informatique Mj. Ces données collaboratives de travail, leurs coordonnées dans R* et leur couple associé (ORIENT_DONNE ; NOM_PLAN) sont tout d'abord enregistrés dans la mémoire de stockage du serveur MO avec la date TjO (Figure 1 : renvoi 65). Cet enregistrement déclenche la réponse de MO à la requête REQ3 de Mj. Dans le cadre de cette réponse, on renvoie également à Mj l'ensemble des données collaboratives de travail modifiées, leurs coordonnées dans R* et leur couple associé (ORIENT_DONNE ; NOM_PLAN) (Figure 1: renvoi 66). Pour des raisons de facilité, dans le cadre de cette réalisation préférée, on choisit de renvoyer à Mj l'ensemble des données collaboratives de travail DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILX qui viennent d'être enregistrées avec la date TjO dans la mémoire de stockage de MO, sans distinguer celles dont la valeur ORIENT_DONNEE a effectivement été modifiée de celles qui étaient préalablement cohérentes. Mj reçoit toutes ces données (Figure 1 : renvoi 67), puis les enregistre à son tour dans sa mémoire de stockage avec la date TjO (Figure 1 : renvoi 68). Dans le cadre d'une variante du procédé objet de l'invention, on pourrait ne renvoyer à Mj que les données collaboratives de travail accompagnées de leurs coordonnées de localisation dans R* et de leur couple associé (ORIENT_DONNEE ; NOM_PLAN) effectivement modifiées au niveau du serveur MO, ce qui conduirait à optimiser les délais de traitement et les niveaux de consommation en ressource. On pourrait pour cela par exemple marquer les données contrôlées au niveau du serveur MO à la suite de la requête REQ3, par un indicateur binaire différenciant les données collaboratives de travail effectivement modifiées de celles qui sont laissées telles quelles.

La transaction TRANS3 décrite ci-avant est de durée très courte puisqu'il s'agit simplement d'une opération de lecture-écriture en base de données. Le cas de figure selon lequel cette transaction démarrerait pendant la durée de traitement d'une transaction TRANSI et serait validée après ouverture de la transaction TRANS2 associée est improbable dans les configurations usuelles de mise en œuvre du présent procédé. En tenant compte, par exemple, d'un serveur MO bicoeur dont la fréquence CPU serait égale 2 x 2,4Ghz, consacré au présent procédé, et d'une semaine au cours de laquelle sont effectués, à des moments aléatoires :

37/48 ο 1 changement d'orientation du plan numérique, o La synchronisation de 100 données collaboratives différentes DOCTRAVAILl, DOCTRAVAIL2, ..., DOC_TRAVAIL100,

La probabilité selon laquelle la transaction TRANS3 démarrerait pendant la durée traitement d'une transaction TRANSI et serait validée après ouverture de la transaction TRANS2 associée est inférieure à 1 chance sur 100 millions. Si l'on veut tout de même pouvoir couvrir tous les cas de figure possibles, il est possible, dans le cas où c'est le serveur MO qui traite toutes les transactions TRANSI et toutes les transactions TRANS3 possibles, d'introduire un indicateur binaire spécifique ETAT3, comparable à l'indicateur ETAT2, qui bloque la validation de la transaction TRANSI tant qu'une transaction TRANS3 est en cours de traitement (Figure 2B : renvoi 32). Comme pour l'indicateur ETAT2, cet indicateur ETAT3 prend par défaut la valeur 1 et est enregistré en tant que tel dans la mémoire de stockage du serveur MO. Lorsqu'une transaction TRANS3 est ouverte, l'indicateur ETAT3 est modifié et est enregistré dans la mémoire de stockage de MO en prenant la valeur 0 (Figure 1 : renvoi 61). L'indicateur ETAT3 reprend la valeur 1 au moment de la validation de cette transaction TRANS3 (Figure 1 : renvoi 64). On introduit alors, dans le traitement de la transaction TRANSI, une temporisation dont la condition de levée et que l'indicateur ETAT3 valle 1 (Figure 2B : renvoi 33).

Juste après synchronisation de MO avec Mj, les deux dispositifs informatiques ont enregistré dans leur mémoire de stockage respective :

La valeur ORIENT_MAITRE, du plan numérique NOM_PLAN, mise à jour en tenant compte de l'orientation sélectionnée ORIENT par l'utilisateur.

Les fichiers de visualisation DOC_VISUALISATION du plan numérique NOM_PLAN mis à jour en tenant compte de l'orientation sélectionnée ORIENT par l'utilisateur. Des données collaboratives de travail DOC_TRAVAIL1, ... DOC_TRAVAILK, du plan numérique NOM_PLAN, partagées et dont les coordonnées de localisation dans le référentiel R* ont été mises à jour, en cohérence avec l'orientation sélectionnée ORIENT par l'utilisateur.

Pour atteindre un premier état de cohérence du système (Figure 3 : renvoi 01), où chaque dispositif informatique MO, Ml, M2,..., Mn a enregistré dans sa mémoire de stockage :

Les fichiers de visualisation DOC_VISUALISATION, du plan numérique NOM_PLAN, mis à jour en tenant compte de l'orientation sélectionnée ORIENT par l'utilisateur. Des données collaboratives de travail DOC_TRAVAIL1, ... DOC_TRAVAILKj, du plan numérique NOM_PLAN, partagées et dont les coordonnées de localisation dans le référentiel R* ont été mises à jour, en cohérence avec l'orientation sélectionnée ORIENT par l'utilisateur.

Il faut effectuer, dans le cadre de cette réalisation préférée, au moins une synchronisation de MO avec chacun des dispositifs informatiques partenaires (Ml, M2,..., Mn).

38/48

Pour atteindre un état de cohérence parfaite du système (Figure 3 : renvoi 01) où tous les dispositifs informatiques MO, Ml, M2, ..., Mn ont enregistré dans leur mémoire de stockage respective :

Les fichiers de visualisation DOC_VISUALISATION, du plan numérique NOM_PLAN, mis à jour en tenant compte de l'orientation sélectionnée ORIENT par l'utilisateur. Toutes les données collaboratives de travail DOC_TRAVAIL1, ... DOC_TRAVAILZ, du plan numériques NOM_PLAN, partagées et dont les coordonnées de localisation dans le référentiel R* ont été mises à jour, en cohérence avec l'orientation sélectionnée ORIENT par l'utilisateur.

Il faut effectuer, dans le cadre de cette réalisation préférée, au moins une synchronisation de MO avec chacun des dispositifs informatiques partenaires Ml, M2, ..., Mn et procéder à une synchronisations de MO avec chacun des dispositifs informatiques partenaires Ml, M2,..., Mn à chaque fois qu'une donnée collaborative de travail supplémentaire (DOC_TRAVAILZ+1) est enregistrée dans la mémoire de stockage de l'un des dispositifs informatiques (MO, Ml, M2, ..., Mn), en commençant, le cas échéant, par la synchronisation de MO avec le dispositif partenaire Mj dans la mémoire de stockage duquel cette donnée collaborative supplémentaire vient d'être enregistrée. Ces synchronisations ne doivent pas être simultanées et sont réalisées les unes après les autres, de manière à assurer un partage complet des données collaboratives entre les différents dispositifs informatiques (MO, Ml,..., Mn).

Le bouton permettant à l'utilisateur de sélectionner pour ce plan numérique NOM_PLAN une autre orientation a été rendu disponible au moment de la validation de la seconde transaction TRANS2. Le procédé objet de la présente invention est terminé et l'utilisateur peut, s'il le souhaite, définir une nouvelle orientation.

Une variante du procédé objet de la présente invention consisterait à ne pas utiliser des miniatures du plan numérique au moment de la sélection, par l'utilisateur, de l'orientation privilégiée, mais plutôt des extraits du plan numérique. Comparativement à la réalisation décrite, ces extraits de plan seraient d'une meilleure qualité que les miniatures utilisées (meilleure résolution, exprimée en dpi), mais auraient le défaut de proposer à l'utilisateur une vue plus réduite, et peut-être non identifiable, du plan numérique. Un premier extrait de plan, résultant d'un découpage rectangulaire de l'objet BUFFERED_PLAN_O, remplacerait alors l'objet BUFFERED_O. Il en résulterait une image PNG EXTRAIT_0_PLAN en lieu et place de l'image PNG MINI_0_PLAN. Sa valeur ORIENTMINI serait égale à 0. En réalisant un quart de tour à droite du découpage de l'objet BUFFERED_PLAN_O, on créerait ensuite l'image PNG EXTRAIT_90_PLAN, de valeur ORIENTMINI égale à 90, en lieu et place de l'image PNG MINI_90_PLAN. En réalisant un demi-tour du découpage de l'objet BUFFERED_PLAN_O, on créerait également l'image PNG EXTRAIT_180_PLAN, de valeur ORIENTMINI égale à 180, en

39/48 lieu et place de l'image PNG MINI_180_PLAN. En réalisant un quart de tour à gauche du découpage de l'objet BUFFERED_PLAN_O, on créerait enfin l'image PNG EXTRAIT_270_PLAN, de valeur ORIENTMINI égale à 270, en lieu et place de l'image PNG MINI_270_PLAN. Le découpage pourrait par exemple être effectué dans une zone située au centre du plan numérique, ou dans l'un de ses coins. De manière à ce que ces extraits de plans soient moins consommateurs de ressource que le plan numérique lui-même, comme le sont les miniatures du plan par rapport aux fichiers de visualisation DOC_VISUALISATION du plan numérique, il conviendrait de limiter les dimensions de la zone rectangulaire de découpage. On pourrait par exemple retenir une zone rectangulaire de découpage de l'objet BUFFERED_PLAN_O de hauteur H, en pixels, et de la largeur L, en pixels, où H est la plus petite des deux valeurs (250 ; Hplan/10) et L est la plus petite des deux valeurs (250 ; Lplan/10) arrondie à l'entier le plus proche. On rappelle ici que Hplan et Lplan sont les valeurs obtenues lorsque l'on applique respectivement les fonctions « getHight » et « getWidth » à l'objet BUFFERED_PLAN_O.

Une variante du procédé objet de la présente invention consisterait à n'afficher ni miniature ni extrait du plan numérique au moment de la sélection, par l'utilisateur, de la nouvelle orientation. On proposerait simplement à l'utilisateur trois boutons lui permettant de déclencher, au choix, un quart de tour à droite, un demi-tour, ou un quart de tour à gauche. Chacun de ces boutons pourrait par exemple être matérialisé par un conteneur « div » de couleur unie, contenant une mention lisiblement écrite adaptée, comme par exemple « quart de tour à droite » ou « demi-tour » ou « quart de tour à gauche ». L'évènement de clic sur l'un de ces trois boutons pourrait ainsi déclencher l'ouverture de la transaction TRANSI. On prendrait en compte une valeur ORIENT dépendant non plus de la miniature sélectionnée par l'utilisateur, mais du bouton sur lequel l'utilisateur aurait cliqué. Cette variante aurait l'avantage d'être plus rapide à mettre en œuvre que la solution préférée retenue puisqu'elle ne nécessiterait pas d'images miniatures, mais elle serait moins ergonomique pour l'utilisateur qui serait alors amené à devoir sélectionner une nouvelle orientation (ORIENT) à l'aveugle, sans pouvoir se faire une idée, à l'avance, de la vue orientée sous laquelle se serait présenté son plan à l'issue du traitement.

Dans le cadre d'une variante du procédé objet de la présente invention les fichiers de visualisation DOC_VISUALISATION ne sont pas mis à jour au niveau du serveur MO et ne font pas partie des documents échangés entre le serveur MO et les dispositifs partenaires Ml, ..., Mn. A la place, c'est la valeur de l'orientation sélectionnée ORIENT, qui est partagée entre les dispositifs informatiques, de telle sorte que chaque dispositif informatique partenaire réalise lui-même la mise à jour des fichiers de visualisation DOC_VISUALISATION. Cette solution permet de réduire la durée nécessaire des transmissions de données entre le serveur MO et chacun des dispositifs informatiques partenaires Ml, ..., Mn. En contrepartie, elle mobilise globalement plus de ressources de calcul, et nécessite que chacun des dispositifs informatiques partenaires Ml, ..., Mn dispose des ressources matérielles et logicielles nécessaires à la mise à jour des documents de visualisation. Dans le cadre d'une autre variante

40/48 du procédé objet de la présente invention, on génère au niveau du serveur MO tous les fichiers de visualisation DOC_VISUALISATION possibles, correspondant à toutes les vues orientées du plan numérique NOM_PLAN envisageables et admises par la mise en oeuvre du procédé retenue. Ces fichiers de visualisation sont différenciés par la valeur ORIENT_MAITRE qui caractérise l'orientation dans le repère R* de la vue orientée du plan numérique qu'ils encodent. Tous ces fichiers de visualisation, ainsi que leur valeur d'orientation maître ORIENT_MAITRE, sont enregistrés dans la mémoire de stockage de chacun des dispositifs informatiques MO, Ml, M2,..., Mn, avant que les premières données collaboratives de travail DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILZ soient générées. Par la suite, et comme dans le cas précédent, les documents de visualisation DOC_VISUALISATION du plan numérique NOM_PLAN ne sont plus échangés entre le dispositif informatique principal MO et les dispositifs informatiques partenaires Ml,..., Mn, mais l'on échange, à la place, la valeur de l'orientation sélectionnée ORIENT. Cette valeur ORIENT est alors enregistrée dans la mémoire de stockage de chacun des dispositifs informatiques MO, Ml, ..., Mn et permet d'identifier, par comparaison avec les valeurs d'orientation maître ORIENT MAITRE possibles, les fichiers de visualisation DOC_VISUALISATION à mobiliser pour aboutir à l'affichage de la vue orientée dans le repère R* attendue par l'utilisateur. Au titre de cette variante, les fichiers de visualisation DOC_VISUALISATION codant les vues orientées possibles sont échangés au cours d'une communication dissociée de la suite du procédé, ce qui permet éventuellement de mobiliser un réseau de communication RI2 différent du réseau de communication informatique RI. Par exemple, l'utilisateur pourrait enregistrer ces fichiers de visualisation DOC_VISUALISATION et leur valeur d'orientation maître ORIENT_MAITRE associée sur une clé USB, puis transporter physiquement cette clé USB au contact de chacun des dispositifs informatiques partenaires Ml, ..., Mn et copier ces données manuellement dans leurs mémoires de stockage respectives. Cette variante peut être mise en œuvre dans les cas de figure où le nombre de vues orientées possibles est préalablement connu et fini. Comme pour la variante précédente, elle a l'avantage de réduire la durée nécessaire des transmissions de données entre le dispositif informatique principal MO et les dispositifs informatiques partenaires Ml,..., Mn une fois tous les fichiers de visualisation DOC_VISUALISATION possibles enregistrés dans les mémoires de stockages des machines MO, Ml,..., Mn.

Dans le cadre d'une autre variante du procédé objet de la présente invention, on associe à chaque donnée collaborative de travail DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILZ, au moment où elle est générée, un ensemble de coordonnées qui la repère, dans le référentiel R*, selon toutes les vues orientées possibles du plan numérique NOM_PLAN admises par la mise en œuvre du procédé retenue. Par exemple, et dans le cas où l'on ne retient que les rotations usuelles (quart de tour à droite, quart de tour à gauche, demi-tour) décrites dans le cadre de la réalisation préférée du procédé énoncée ci-avant, chaque donnée collaborative de travail est associée à 4 jeux de coordonnées qui correspondent à toutes les localisations possibles, dans le repère R*, admises par le système (Figure 3 : renvoi 01). Chaque jeu de coordonnées est alors lui-même associé à la valeur d'orientation maître ORIENT_MAITRE

41/48 correspondant à la vue orientée du plan numérique avec laquelle il est en cohérence. Dans le cas de données collaboratives de travail localisées sur un plan en deux dimensions, et dans un système (Figure 3 : renvoi 01) n'admettant que les 4 rotations listées ci-dessus, chaque donnée collaborative de travail DOC_TRAVAILi est donc caractérisée par un tableau TABi à 4 lignes et 3 colonnes où sont rangées, en ligne, les données relatives à une vue orientée possible, et en colonne, les positions possibles de cette donnée collaboratives de travail sur l'axe des abscisses du repère R*, les positions possibles de cette donnée collaborative de travail sur l'axe des ordonnées du repère R*, et une valeur comparable à ORIENT_MAITRE, caractérisant l'orientation dans le repère R*, de chaque vue orientée possible. Ce tableau TABi accompagne la donnée collaborative de travail DOC_TRAVAILi à chaque fois qu'elle est échangée et enregistrée dans la mémoire de stockage d'un des dispositifs informatiques MO, Ml, ..., Mn. Dès lors, il n'est plus nécessaire de procéder au calcul des coordonnées de localisation de R*, au niveau du serveur MO, de chacune des données collaboratives de travail DOC_TRAVAIL1, ..., DOC_TRAVAILZ à chaque fois que la valeur d'orientation sélectionnée ORIENT varie. A la place, cette valeur d'orientation privilégiée ORIENT est échangée entre le dispositif informatique principal MO et chacun des dispositifs informatiques partenaires, et enregistrée dans la mémoire de stockage de chacune des machines MO, Ml,..., Mn du système (Figure 3 : renvoi 01). On met en cohérence les coordonnées de localisation de chaque donnée collaborative de travail DOC_TRAVAILi en utilisant la ligne du tableau TABi en corrélation avec la vue orientée du plan numérique affichée, à cet instant, sur le dispositif informatique MO, Ml, ..., Mn considéré. Cette variante mobilise globalement plus de puissance de calcul au niveau des dispositifs informatiques partenaires Ml, ..., Mn mais permet réduire la durée nécessaire des transmissions de données entre le serveur MO et chacun des dispositifs informatiques partenaires Ml,..., Mn. Cette variante peut être mise en oeuvre dans les cas de figure où le nombre de vues orientées possibles est préalablement connu et fini.

Dans le cadre d'une autre variante du procédé objet de la présente invention, aucun des dispositifs informatiques (MO, Ml, ..., Mn) ne dispose d'horloge. On associe, à la place, à chaque donnée collaborative une donnée de caractérisation appelée « indice » qui a pour valeur zéro au moment de sa création, et qui est incrémentée de un à chaque fois que la donnée en question est enregistrée dans une mémoire de stockage après avoir subi une modification ou une mise à jour au cours d'une transaction TRANSI, TRANS2 ou TRANS3. Dans ce cas de figure, les dispositifs informatiques (MO, Ml, ..., Mn) affichent les vues orientées codées par les fichiers de visualisation DOC_VISUALISATION enregistrés dans leur mémoire de stockage et possédant la valeur « indice » la plus élevée. A tout instant, et pour toute donnée collaborative considérée, la version la plus à jour de cette donnée correspond à celle qui est caractérisée par la valeur indice la plus élevée. On modifie par ailleurs l'étape de synchronisation de MO avec Mj de telle sorte que :

La requête REQ1 est supprimée.

Au cours de la requête REQ2, le dispositif MO envoie au dispositif Mj toutes les données collaboratives enregistrées dans sa mémoire de stockage, dans la version

42/48 la plus à jour qu'il connaît ; c'est-à-dire celle qui est associée à la valeur indice la plus élevée dans sa mémoire de stockage. Mj les réceptionne et se prépare à enregistrer dans sa mémoire de stockage celles qu'il ne connaît pas et celles qu'il connaît dans une version antérieure.

Au cours de la requête REQ3, le dispositif Mj envoie au dispositif MO toutes les données collaboratives de travail enregistrées dans sa mémoire de stockage, dans la version la plus à jour qu'il connaît. MO les réceptionne puis isole celles qu'il ne connaît pas. On ouvre la transaction TRANS3 en mobilisant ce lot de données collaboratives de travail isolées. Ces données sont mises à jour dans le cadre de la transaction TRANS3 et leur indice est incrémenté d'une unité. En réponse à la requête REQ3, MO envoie à Mj ces données collaboratives de travail mises à jour.

Cette variante du procédé objet de la présente invention a le défaut d'augmenter la durée des synchronisations puisque le volume de données échangé au cours de chaque connexion entre un dispositif informatique partenaire (Ml, M2, ..., Mn) et le dispositif informatique central (MO) est considérablement accru. Cette variante a toutefois l'avantage de mettre en oeuvre un système ne mobilisant aucune horloge.

43/48

Claims (17)

1. Revendications

   1. Procédé de rotation et de partage cohérent de vues orientées d'un plan numérique (PLAN) comportant des données localisées dites « collaboratives de travail » (DOCTRAVAILl, DOC_TRAVAIL2, DOC_TRAVAILZ) repérées dans un référentiel (R*), par des dispositifs informatiques dits « partenaires » (Ml, M2,..., Mn) où chacun desdits dispositifs partenaires (Mj) communique au moyen de connexions ponctuelles (TjO, Tj-1, ..., Tj-kj) avec un dispositif informatique dit « principal » (MO), et caractérisé en ce que :

   on mémorise une valeur dite « d'orientation sélectionnée » (ORIENT) caractérisant l'orientation dans le référentiel (R*) d'une vue orientée du plan numérique (PLAN) privilégiée, chaque dispositif informatique partenaire (Ml, M2, ..., Mn) mémorise des fichiers dits « de visualisation » (DOC_VISUALISATION) destinés à l'affichage de vues orientées du plan numérique (PLAN), mis à jour en tenant compte de la valeur d'orientation sélectionnée (ORIENT), on met à jour les coordonnées de localisation de toutes les données collaboratives de travail (DOCTRAVAILl, DOC_TRAVAIL2,..., DOC_TRAVAILZ) dans le référentiel (R*) en tenant compte de la valeur d'orientation sélectionnée (ORIENT), chaque dispositif informatique partenaire (Ml, M2, ..., Mn) mémorise toutes les données collaboratives de travail (DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILZ) et leurs coordonnées de localisation dans le référentiel (R*).
2. 2. Procédé selon la revendication 1 et selon lequel on intègre aux données collaboratives de travail (DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILZ) couvertes par le procédé chaque donnée collaborative de travail supplémentaire (DOC_TRAVAILZ+1) mémorisée par l'un des dispositifs informatiques (MO, Ml, M2,..., Mn) au cours du déroulement du procédé.
3. 3. Procédé selon l'une des revendications précédentes et selon lequel on transmet au dispositif informatique principal (MO) au cours d'au moins une de ses connexions ponctuelles (TjO, Tj-1,..., Tj-kj) avec l'un des dispositifs informatiques partenaires (Mj) toutes les données collaboratives de travail dites « modifiées ou nouvelles» (DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILXj) que ce dispositif informatique partenaire (Mj) a mémorisé pendant l'intervalle de temps séparant le début de cette connexion ponctuelle (Tjœ2) et la fin d'une connexion ponctuelle précédente (Tjtol) entre le dispositif informatique principal (MO) et ce dispositif informatique partenaire (Mj).

   44/48
4. 4. Procédé selon l'une des revendications précédentes et selon lequel on transmet à l'un des dispositifs informatiques partenaires (Mj) au cours d'au moins une de ses connexions ponctuelles (TjO, Tj-1, Tj-kj) avec le dispositif informatique principal (MO) toutes les données collaboratives de travail dites « modifiées ou nouvelles» (DOC_TRAVAIL1, DOC_TRAVAIL2, DOC_TRAVAILX0) que le dispositif informatique principal (MO) a mémorisé pendant l'intervalle de temps séparant le début de cette connexion ponctuelle (Tjœ2) et la fin d'une connexion ponctuelle précédente (Tjojl) entre le dispositif informatique principal (MO) et ce dispositif informatique partenaire (Mj).
5. 5. Procédé selon l'une des revendications précédentes et selon lequel la vue orientée du plan numérique (PLAN) privilégiée est définie par un utilisateur.
6. 6. Procédé selon l'une des revendications précédentes selon lequel on associe à au moins une vue orientée du plan numérique (PLAN) mémorisée par au moins un des dispositifs informatiques (MO, Ml, M2,..., Mn) une valeur dite « d'orientation maître » (ORIENT_MAITRE) caractérisant l'orientation de cette vue dans le référentiel (R*).
7. 7. Procédé selon l'une des revendications précédentes et selon lequel on associe à au moins une des données collaboratives de travail (DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILZ), localisée sur une vue orientée du plan numérique (PLAN) une valeur dite « d'orientation de donnée » (ORIENT_DONNEE) caractérisant l'orientation de cette vue dans le référentiel (R*)·
8. 8. Procédé selon la revendication 7 et/ou la revendication 6 et selon lequel on compare au moins une valeur d'orientation de donnée (ORIENT_DONNE) à la valeur d'orientation sélectionnée (ORIENT) ou à une valeur d'orientation maître (ORIENT_MAITRE) pour mettre à jour les coordonnées de localisation dans le référentiel (R*) d'au moins une des données collaboratives de travail (DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILZ).
9. 9. Procédé selon l'une des revendications précédentes et selon lequel on effectue la mise à jour des coordonnées de localisation dans le référentiel (R*) d'au moins une des données collaboratives de travail (DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILZ) dans une transaction informatique dite « première » (TRANSI).
10. 10. Procédé selon la revendication 9 et selon lequel on effectue la mise à jour des coordonnées de localisation dans le référentiel (R*) d'au moins une des données

    45/48 collaboratives de travail (DOC_TRAVAIL1, DOC_TRAVAIL2, DOC_TRAVAILZ) dans une transaction informatique dite « seconde » (TRANS2) ouverte après validation de la première transaction informatique (TRANSI).
11. 11. Procédé selon la revendication 5 et selon lequel l'utilisateur définit la vue orientée du plan numérique (PLAN) privilégiée en sélectionnant une représentation visuelle miniaturisée de cette vue orientée du plan numérique (MINI_ORIENT_PLAN) parmi d'autres représentations de vues orientées du plan numérique.
12. 12. Procédé selon les revendications 5 ou 11 et selon lequel l'utilisateur définit la vue orientée du plan numérique (PLAN) privilégiée en choisissant une représentation visuelle d'un extrait de cette vue orientée du plan numérique (EXTRAIT_ORIENT_PLAN) parmi d'autres représentations de vues orientées du plan numérique.
13. 13. Procédé selon l'une des revendications précédentes et selon lequel on ne mobilise que la puissance de calcul du dispositif informatique principal (MO) pour déterminer les coordonnées de localisation mises à jour dans le référentiel (R*) des données collaboratives de travail (DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILZ).
14. 14. Procédé selon l'une des revendications précédentes et selon lequel on échange entre le dispositif principal (MO) et au moins l'un des dispositifs informatiques partenaires (Ml, M2,..., Mn) des fichiers de visualisations (DOC_VISUALISATION).
15. 15. Procédé selon l'une des revendications précédentes et selon lequel au moins un des dispositifs informatiques (MO, Ml, M2,..., Mn) produit un objet informatique dynamique, de type HTML ou comparable à un document HTML, contenant des balises de type image.
16. 16. Système de rotation et de partage cohérent de vues orientées d'un plan numérique (PLAN) comportant des données localisées dites « collaboratives de travail » (DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILZ) repérées dans un référentiel (R*), comprenant des dispositifs informatiques dits « partenaires » (Ml, M2, ..., Mn), où chacun desdits dispositifs partenaires (Mj) communique au moyen de connexions ponctuelles (TjO, Tj-1, ..., Tj-kj) à travers un réseau informatique (RI) avec un dispositif informatique dit « principal » formant serveur (MO), chaque dispositif informatique (MO, Ml, M2, ..., Mn) disposant ou étant relié à un module de communication avec ledit réseau informatique (RI),

    46/48 disposant ou étant relié à un moyen de commande permettant de recueillir des informations ou des ordres émis par l'utilisateur (COMMANDE), disposant d'une mémoire informatique pour mémoriser des fichiers dits « de visualisation » (DOC_VISUALISATION) destinés à l'affichage de vues orientées du plan numérique (PLAN), lesdites données collaboratives de travail (DOC_TRAVAIL1, DOC_TRAVAIL1, DOC_TRAVAIL2,..., DOC_TRAVAILZ) et leurs coordonnées dans le référentiel (R*), ainsi qu'une valeur dite « d'orientation sélectionnée » (ORIENT) caractérisant l'orientation dans le référentiel (R*) d'une vue orientée du plan numérique (PLAN) privilégiée, disposant ou étant relié à un dispositif d'affichage comprenant une zone d'affichage (DISPLAY), et disposant d'une unité de traitement capable de générer et d'afficher sur son dispositif d'affichage, des objets informatiques dynamiques ou des fichiers informatiques en utilisant ou en transformant tout ou partie desdits fichiers de visualisation (DOC_VISUALISATION), au moins un des dispositifs informatiques (MO, Ml,..., Mn) étant configuré pour : la mémorisation de la valeur d'orientation sélectionnée (ORIENT), la mise à jour de fichiers de visualisation (DOC_VISUALISATION) destinés à l'affichage de vues orientées du plan numérique (PLAN) en tenant compte de la valeur d'orientation sélectionnée (ORIENT), la mise à jour des coordonnées de localisation des données collaboratives de travail (DOCTRAVAILl, DOCTRAVAILl, DOC_TRAVAIL2, ..., DOC_TRAVAILZ) dans le référentiel (R*) en tenant compte de la valeur d'orientation sélectionnée (ORIENT), chaque dispositif informatique partenaire (Ml,..., Mn) étant configuré pour : la diffusion de données collaboratives (DOC_TRAVAIL1, DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILZj) réceptionnées par le dispositif informatique principal (MO), la réception de données collaboratives (DOC_TRAVAIL1, DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILZ0) diffusées par le dispositif informatique principal (MO), la mémorisation de toutes les données collaboratives de travail (DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILZ) et leurs coordonnées dans le référentiel (R*), la mémorisation de fichiers de visualisation (DOC_VISUALISATION), le dispositif informatique principal (MO) étant configuré pour :

    la diffusion de données collaboratives (DOC_TRAVAIL1, DOC_TRAVAIL1, DOC_TRAVAIL2, ..., DOC_TRAVAILZ0) réceptionnées par les dispositifs informatiques partenaires (Ml, M2,..., Mn),

    47/48 la réception de données collaboratives (DOC_TRAVAIL1, DOC_TRAVAIL1, DOC_TRAVAIL2, DOC_TRAVAILZj) diffusées par les dispositifs informatiques partenaires (Ml, M2,..., Mn).
17. 17. Système selon la revendication 16 apte à mettre en œuvre un procédé selon l'une quelconque des revendications 2 à 15

    1/7

    Début connexion ponctuelle de MO avec Mj

    N/ 'ETAT2T . li 0, <Côté MO

    Côté Mj_z

    4^Attente fin Transaction TRANS2

    REQ.1 : Demande date TjO

    Détermination et diffusion date TjO

    N/

    Stockage des données en mémoire vive

    Transaction TRANS3

    Stockage TjO en mémoire vive „ 58

    REQ3 : envoi des données collaboratives nouvelles et modifiées de Mj

    DOC_TRAVAILj (xj ; yj) dans R* ORIENT_DONNEE = ?

    Tj-1 < date < TjO

    2/7

    Enregistrement de DOC_SOURCE et de NOM_PLAN

    Vers 15

    Depuis 23-

    Mémorisation ; boc_visuÂLisÂfiÔN! LOR'EKÇMAiTRE _ _ j f date

    ProductioiÎpar l'utilisateur de données collaboratives de travail localisées dans R*

    DOC_TRAVAILi (xi ; yi) dans R* ORIENT_DONNEE = ORIENT MAITRE date

    N

    14a

    Mémorisation

    DOC_TRAVAILi (xi ; yi) dans R* ORIENT_DONNEE = ORIENT_MAITRE

    Depuis 23 Depuis 26

    Génération des fichiers de visualisation DOC VISUALISATION avec ORIENT MAITRE = (al)

    Mémorisation b’ÔcJviSÙÂÙSÂTIÔN’!

    date

    Synchronisation de MO avec Mj al/a2/b (a2)

    Mémorisation

    Mb) (b)l

    Modification des données collaboratives de travail diffusées par Mj, en tenant compte de la valeur ORIENT_MAITRE la plus à jour

    DOC_TRAVAILi et (xi ; yi) dans R* ORIENT DONNEE = ORIENT MAITRE

    DOC_TRAVAILi (xi ; yi) dans R* ORIENT_DONNEE = ORIENT MAITRE (b)

    Production par l'utilisateur de données collaboratives de travail localisées dans R*

    DOC_TRAVAILi (xi ; yi) dans R* ORIENT_DONNEE = ORIENT_MAITRE date date

    14b hJ

    3/7

    4/7