FR 3103916 A1 20210604 FR 1913441 A 20191129 Un procédé de contrôle d’accès à des données dans un serveur d’intermédiation inclut : le stockage d’un enregistrement contenant : un identifiant d’enregistrement ; une pluralité de sections chacune contenant des données ; et en association à chaque section, un identifiant de propriétaire à partir d’un ensemble d’identifiants de demandeur correspondant à des sous-systèmes demandeurs respectifs ; le stockage des données de contrôle d’accès correspondant à chaque identifiant de demandeur ; dans lequel les données de contrôle d’accès pour un identifiant de demandeur donné indiquent quels autres identifiants de demandeur sont habilités à accéder à une section de l’enregistrement ayant l’identifiant de demandeur donné qui lui est associé comme identifiant de propriétaire ; en réponse à la réception, de l’un des sous-systèmes demandeurs, une requête contenant l’identifiant d’enregistrement et un identifiant actif des identifiants de demandeur correspondant au sous-système demandeur actif : l’octroi d’un accès à un sous-ensemble des sections en fonction de l’identifiant du demandeur actif, des identifiants de propriétaire et des données de contrôle d’accès. Système et procédé de contrôle d’accès différentiel de données partagées La spécification concerne de façon générale le stockage de données et spécifiquement un système et un procédé de contrôle d’accès différentiel de données partagées. Contexte L’exécution de tâches diverses telles que la fourniture d’articles (p. ex. des produits et des services liés au voyage) des fournisseurs aux consommateurs peut impliquer une interaction entre un nombre de sous-systèmes informatiques distincts gérés par différentes entités. Pour permettre au système dans sa globalité d’exécuter la tâche pertinente avec succès, certains des sous-systèmes informatiques susmentionnés peuvent utiliser des ensembles communs de données. De plus, certains sous-systèmes informatiques peuvent cependant utiliser des données qui sont spécifiques et/ou exclusives à ces sous-systèmes, en plus des ensembles communs de données. Le maintien d’une séparation entre les données communes et exclusives ou autrement les données à accès limité peut introduire des erreurs et/ou une complexité computationnelle plus importante dans le stockage et la synchronisation des ensembles communs de données. Résumé Un aspect de la spécification fournit un procédé de contrôle d’accès à des données, comprenant : le stockage à un serveur d’intermédiation d’un enregistrement contenant : (i) un identifiant d’enregistrement principal ; (ii) une pluralité de sections chacune contenant des données ; et (iii) en association à chaque section, un identifiant de propriétaire sélectionné parmi un ensemble d’identifiants de demandeur correspondant à des sous-systèmes demandeurs respectif ; le stockage, au serveur d’intermédiation, des données de contrôle d’accès correspondant à chaque identifiant de demandeur ; dans lequel les données de contrôle d’accès pour un identifiant de demandeur donné indiquent quels autres identifiants de demandeur sont habilités à accéder à une section de l’enregistrement ayant l’identifiant de demandeur donné qui lui est associé comme identifiant de propriétaire ; en réponse à la réception, au serveur d’intermédiation d’un sous-système actif des sous-systèmes demandeurs, d’une requête contenant (i) l’identifiant d’enregistrement principal et (ii) un identifiant actif des identifiants de demandeur correspondant au sous-système demandeur actif : l’octroi d’un accès à un sous-ensemble des sections en fonction de l’identifiant du demandeur actif, des identifiants de propriétaire et des données de contrôle d’accès. L’octroi d’un accès à un sous-ensemble des sections peut inclure de récupérer le sous-ensemble des sections dans l’enregistrement et de transmettre le sous-ensemble des sections au sous-système demandeur actif. Le procédé peut par ailleurs inclure, le stockage, au serveur d’intermédiation, de données de configuration de présentation. La transmission du sous-ensemble des sections peut inclure d’arranger le sous-ensemble des sections en fonction des données de configuration de présentation pour affichage au sous-système demandeur. Le procédé peut par ailleurs inclure : la réception, au serveur d’intermédiation en provenance de l’un des sous-systèmes demandeurs, de données de configuration de présentation actualisées correspondant à l’un des sous-systèmes demandeurs ; et la mise à jour des données de configuration de présentation. Les données de contrôle d’accès peuvent être stockées dans un répertoire de configuration distinct de l’enregistrement. Les données de contrôle d’accès incluent des données de contrôle d’accès par défaut stockées dans le répertoire de configuration. Les données de contrôle d’accès peuvent inclure par ailleurs des données du dérogation de contrôle d'accès stockées dans l’enregistrement. Le procédé peut par ailleurs inclure : la réception, au serveur d’intermédiation en provenance de l’un des sous-systèmes demandeurs, de données de contrôle d’accès actualisées correspondant à l’un des sous-systèmes demandeurs ; et la mise à jour des données de contrôle d’accès. Chacune des sections peut inclure un ou plusieurs champs de donnée distincts. Au moins une des sections peut être cryptée. Le procédé peut par ailleurs inclure : la réception, au serveur d’intermédiation, d’une requête pour remplacer un identifiant initial de propriétaire d’une section par un nouvel identifiant de propriétaire ; et le remplacement de l’identifiant initial de propriétaire par le nouvel identifiant de propriétaire. Un autre aspect de la spécification fournit un serveur d’intermédiation pour le contrôle d’accès à des données, le serveur d’intermédiation comprenant : une interface de communication ; une mémoire configurée pour stocker : un enregistrement contenant (i) un identifiant d’enregistrement principal ; (ii) une pluralité de sections chacune contenant des données ; et (iii) en association à chaque section, un identifiant de propriétaire sélectionné parmi un ensemble d’identifiants de demandeur correspondant à des sous-systèmes demandeurs respectifs ; et les données de contrôle d’accès correspondant à chaque identifiant de demandeur ; dans lequel les données de contrôle d’accès pour un identifiant de demandeur donné indiquent quels autres identifiants de demandeur sont habilités à accéder à une section de l’enregistrement ayant l’identifiant de demandeur donné qui lui est associé comme identifiant de propriétaire ; un processeur interconnecté à la mémoire et à l’interface de communication, le processeur étant configuré pour : en réponse à la réception d’un sous-système actif des sous-systèmes demandeurs, d’une requête contenant (i) l’identifiant d’enregistrement principal et (ii) un identifiant actif des identifiants de demandeur correspondant au sous-système demandeur actif: octroyer un accès à un sous-ensemble des sections en fonction de l’identifiant du demandeur actif, des identifiants de propriétaire et des données de contrôle d’accès. Le processeur peut être configuré, afin d’octroyer un accès à un sous-ensemble des sections, pour : récupérer le sous-ensemble des sections à partir de l’enregistrement et transmettre le sous-ensemble des sections au sous-système demandeur actif. La mémoire peut par ailleurs être configurée pour stocker des données de configuration de présentation ; et le processeur peut par ailleurs être configuré, afin de transmettre le sous-ensemble des sections, pour arranger le sous-ensemble des sections en fonction des données de configuration de présentation pour affichage au sous-système demandeur. Le processeur peut par ailleurs être configuré pour : recevoir de l’un des sous-systèmes demandeurs, des données de configuration de présentation actualisées correspondant à l’un des sous-systèmes demandeurs ; et mettre à jour les données de configuration de présentation dans la mémoire. Les données de contrôle d’accès peuvent être stockées dans un répertoire de configuration distinct de l’enregistrement. Les données de contrôle d’accès incluent des données de contrôle d’accès par défaut stockées dans le répertoire de configuration. Les données de contrôle d’accès peuvent par ailleurs inclure des donnèes du dèrogation de contrôle d'accès stockées dans l’enregistrement. Le processeur peut par ailleurs être configuré pour : recevoir, de l’un des sous-systèmes demandeurs, des données de contrôle d’accès actualisées correspondant à l’un des sous-systèmes demandeurs ; et la mise à jour des données de contrôle d’accès dans la mémoire. Chacune des sections peut inclure un ou plusieurs champs de donnée distincts. Au moins une des sections peut être cryptée. Le processeur peut par ailleurs être configuré pour : recevoir une requête pour remplacer un identifiant initial de propriétaire d’une section par un nouvel identifiant de propriétaire ; et remplacer l’identifiant initial de propriétaire par le nouvel identifiant de propriétaire. Un autre aspect de la spécification fournit un produit programme d’ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur comprenant des moyens de programme lisibles par ordinateur pour stocker, au serveur d’intermédiation, un enregistrement contenant : (i) un identifiant d’enregistrement principal ; (ii) une pluralité de sections chacune contenant des données ; et (iii) en association à chaque section, un identifiant de propriétaire sélectionné parmi un ensemble d’identifiants de demandeur correspondants à des sous-systèmes demandeurs respectifs ; et comprenant des moyens de programme lisibles par ordinateur pour stocker, au serveur d’intermédiation, des données de contrôle d’accès correspondant à chaque identifiant de demandeur ; dans lequel les données de contrôle d’accès pour un identifiant de demandeur donné indiquent quels autres identifiants de demandeur sont habilités à accéder à une section de l’enregistrement ayant l’identifiant de demandeur donné qui lui est associé comme identifiant de propriétaire ; en réponse à la réception, au serveur d’intermédiation d’un sous-système actif des sous-systèmes demandeurs, d’une requête contenant (i) l’identifiant d’enregistrement principal et (ii) un identifiant actif des identifiants de demandeur correspondant au sous-système demandeur actif : et l’octroi d’un accès à un sous-ensemble des sections en fonction de l’identifiant du demandeur actif, des identifiants de propriétaire et des données de contrôle d’accès lorsque ledit programme fonctionne sur un processeur d’un serveur d’intermédiation. Les modes de réalisation sont décrits en faisant référence aux figures suivantes, dans lesquelles : est un diagramme d’un système pour un contrôle d’accès différentiel à des données partagées ; est un diagramme des composants du serveur d’intermédiation de la FIG. 1 ; est un organigramme d’un procédé de contrôle d’accès différentiel à des données partagées ; est un diagramme d’une exécution exemplaire du bloc 305 du procédé de la FIG. 3 ; est un diagramme illustrant une mise à jour des données de contrôle d’accès utilisées dans le procédé de la FIG. 3 ; et est un diagramme illustrant un autre mécanisme de stockage pour les données de contrôle d’accès utilisées dans le procédé de la FIG. 3. Description détaillée FIG. 1 illustre un système 100 pour un contrôle d’accès différentiel de données partagées (ou partiellement partagées). Dans le système 100, divers sous-systèmes informatiques génèrent des requêtes associées aux données, incluant des requêtes pour visionner ou autrement présenter les données (p. ex. sur un affichage) et des requêtes pour éditer les données. Les sous-systèmes susmentionnés peuvent généralement être désignés comme sous-systèmes demandeurs. Le système 100 peut inclure divers types de sous-systèmes demandeurs, chacun d’eux pouvant être géré par des entités différentes. La nature de l’entité gérant chaque sous-système demandeur définit quels sous-ensembles des données susmentionnées sont traités (p. ex. actualiser ou autrement accédés) par ce sous-système demandeur. La nature des données et des entités gérant les sous-systèmes demandeurs n’est pas particulièrement limitée. Cependant, dans l’exemple illustré exposé ci-dessous, les sous-systèmes demandeurs sont gérés par des entités fournisseuses et des entités vendeuses ou clientes. Les entités clientes et fournisseuses interagissent via les sous-systèmes demandeurs respectifs pour délivrer des articles aux clients. Les articles dans les exemples sont des produits et des services liés au voyage, tels que des billets d’avion, des réservations d’hôtel, des réservations de location de véhicule, et similaires. Les entités fournisseuses peuvent donc être des compagnies aériennes alors que les entités clientes peuvent être des consommateurs au point final ou des agences de voyages achetant les articles ci-dessus pour le compte de ces consommateurs. Les données gérées dans le système 100 dans ces exemples incluent des données définissant des prix et des programmations pour les produits ou les services, identifiant et des informations de contact pour les clients, des données définissant des attributs d’équipements divers (p. ex. un aéronef), des informations de paiement et similaire. L’échange de données dans le système 100 peut être implémenté en fonction d’une quelconque norme appropriée ou une combinaison de normes. Par exemple, le système 100 peut implémenter la norme de nouvelle capacité de distribution (NDC) selon laquelle les entités du système 100 échangent des données via des types et des formats de messages prédéterminés. Certaines portions des données susmentionnées telles que des informations de prix et de programmation sont partagées entre le client et les entités fournisseuses (et donc entre leurs sous-systèmes demandeurs respectifs). Cependant, d’autres portions des données susmentionnées, telles que certaines informations de contact, peuvent être utilisées uniquement par les entités clientes et l’accès à ces données par d’autres entités peut être restreint. Par ailleurs, le système 100 peut inclure des sous-systèmes demandeurs gérés par de multiples entités clientes distinctes et de multiples entités fournisseuses distinctes et l’accessibilité de diverses portions des données utilisées pour réaliser la livraison d’un article donné ou d’un ensemble d’articles peut varier selon les entités fournisseuses et clientes qui ont la responsabilité de cette réalisation. Dans l’exemple illustré de la FIG. 1, le système 100 inclut deux sous-systèmes clients exemplaires 104-1 et 104-2 (collectivement désignés comme étant les sous-systèmes clients 104 ou simplement les clients 104, et désignés de façon générique comme étant un sous-système client 104 ou simplement un client 104). Chaque sous-système client 104 peut être un quelconque dispositif approprié ou une quelconque combinaison appropriée de dispositifs informatiques incluant un serveur, un ordinateur de bureau, un ordinateur portable tel qu’une tablette et similaire. Ainsi que noté ci-dessus, chaque sous-système client 104 dans l’exemple illustré est géré par un client distinct, tel qu’une agence de voyages, qui interagit avec des entités fournisseuses pour organiser l’achat et la concrétisation de produits et de services liés au voyage pour le compte de clients. Le système 100 inclut aussi trois exemples de sous-systèmes de fournisseurs 108-1, 108-2 et 108-3. Chaque sous-système fournisseur 108 peut être un quelconque dispositif approprié ou une quelconque combinaison appropriée de dispositifs informatiques incluant un serveur, un ordinateur de bureau, un ordinateur portable tel qu’une tablette et similaire. Ainsi que noté ci-dessus, chaque sous-système de fournisseur 108 dans l’exemple illustré est géré par une compagnie aérienne distincte qui interagit avec des entités clientes pour organiser l’achat et la concrétisation de produits et de services liés au voyage. De plus, le système 100 tel qu’illustré inclut un sous-système auxiliaire 110 qui peut être géré par une entité supplémentaire distincte des fournisseurs et des clients mentionnés ci-dessus. Par exemple, le sous-système auxiliaire 110 peut être géré par une entité de plan de facturation et de règlement (BSP), responsable pour l’intermédiation des paiements entre les clients et les fournisseurs résultants de la concrétisation susmentionnée des produits et services liés au voyage. Divers autres systèmes auxiliaires peuvent aussi être inclus (non illustrés) tels que d’autres systèmes de recettes et de comptabilité, des applications de clients ou de voyageurs, ou similaires. Le sous-système auxiliaire 110 peut explicitement requérir des portions des données générées et traitées par les sous-systèmes 104 et 108, ou peut facilement recevoir ces données en réponse à divers événements comme cela sera exposé ci-dessous de façon plus détaillée. Le système 100 peut inclure un nombre plus important ou plus petit de sous-systèmes client 104, sous-systèmes de fournisseurs 108 et sous-systèmes auxiliaires 110 dans d’autres exemples. Comme il en ressortira maintenant, les sous-systèmes clients 104, les sous-systèmes fournisseurs 108 et les sous-systèmes auxiliaires 110 représentent divers exemples de sous-systèmes demandeur mentionnés auparavant. C’est-à-dire, que chacun des sous-systèmes client 104, sous-systèmes fournisseurs 108 et sous-systèmes auxiliaires 110 peut demander accès à divers sous-ensembles d’un ensemble de données associé à la concrétisation des articles définissant un itinéraire de voyage. Le système 100 inclut aussi un serveur d’intermédiation 112 (aussi désigné simplement dans la présente comme le serveur 112) interconnecté a chacun des sous-systèmes clients, fournisseurs et auxiliaires, 104, 108 et 110 via un réseau 116. Le réseau 116 peut inclure une quelconque combinaison appropriée de réseaux de zone locale (LANs) et de réseaux de zone étendue (WANs), incluant l’Internet. Le serveur d’intermédiation 112 stocke les données mentionnées ci-dessus dans un répertoire de données partagées 120. En particulier, chacun des ensembles de données associés à la concrétisation des articles définissant un itinéraire de voyage est stocké au serveur d’intermédiation 112 dans un enregistrement de données auquel chacun des sous-systèmes client 104, sous-systèmes de fournisseurs 108 et sous-système auxiliaire 110 peut demander accès. C’est-à-dire que chaque ensemble de données est stocké ensemble dans un enregistrement partagé dans le répertoire 120. Les enregistrements dans le répertoire 120 peuvent être dans le présent exemple des enregistrements de commandes de voyage NDC. D’autres approches pour fournir un accès différentiel aux données peuvent diviser cet enregistrement en de multiples enregistrements distincts et octroyer ou refuser l’accès à chaque enregistrement à une entité donnée (p. ex. un sous-système client 104). Cependant, dans un système tel que le système 100, dans lequel de nombreux sous-systèmes informatiques différents peuvent chercher à accéder aux données, ces approches peuvent introduire des complications coûteuses dans la synchronisation des changements à travers de tels enregistrements séparés. Par contraste aux approches susmentionnées à l’accès différentiel, le serveur d’intermédiation 112 implémente une fonctionnalité, exposée de façon plus détaillée ci-dessous, pour octroyer un accès différentiel à des sous-ensembles de données dans un enregistrement donné unique aux sous-systèmes clients 104, sous-systèmes de fournisseur 108 et sous-système auxiliaire 110. Le serveur d’intermédiation 112 stocke un répertoire de profils 124 contenant, pour au moins certains des sous-systèmes demandeurs, des données de contrôle d’accès définissant des droits d’accès pour d’autres sous-systèmes demandeurs. De plus, le répertoire de profils 124 peut inclure des données de configuration de présentation pour chaque sous-système demandeur, définissant le formatage et d’autres règles d’affichage selon lesquels les données doivent être présentées au sous-système pertinent. Le serveur d’intermédiation 112, en réponse à une quelconque requête pour accéder à un enregistrement dans le répertoire 120 détermine s’il doit octroyer ou refuser l’accès à des sous-ensembles de données dans l’enregistrement pertinent en fonction à la fois du répertoire de profil 124 et des identifiants de certains sous-systèmes dans l’enregistrement lui-même. On retiendra de la discussion dans la présente qu’une grande variété d’autres types de données peut aussi être gérée par une grande variété d’autres types d’entités gestionnaires. Par conséquent, le système 100 ou d’autres systèmes implémentés conformément à l’enseignement de la présente peuvent être soumis au contrôle d’accès aux données dans divers scénarios dans lesquels des sous-systèmes informatiques distincts fonctionnent sur un ensemble de données qui est au moins partiellement partagé entre les sous-systèmes informatiques. C’est-à-dire que l’ensemble de données contenu dans chaque enregistrement dans le répertoire 120 n’a pas besoin de définir un itinéraire de voyage. Avant d’aller plus loin dans la description de la fonctionnalité des divers composants du système 100, certains composants internes du serveur d’intermédiation 112 seront décrits en faisant référence à la FIG. 2. Prêtant attention à la FIG.2, le serveur d’intermédiation 112 inclut au moins un processeur 200, tel qu’une unité de traitement centrale (CPU) ou similaire. Le processeur 200 est relié à une mémoire 204 implémentée comme un support approprié, non transitoire, lisible par ordinateur (p. ex. une combinaison appropriée de sous-systèmes de mémoires volatiles et non volatiles incluant une quelconque ou plusieurs mémoires à accès aléatoire [RAM], mémoires à lecture seule [ROM], mémoires programmables à lecture seule effaçables électriquement [EEPROM], mémoires flash, stockage informatique magnétique, et similaire). Le processeur 200 et la mémoire 204 sont généralement compris d’un ou de plusieurs circuits intégrés (ICs). Le processeur 200 est aussi interconnecté à une interface de communication 208 qui permet au serveur 112 de communiquer avec les autres dispositifs informatiques du système 100 via le réseau 116. L’interface de communication 208 inclut donc tous les composants nécessaires (p. ex. des contrôleurs d’interface de réseau [NICs], des unités de radio, et similaires) pour communiquer via le réseau 116. Les composants spécifiques de l’interface de communication 208 sont sélectionnés en fonction de la nature du réseau 116. Le serveur 112 peut aussi inclure des dispositifs d’entrée et de sortie connectés au processeur 200, tels que des claviers, des souris, des affichages, et similaires (non illustrés). Les composants du serveur 112 mentionnés ci-dessus peuvent être déployés dans une seule enceinte ou sous un format distribué. Par conséquent dans certains exemples, le serveur 112 inclut une pluralité de processeurs qui peuvent soit partager la mémoire 204 et l’interface de communications 208 ou qui ont chacun des interfaces de communications et des mémoires associées distinctes. Par conséquent, les répertoires 120 et 124 peuvent aussi être distribués dans certains exemples selon un quelconque mécanisme approprié pour répliquer certains ou l’ensemble des contenus du répertoire 120 et/ou 124 géographiquement. La mémoire 204 stocke le répertoire de données partagées 120 et le répertoire de profils 124 mentionnés ci-dessus ainsi que des instructions lisibles par ordinateur, exécutables par le processeur 200 pour implémenter diverses fonctionnalités. Les instructions lisibles par ordinateur peuvent aussi être désignées comme étant des applications et, dans l’exemple illustré, la mémoire 204 stocke une application de contrôles d’accès 212 (également désignée simplement dans la présente comme étant l’application 212). Le processeur 200 exécute les instructions de l’application 212 afin d’effectuer diverses actions définies par les instructions contenues dans celle-ci. Dans la description ci-dessous, le processeur 200 et de façon plus générale le serveur 112 sont censés effectuer ou être configurés pour effectuer ces actions. On comprendra qu’ils sont configurés ainsi via l’exécution (par le processeur 200) des instructions des applications stockées dans la mémoire 204. En général, via l’exécution de l’application de 212, le serveur 112 implémente le contrôle d’accès différentiel pour des enregistrements dans le répertoire 120 selon des indicateurs dans ses enregistrements eux-mêmes ainsi que les données dans le répertoire de profils 124. Faisant maintenant référence à la FIG. 3, certains aspects d’exploitation du système 100 seront décrits de façon plus détaillée. Spécifiquement, la FIG. 3 illustre un procédé 300 pour fournir un contrôle d’accès différentiel à des données partagées tel que des données contenues dans les enregistrements du répertoire 120. L’exécution du procédé 300 sera décrite ci-dessous conjointement avec sa mise en œuvre dans le système 100 et en particulier par le serveur d’intermédiation 112. Au bloc 305, le serveur d’intermédiation 112 reçoit une requête pour accéder à un enregistrement dans le répertoire 120. La requête au bloc 305 peut être une requête pour récupérer un enregistrement, p. ex. pour affichage au sous-système demandeur (p. ex. une requête de lecture). Dans d’autres exemples, la requête reçue au bloc 305 peut être une requête pour actualiser un enregistrement, pour insérer ou changer des données dans celui-ci (p. ex. une requête d’écriture). La requête peut être reçue au serveur d’intermédiation 112 en provenance d’un quelconque des sous-systèmes demandeurs susmentionnés (p. ex. les sous-systèmes clients 104, les sous-systèmes de fournisseurs 108 ou le sous-système auxiliaire 110). La requête reçue au bloc 305 est généralement une requête d’accès pour le compte de l’émetteur (c.-à-d. le sous-système demandeur qui a initié la requête). Cependant, dans certains exemples la requête reçue au bloc 305 est une requête d’accès par une entité autre que l’émetteur de la requête. Par exemple, un sous-système de fournisseur 108 peut transmettre une requête pour des données d’un enregistrement dans le répertoire 120 devant être transmises au sous-système auxiliaire 110. Dans d’autres exemples, la réception de la requête inclut la génération de la requête au serveur d’intermédiation 112 lui-même. Par exemple, le serveur 112 peut être configuré en réponse à la réception de certaines mises à jour d’un enregistrement (qui elles-mêmes constituent des requêtes traitées via le procédé 300) pour transmettre automatiquement certaines données au sous-système auxiliaire 110. De telles transmissions automatiques peuvent être traitées comme des requêtes de lecture pour le compte du sous-système auxiliaire 110, bien que le sous-système auxiliaire 110 n’ait par lui-même transmis une requête. La requête reçue au bloc 305 inclut au moins un identifiant d’enregistrement principal correspondant à un des enregistrements dans le répertoire 120. L’identifiant d’enregistrement principal peut être attribué par le serveur d’intermédiation 112 lors de la création de l’enregistrement ou par un des sous-systèmes demandeurs. L’identifiant d’enregistrement principal est utilisé par chacun des sous-systèmes demandeurs pour accéder à l’enregistrement (c.-à-d. l’identifiant d’enregistrement principal est un identifiant commun utilisé par tous les sous-systèmes pour accéder un enregistrement particulier). Comme on le verra de façon plus détaillée ci-dessous la requête reçue au bloc 305 peut aussi inclure d’autres paramètres, tels qu’une indication que la requête est une requête de lecture ou une requête d’écriture, des identifiants de sections particulières de l’enregistrement, des mises à jour devant être appliquées à l’enregistrement, et similaire. Au bloc 310, le serveur 112 détecte un type de la requête reçue au bloc 305. En particulier, le serveur 112 détermine si la requête est une requête de lecture ou une requête d’écriture. Lorsque la requête est une requête de lecture, l’exécution du procédé 300 poursuit au bloc 315 où le serveur 112 détermine quelles sections de l’enregistrement demandé doivent être évaluées en fonction des données de contrôle d’accès. Lorsque la requête est une requête d’écriture, le serveur 112 poursuit directement au bloc 320, outrepassant le bloc 315. L’exécution des blocs 310 et 315 permet au serveur 112 d’identifier des sections de l’enregistrement requis auxquelles un accès est demandé. Une requête d’écriture, afin de spécifier quelles données doivent être insérées ou autrement actualisées dans l’enregistrement, spécifie explicitement les sections (p. ex. les champs de données, les champs de données de groupe ou similaires) auxquelles un accès est demandé. La détection par le serveur 112 des sections auxquelles un accès est demandé n’est donc pas nécessaire. Par contraste, les requêtes de lecture peuvent ne pas explicitement identifier des sections de l’enregistrement auquel un accès est demandé. Au lieu de cela, cette identification peut se faire à partir des données de configuration de présentation mentionnées auparavant. Les données de configuration de présentation définissent, pour chaque sous-système demandeur, quelles sections des enregistrements dans le répertoire 120 doivent être fournies à ce sous-système demandeur (et dans quel format, arrangement sur un affichage et similaire). Dans d’autres exemples, les requêtes de lecture peuvent aussi indiquer explicitement pour quelles sections de l’enregistrement l’accès est demandé et au bloc 315 elles peuvent donc être omises de ces exemples. Cependant, dans le présent exemple il est supposé que les requêtes de lecture contiennent seulement un identifiant d’un enregistrement sans indiquer explicitement quelles portions de cet enregistrement sont demandées. L’attention est maintenant dirigée vers la FIG. 4 montrant une requête exemplaire 400 transmise du sous-système client 104-1 (qui peut aussi être désigné comme étant le sous-système demandeur « actif ») au serveur d’intermédiation 112. La requête 400 inclut au moins un identifiant principal d’enregistrement (« 404-1 » dans le présent exemple) et indique aussi un type de requête (lecture, dans le présent exemple). Également montré dans la FIG. 4 est un contenu partiel du répertoire 120, incluant les enregistrements 404-1 et 404-2. Comme il en ressortira maintenant, la requête 400 est une requête pour présenter (p. ex. afficher) l’enregistrement 404-1 au sous-système client 104-1. Le répertoire 120 peut contenir un quelconque nombre d’enregistrements supplémentaires 404. Chaque enregistrement 404 dans le répertoire 120 inclut un ensemble prédéterminé de champs de données arrangés en un ensemble de sections. Dans l’exemple illustré, les enregistrements 404 incluent chacun une première section 408 contenant deux champs : un champ d’information de paiement, tel qu’un numéro de carte de paiement et un champ de « notes ». Les enregistrements 404 incluent aussi chacun une deuxième section 412 contenant quatre champs (nom de passagers, ville d’origine, ville de destination et prix) et une troisième section 416 contenant un champ (attribution d’équipage pour un vol donné). Un contenu exemplaire des sections 408-1, 412-1 et 416-1 est montré dans l’enregistrement 404-1. Une grande variété d’autres champs peuvent être inclus dans les enregistrements 404 et ces champs peuvent être arrangés dans une grande variété d’autres sections que celles qui sont montrées dans la FIG. 4. Chaque section de chaque enregistrement 404 est associée à un identifiant de propriétaire. Dans l’exemple illustré, les sections 408-1, 412-1 et 416-1 de l’enregistrement 404-1 incluent des identifiants de propriétaire dans les sections elles-mêmes sous forme de champs « ID propriétaire ». Dans d’autres exemples, les enregistrements 404 peuvent inclure une section distincte contenant des identifiants de propriétaire. Comme on le voit dans la FIG. 4, chaque identifiant de propriétaire correspond à un des identifiants de demandeur notés ci-dessus. L’identifiant de propriétaire associé à une section donnée détermine pour les entités demandeuses le niveau d’accès octroyé à la section pertinente. Le serveur 112 reçoit la requête 400 au bloc 310 et détermine au bloc 315 que la requête est une requête de lecture. Le serveur 112 poursuit donc au bloc 315. Au bloc 315, le serveur 112 récupère les identifiants de section demandés en fonction des données de configuration de présentation qui correspondent au demandeur. Ainsi dans le présent exemple, le serveur 112 récupère les données de configuration de présentation correspondant au sous-système client 104-1. Le tableau 1 illustre des contenus exemplaires du répertoire de profils 124 qui contiennent les données de configuration de présentation. Répertoire de profils 124 ID propriétaire Données de contrôle d’accès Données de config.de présentation 104-1 408 : 104-1 R/W 408 : 4 derniers chiffres du No de la carte 412 104-2 108-1 108-2 108-3 412 : 108-3 R/W ; 104-1 R/W ; 104-2R/W 416 : 108-3 R/W 412 416 110 N/A 412 : prix uniquement Seuls certains champs du tableau 1 sont complétés à titre d’illustration ; on comprendra qu’en pratique, le répertoire 124 peut inclure des données de contrôle d’accès et des données de configuration de présentation pour chaque entité demandeuse. Comme on le voit ci-dessus, le répertoire de profils 124 contient des enregistrements correspondant à chaque sous-système demandeur. Chaque enregistrement inclut un identifiant du sous-système demandeur pertinent indiqué ci-dessus sous forme d’identifiant de propriétaire. Les IDs de propriétaire montrées dans le tableau 1 sont les numéros de référence attribués au client, aux sous-systèmes de fournisseur et auxiliaire montrés dans la FIG. 1, mais dans d’autres exemples une grande variété d’identifiants peut être utilisée, incluant une quelconque adresse de réseau appropriée (p. ex. adresse IP, domaine, etc.). Chaque enregistrement définit, pour l’ID de propriétaire pertinent, des données de contrôle d’accès spécifiant les entités demandeuses et leurs niveaux d’accès respectifs aux sections lorsque l’ID de propriétaire pertinent est associé à ces sections. Dans l’exemple montré ci-dessus, l’enregistrement pour le sous-système client 104-1 indique que lorsque le sous-système client 104-1 est le propriétaire d’une section 408 dans un enregistrement 404 (comme c’est le cas dans la FIG. 4 dans laquelle la section 408-1 contient l’ID de propriétaire « 104-1 »), le sous-système client 104-1 lui-même a pleinement accès à cette section. Aucune autre entité n’est habilitée à une quelconque forme d’accès à la section 408. Le répertoire de profils 124 indique aussi, pour le sous-système de fournisseur 108-3, que lorsque le sous-système de fournisseur 108-3 est le propriétaire d’une section 412, le sous-système de fournisseur 108-3 lui-même a pleinement accès à cette section et que les sous-systèmes 104-1 et 140-2 ont aussi pleinement accès à cette section. Lorsque le sous-système de fournisseur 108-3 est le propriétaire d’une section 416, le sous-système de fournisseur 108-3 est le seul à avoir un plein accès à cette section. Chaque enregistrement du répertoire de profils 124 inclut également des données de configuration de présentation qui identifient quelles sont les sections d’un enregistrement dans le répertoire 120 qui doivent être présentées à l’ID de propriétaire à la demande. Dans d’autres exemples, les données de contrôle d’accès et les données de configuration de présentation peuvent être stockées dans des répertoires séparés. Les données de configuration de présentation définissent quelles sections d’un enregistrement 404 doivent être renvoyées à un sous-système demandeur pour affichage ou autre présentation. Les données de configuration de présentation peuvent aussi définir un format dans lequel les données doivent être présentées, une mise en page graphique dans laquelle les données doivent être présentées, et similaires. Dans certains exemples, les données de configuration de présentation peuvent définir des mises en page de présentation pour des comptes séparés, des utilisateurs séparés, ou similaires associés à l’identifiant de propriétaire. Par exemple, des opérateurs distincts associés au sous-système client 104-1 peuvent soumettre des requêtes à un enregistrement donné 404. Toutes ces requêtes incluent l’identifiant de demandeur « 104-1 », mais les requêtes peuvent aussi inclure des sous-identifiants tels que des noms d’utilisateurs ou similaires. Le répertoire de profils 124 peut définir des données de configuration de présentation spécifiques à certains noms d’utilisateurs, groupes de noms d’utilisateurs, ou similaires plutôt que, ou en plus des données de configuration de présentation basées sur un propriétaire par défaut. Dans certains exemples, les données de contrôle d’accès peuvent aussi être spécifiées pour chaque utilisateur comme cela a été exposé ci-dessus en lien aux données de configuration de présentation. De façon similaire, les identifiants de propriétaires peuvent aussi inclure des identifiants de comptes spécifiques, d’utilisateurs ou similaires en association au sous-système demandeur identifié. Par exemple, l’enregistrement correspondant au sous-système client 104-1 indique que le sous-système client 104-1 requiert la présentation d’un enregistrement 404, les sections 408 et 412 sont renvoyées. Par ailleurs, les données de configuration de présentation indiquent que pour le champ de numéro de carte de crédit, seuls les quatre derniers chiffres sont renvoyés. Dans l’exemple montré dans la FIG. 4, au bloc 315 le serveur 112 récupère l’enregistrement du répertoire de profils 124 correspondant au sous-système client 104-1 et détermine que les sections devant être renvoyées au sous-système client 104-1 (subordonnées aux déterminations de contrôle d’accès) sont les sections 408-1 et 412-1. En d’autres termes, au bloc 315, à partir d’une requête qui peut ne pas indiquer explicitement quelles sections de l’enregistrement 400-1 sont requises, le serveur 112 détermine les sections qui sont demandées. Ayant fait cette détermination, le serveur 112 poursuit au bloc 320 pour évaluer l’accessibilité aux sections requises pour l’entité demandeuse (c.-à-d. le sous-système client 104-1, dans l’exemple illustré). Au bloc 320, le serveur 112 récupère les identifiants de propriétaire associés aux sections de l’enregistrement 404 affectées par la requête reçue au bloc 305. Dans le présent exemple, le serveur 112 récupère à partir de l’enregistrement 404-1, les identifiants de propriétaires correspondant aux sections 408-1 et 412-1 comme étant les sections spécifiées dans les données de configuration de présentation pour le sous-système client 104-1. Les identifiants de propriétaire associés aux sections 408-1 et 412-1, comme on le voit dans la FIG. 4 sont « 104-1 » et « 108-3 » respectivement. Dans le cas d’une requête de lecture, les identifiants de section impliqués au bloc 320 sont ceux auxquels la requête d’écriture fait référence. Par exemple, une requête d’écriture peut explicitement identifier certaines sections et les champs de celles-ci qui doivent être actualisés. Dans d’autres exemples, la requête d’écriture peut explicitement identifier seulement des champs spécifiques et le serveur 112 peut déterminer les sections pertinentes à partir du modèle commun auquel adhèrent tous les enregistrements 404 dans le répertoire 120. Ayant récupéré, ou autrement déterminé, les identifiants de section affectés par la requête à partir du bloc 305, au bloc 325 le serveur 112 récupère les données de contrôle d’accès basés sur les identifiants de propriétaire à partir du bloc 320. Spécifiquement, le serveur 112 récupère les données de contrôle d’accès dans le répertoire de profils 124 pour chaque identifiant de propriétaire déterminé au bloc 320. Par conséquent dans l’exemple de la FIG. 4, au bloc 325 le serveur 112 récupère les données de contrôle d’accès pour le sous-système client 104-1 (pour application à la section 408-1) et pour le sous-système de fournisseur 108-3 (pour application à la section 412-1). Le serveur 112 est ensuite configuré pour évaluer la requête du bloc 305 en fonction des données de contrôle d’accès reçues au bloc 325. En particulier, via les exécutions respectives des blocs 330 et 335 pour chacun des identifiants de sections de la requête elle-même, ou à partir du bloc 315, le serveur 112 compare les paramètres de requête (p. ex. l’identifiant du demandeur et le type de requête) avec les données de contrôle d’accès pour déterminer si l’accès peut être octroyé à la section pertinente. Au bloc 330, le serveur 112 sélectionne la prochaine section à traiter pour une détermination d’accès. Dans l’exemple de la FIG. 4, à une première occurrence du bloc 330, le serveur 112 sélectionne donc la section 408-1. Au bloc 335, le serveur 112 détermine si l’accès demandé à la section 408-1 est autorisé. La détermination au bloc 335 peut inclure de comparer l’identifiant du demandeur (p. ex. un identifiant du sous-système client 104-1) aux identifiants de demandeur à partir des données de contrôle d’accès, ainsi que le type de requête au type de requête permis dans les données de contrôle d’accès. Dans le présent exemple, le propriétaire de la section 408-1 est le sous-système client 104-1 lui-même et les données de contrôle d’accès indiquent que le sous-système client 104-1 a un plein accès (c.-à-d. lecture et écriture) aux sections 408 dans lesquelles le sous-système client 104-1 est identifié comme étant le propriétaire. La détermination au bloc 335 est donc affirmative et au bloc 340 une décision d’octroyer l’accès à la section 408-1 est stockée au serveur 112. Lorsque la détermination au bloc 335 est négative (p. ex. si le sous-système client 104-1 a soumis une requête de lecture de la section 416-1 de l’enregistrement 404-1), au bloc 345 le serveur 112 stocke une décision de refuser l’accès à la section pertinente de l’enregistrement 404. En d’autres termes, l’accès peut être accordé ou refusé par le serveur 112, section par section, et la requête du bloc 305 peut recevoir une réponse partielle si le demandeur est autorisé à accéder seulement à un sous-ensemble des sections demandées. Dans d’autres exemples, l’accès peut être octroyé ou refusé pour l’ensemble de la requête. Dans ces exemples, une seule détermination négative au bloc 335 (c’est-à-dire pour une section) peut conduire à un refus d’accès pour la requête dans son ensemble en dépit du fait que l’accès à une quelconque autre section demandée pourrait être admissible. Au bloc 350, le serveur 112 détermine s’il reste d’autres sections à évaluer. Dans l’exemple de la FIG. 4, la détermination au bloc 350 est affirmative parce qu’il reste la section 412-1 à évaluer. Le serveur 112 exécute donc les blocs 330 et 335 pour la section 412-1. À la deuxième occurrence du bloc 335, la détermination est aussi affirmative parce que, comme le montre le tableau 1, les données de contrôle d’accès correspondant au sous-système de fournisseur 108-3 (propriétaire de la section 412-1) indiquent que le sous-système 104-1 a un accès de lecture et d’écriture aux sections 412. Une autre mise en œuvre du bloc 350 est négative dans le présent exemple parce que seules les sections 408-1 et 412-1 sont demandées. Le serveur 112 poursuit donc au bloc 335 où le serveur 112 répond à la requête du bloc 305 en fonction des déterminations d’accès aux blocs 340 et/ou 345. Dans l’exemple de la FIG. 4, le serveur 112 renvoie les sections 408-1 et 412-1 de l’enregistrement 404-1 au sous-système client 104-1 en réponse à la requête 400, la réponse étant formatée selon les données de configuration de présentation dans le répertoire 124 qui correspondent au sous-système client 104-1. Dans le cas des requêtes d’écriture, l’exécution du bloc 355 peut inclure la mise à jour de l’enregistrement ainsi que demandé au bloc 305 ou une mise à jour partielle de l’enregistrement si le sous-système demandeur est autorisé à actualiser certaines des sections requises, mais pas d’autres. Le serveur 112 peut envoyer un message à l’entité demandeuse au bloc 355 indiquant quelles mises à jour ont été appliquées à l’enregistrement 404. Les données de contrôle d’accès et les données de configuration de présentation correspondant à un quelconque sous-système demandeur donné identifié dans le répertoire 124 peuvent être actualisées. Par exemple, un sous-système demandeur donné peut transmettre une requête au serveur 112 pour mettre à jour les données de contrôle d’accès et/ou les données de configuration de présentation dans le répertoire 124 qui correspondent à ce sous-système demandeur. La FIG. 5 illustre une requête 500 du sous-système demandeur 108-3 contenant des données de contrôle d’accès actualisées. En réponse à la réception de la requête 500, le serveur 112 peut actualiser le répertoire 124 comme le montre le tableau 2 ci-dessous. Répertoire de profils 124 ID propriétaire Données de contrôle d’accès Données de config. de présentation 104-1 408 : 104-1 R/W 408 : quatre derniers chiffres du N° de la carte 412 104-2 108-1 108-2 108-3 412 : 108-3 R/W ; 104-1 R/W ; 110 R 416 108-3 R/W 412 416 110 N/A 412 : prix uniquement Comme le montre le tableau 2, les données de contrôle d’accès correspondant au sous-système de fournisseur 108-3 indiquent que le sous-système client 104-2 n’a plus accès aux sections 412 avec le sous-système de fournisseur 108-3 indiqué comme propriétaire et que le sous-système auxiliaire 110 à un accès d’écriture à ces sections. Les données de configuration de présentation peuvent aussi être actualisées par le sous-système demandeur pertinent. C’est-à-dire que le sous-système client 104-1 peut actualiser les données de configuration de présentation montrées ci-dessus par une requête au serveur 112. Dans certains exemples, le serveur 112 peut déterminer si les données de configuration de présentation actualisées et/ou les données de contrôle d’accès induisent des conflits. Par exemple, si le sous-système client 104-1 actualise les données de configuration de présentation pour inclure une référence à la section 416, le serveur 112 peut déterminer qu’aucune donnée de contrôle d’accès ne permet un accès à la section 416 au sous-système client 104-1. Le serveur 112 peut donc empêcher la mise à jour ci-dessus aux données de configuration de présentation ou peut simplement générer un message d’avertissement pour transmission au sous-système client 104-1 indiquant l’existence d’un conflit. Les requêtes pour mettre à jour les données de contrôle d’accès et/ou les données de configuration de présentation peuvent aussi être évaluées en fonction des données de contrôle d’accès elles-mêmes ou selon un ensemble de références de données de contrôle d’accès au cas où aucune donnée de contrôle d’accès ne serait spécifiée pour un sous-système demandeur donné. Ces données de contrôle d’accès de référence, ou par défaut, peuvent aussi être appliquées pour accéder à des requêtes en plus des requêtes de mise jour. Par exemple, selon les contenus du tableau 2, le sous-système de fournisseur 108-3 a plein accès aux sections 416 et peut donc être habilité à octroyer un accès aux sections 416 au sous-système client 104-1. Cependant, le sous-système client 104-1 ne serait pas habilité à s’octroyer cet accès à lui-même. Comme le montrent les tableaux 1 et 2, certains sous-systèmes demandeurs peuvent ne pas avoir de données de contrôle d’accès stockées qui leur soient associées dans le répertoire de profils 124. Le système auxiliaire 110 peut ne pas soumettre de requête au serveur 112 pour accéder aux données. Au lieu de cela, d’autres demandeurs (p. ex. les sous-systèmes demandeurs 108) peuvent envoyer des requêtes au serveur 112 pour transmettre certaines données au sous-système auxiliaire 110. Dans d’autres exemples, le serveur 112 peut automatiquement générer des requêtes internes pour transmettre ces données au sous-système auxiliaire 110, par exemple en réponse à certaines mises à jour aux enregistrements 404. Le répertoire 124 ne contient donc pas les données de contrôle d’accès au sous-système auxiliaire 110, mais ne contient pas de données de configuration de présentation, indiquant que le sous-système auxiliaire 110 reçoit seulement le champ de prix de la section 412. Par ailleurs, comme le montre le tableau 2, le sous-système 110 reçoit ces données uniquement lorsque le sous-système de fournisseur 108-3 est le propriétaire indiqué pour la section pertinente 412. L’identifiant de propriétaire associé à une section d’un enregistrement 404 peut aussi être actualisé, par exemple en réponse à une requête du propriétaire actuellement identifié. Par ailleurs, dans certains exemples plus d’un identifiant de propriétaire peut être indiqué dans une section d’un enregistrement 404. Dans ces exemples, le serveur 112 récupère deux ou plusieurs ensembles de données de contrôle d’accès au bloc 325. Dans les exemples détaillés ci-dessus, les données de contrôle d’accès sont stockées en dehors du répertoire 120. Cependant, dans certains exemples, les données de contrôle d’accès peuvent être stockées partiellement ou entièrement dans les enregistrements 404 eux-mêmes. Par exemple, plutôt qu’un identifiant de propriétaire comme le montre la FIG. 4, un enregistrement 404-1' montré dans la FIG. 6, inclut à la fois un identifiant de propriétaire dans la section 408-1' et des données de contrôle d’accès. Dans l’exemple illustré, les données de contrôle d’accès indiquent que le sous-système client 104-2 a un accès de lecture à la section 408-1'. Ces données de contrôle d’accès dans l’enregistrement peuvent s’ajouter aux données de contrôle d’accès dans le répertoire 124. C’est-à-dire, à la fois les données de contrôle d’accès dans l’enregistrement et le répertoire 124 peuvent être envisagés pour octroyer ou refuser l’accès à un enregistrement. Dans d’autres exemples, les données de contrôle d’accès dans l’enregistrement peuvent outrepasser les données de contrôle d’accès dans le répertoire, p. ex. en remplaçant entièrement de quelconques données de contrôle d’accès dans le répertoire 124. Dans certains exemples, une ou plusieurs sections d’un enregistrement 404 peuvent être cryptées. Par exemple, chaque section d’un enregistrement peut être cryptée avec une clé de cryptage correspondant au propriétaire identifié de cette section et la clé de cryptage pertinente peut être fournie aux sous-systèmes demandeurs habilités à accéder à la section selon les données de contrôle d’accès. Les hommes de métier apprécieront que dans certains modes de réalisation, la fonctionnalité d’une quelconque des applications 212, puisse être implémentée en utilisant du matériel préprogrammé ou des éléments micrologiciels (p. ex. des circuits intégrés spécifiques aux applications [ASICs], des mémoires à lecture seule programmables et effaçables électriquement [EEPROMs, etc.] ou d’autres composants associés. Un procédé de contrôle d’accès à des données comprenant : le stockage, à un serveur d’intermédiation, d’un enregistrement contenant : un identifiant d’enregistrement principal ; une pluralité de sections chacune contenant des données ; et en association à chaque section, un identifiant de propriétaire sélectionné parmi un ensemble d’identifiants de demandeur correspondant aux sous-systèmes demandeurs respectifs ; le stockage, au serveur d’intermédiation, des données de contrôle d’accès correspondant à chaque identifiant de demandeur ; dans lequel les données de contrôle d’accès pour un identifiant de demandeur donné indiquent quels autres identifiants de demandeur sont habilités à accéder à une section de l’enregistrement ayant l’identifiant de demandeur donné qui lui est associé comme identifiant de propriétaire ; en réponse à la réception, au serveur d’intermédiation en provenance d’un sous-système actif des sous-systèmes demandeurs, d’une requête contenant [i] l’identifiant d’enregistrement principal et [ii] un identifiant actif des identifiants de demandeur correspondant au sous-système demandeur actif : l’octroi d’un accès à un sous-ensemble des sections en fonction de l’identifiant du demandeur actif, des identifiants de propriétaire et des données de contrôle d’accès, dans lequel les données de contrôle d’accès sont stockées dans un répertoire de configuration distinct de l’enregistrement, dans lequel le procédé comprend par ailleurs : la réception, au serveur d’intermédiation en provenance de l’un des sous-systèmes demandeurs de données de contrôle d’accès actualisées correspondant à l’un des sous-systèmes demandeurs; et la mise à jour des dites données de contrôle d’accès. Le procédé de la revendication 1, dans lequel l’octroi d’un accès à un sous-ensemble des sections comprend de récupérer le sous-ensemble des sections dans l’enregistrement et de transmettre le sous-ensemble des sections au sous-système demandeur actif. Le procédé de la revendication 2, comprenant par ailleurs : le stockage, au serveur d’intermédiation, de données de configuration de présentation ; dans lequel la transmission du sous-ensemble des sections comprend d’arranger le sous-ensemble des sections en fonction des données de configuration de présentation pour affichage au sous-système demandeur. Le procédé de la revendication 3, comprenant par ailleurs : la réception, au serveur d’intermédiation en provenance de l’un des sous-systèmes demandeurs de données de configuration de présentation actualisées correspondant à l’un des sous-systèmes demandeurs ; et la mise à jour des données de configuration de présentation. Le procédé de la revendication 4, dans lequel les données de contrôle d’accès incluent des données de contrôle d’accès par défaut stockées dans le répertoire de configuration. Le procédé de l’une quelconque des revendications 1 à 5, dans lequel les données de contrôle d’accès incluent par ailleurs des donnèes du dèrogation de contrôle d'accès stockées dans un enregistrement. Le procédé de l’une quelconque des revendications 1, dans lequel chacune des sections inclut un ou plusieurs champs distincts de données. Le procédé de l’une quelconque des revendications 1 à 7, dans lequel au moins une des sections est cryptée. Le procédé de l’une quelconque des revendications 1 à 8, comprenant par ailleurs : la réception, au serveur d’intermédiation d’une requête pour remplacer un identifiant initial de propriétaire d’une section par un nouvel identifiant de propriétaire ; et le remplacement de l’identifiant initial de propriétaire par le nouvel identifiant de propriétaire. Un serveur d’intermédiation pour le contrôle d’accès à des données, le serveur d’intermédiation comprenant : une interface de communication ; une mémoire configurée pour stocker : un enregistrement contenant [i] un identifiant d’enregistrement principal ; (ii) une pluralité de sections chacune contenant des données ; et [iii] en association à chaque section, un identifiant de propriétaire sélectionné parmi un ensemble d’identifiants de demandeur correspondants à des sous-systèmes demandeurs respectifs ; et des données de contrôle d’accès correspondant à chaque identifiant de demandeur ; dans lequel les données de contrôle d’accès pour un identifiant de demandeur donné indiquent quels autres identifiants de demandeur sont habilités à accéder à une section de l’enregistrement ayant l’identifiant de demandeur donné qui lui est associé comme identifiant du propriétaire ; un processeur interconnecté à la mémoire et à l’interface de communication, le processeur étant configuré pour : en réponse à la réception d’un sous-système actif des sous-systèmes demandeurs d’une requête contenant [i] l’identifiant d’enregistrement principal et [ii] un identifiant actif des identifiants de demandeur correspondant au sous-système demandeur actif: octroyer un accès à un sous-ensemble des sections en fonction de l’identifiant du demandeur actif, des identifiants de propriétaire et des données de contrôle d’accès, dans lequel les données de contrôle d’accès sont stockées dans un répertoire de configuration distinct de l’enregistrement, dans lequel le processeur est par ailleurs configuré pour : recevoir de l’un des sous-systèmes demandeurs des données de contrôle d’accès actualisées correspondant audit un des sous-systèmes demandeurs ; et mettre à jour les dites données de contrôle d’accès dans la mémoire. Le serveur d’intermédiation de la revendication 10, dans lequel le processeur est configuré, afin d’octroyer un accès à un sous-ensemble des sections, pour : récupérer le sous-ensemble des sections dans l’enregistrement et transmettre le sous-ensemble des sections au sous-système demandeur actif. Le serveur d’intermédiation de la revendication 11, dans lequel la mémoire est par ailleurs configurée pour stocker des données de configuration de présentation ; et dans lequel le processeur est par ailleurs configuré, afin de transmettre le sous-ensemble des sections, pour arranger le sous-ensemble des sections en fonction des données de configuration de présentation pour affichage au sous-système demandeur. Le serveur d’intermédiation de la revendication 12, dans lequel le processeur est par ailleurs configuré pour : recevoir de l’un des sous-systèmes demandeurs des données de configuration de présentation actualisées correspondant à l’un des sous-systèmes demandeurs; et mettre à jour les données de configuration de présentation dans la mémoire. Le serveur d’intermédiation de la revendication 10, dans lequel les données de contrôle d’accès incluent des données de contrôle d’accès par défaut stockées dans le répertoire de configuration. Le serveur d’intermédiation de l’une quelconque des revendications 10 à 14, dans lequel les données de contrôle d’accès incluent par ailleurs des donnèes du dèrogation de contrôle d'accès stockées dans l’enregistrement. Le serveur d’intermédiation de l’une quelconque des revendications 10 à 15, dans lequel chacune des sections inclut un ou plusieurs champs distincts de données. Le serveur d’intermédiation de l’une quelconque des revendications 10 à 16, dans lequel au moins une des sections est cryptée. Le serveur d’intermédiation de l’une quelconque des revendications 10 à 17, dans lequel le processeur est par ailleurs configuré pour : recevoir une requête pour remplacer un identifiant initial de propriétaire d’une section par un nouvel identifiant de propriétaire ; et remplacer l’identifiant initial de propriétaire par le nouvel identifiant de propriétaire. Un produit programme d’ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur comprenant : des moyens de programme lisibles par ordinateur pour stocker, au serveur d’intermédiation, un enregistrement contenant : un identifiant d’enregistrement principal ; une pluralité de sections chacune contenant des données ; et en association à chaque section, un identifiant de propriétaire sélectionné parmi un ensemble d’identifiants de demandeur correspondant à des sous-systèmes demandeurs respectifs ; des moyens de programme lisibles par ordinateur pour stocker, au serveur d’intermédiation, des données de contrôle d’accès correspondant à chaque identifiant de demandeur ; dans lequel les données de contrôle d’accès pour un identifiant de demandeur donné indiquent quels autres identifiants de demandeur sont habilités à accéder à une section de l’enregistrement ayant l’identifiant de demandeur donné qui lui est associé comme identifiant de propriétaire ; en réponse à la réception, au serveur d’intermédiation d’un sous-système actif des sous-systèmes demandeurs d’une requête contenant [i] l’identifiant d’enregistrement principal et [ii] un identifiant actif des identifiants de demandeur correspondant au sous-système demandeur actif: octroyer l’accès à un sous-ensemble des sections en fonction de l’identifiant du demandeur actif, des identifiants de propriétaire et des données de contrôle d’accès, lorsque ledit programme fonctionne sur un processeur d’un serveur d’intermédiation, dans lequel les données de contrôle d’accès sont stockées dans un répertoire de configuration distinct de l’enregistrement, dans lequel le procédé comprend par ailleurs : la réception, au serveur d’intermédiation en provenance de l’un des sous-systèmes demandeurs de données de contrôle d’accès actualisées correspondant à l’un des sous-systèmes demandeurs; et la mise à jour des dites données de contrôle d’accès.