FR 2779595 A1 19991210 FR 9807186 A 19980608 L'invention concerne la gestion de priorités d'accès par des applications à des ressources dans un réseau de communication domestique, ainsi qu'un appareil pour la mise en oeuvre du procédé. Dans un réseau domestique, un certain nombre d'appareils sont reliés par un réseau de communication et communiquent par l'intermédiaire d'un langage commun. De tels réseaux évoluent vers la transmission de données audio et vidéo, et peuvent par exemple être basés sur un bus série de type IEEE 1394. Les appareils connectés au réseau peuvent posséder des 'ressources', c'est à dire des fonctionnalités particulières. Un téléviseur possède par exemple un tuner, un écran cathodique, tandis qu'un magnétoscope possède un tuner et une fonctionnalité d'enregistrement. Les ressources d'un appareil pouvant être mises à la disposition des autres appareils du réseau (par exemple un magnétoscope effectue l'enregistrement d'une émission en contrôlant le tuner du téléviseur), des conflits d'accès aux ressources peuvent apparaître, une ressource pouvant recevoir des commandes contradictoires de la part de diverses applications. L'invention a pour but de proposer une gestion des priorités d'accès. L'invention a pour objet un procédé de gestion de priorités d'accès d'applications à des ressources d'appareils connectés par un réseau de communication, caractérisé en ce que ledit procédé comporte les étapes: d'attribution d'un niveau primaire de droits d'accès à une application effectuant la réservation d'une ressource, - d'attribution d'un niveau secondaire de droits d'accès à d'autres applications effectuant une réservation de ladite ressource, les droits d'accès du niveau secondaire étant tels qu'ils n'interfèrent pas avec les droits d'accès du niveau primaire. Selon un mode de réalisation particulier, une ressource admet simultanément des réservations par au moins N applications, avec N supérieur ou égal à 1. Selon un mode de réalisation particulier, une application effectuant une tentative de réservation d'une ressource déjà réservée par N applications est mise dans une file d'attente, en attendant la libération de la ressource par l'une des N applications. Selon un mode de réalisation particulier, la mise en attente d'une application dans une file d'attente n'est effectuée que si cela est spécifié par cette application. Selon un mode de réalisation particulier, chaque application possède un profil correspondant à un niveau de priorité. Selon un mode de réalisation particulier, un des niveaux de priorité caractérise une application apte à être directement commandée par un utilisateur. Selon un mode de réalisation particulier, une application requiert le statut d'application primaire à une application primaire actuelle par un procédé de négociation comportant l'étape d'acceptation ou de refus du remplacement par l'application primaire actuelle. Selon un mode de réalisation particulier, le procédé de négociation est mis en oeuvre lorsque l'application primaire possède le niveau de priorité caractérisant une application apte à être commandée directement par un utilisateur et que le niveau de priorité de l'application requérant le statut d'application primaire possède un niveau de priorité identique ou plus faible. Selon un mode de réalisation particulier, une application requiert le statut d'application primaire à une application primaire actuelle par un procédé de préemption comportant l'étape d'abandon forcé dudit statut par l'application primaire actuelle. Selon un mode de réalisation particulier, le procédé de préemption est mis en oeuvre lorsque l'application requérant le statut d'application primaire possède un niveau de priorité plus élevé que le niveau de priorité de l'application primaire actuelle. L'invention a aussi pour objet un appareil dans un réseau de communication domestique comportant au moins une ressource locale apte à être réservée par d'autres appareils connectés au réseau et des moyens de connexion audit réseau, caractérisé en ce qu'il comporte en outre un gestionnaire des ressources apte à mémoriser des informations statiques et/ou dynamiques relatives à l'ensemble des ressources locales et des applications ayant réservé une ressource locale, lesdites informations identifiant pour chaque ressource réservée l'unique application possédant les droits d'accès les plus étendus à cette ressource. D'autres caractéristiques et avantages de l'invention apparaîtront à travers la description d'un exemple de réalisation non limitatif illustré par les figures jointes parmi lesquelles - la figure 1 est un diagramme bloc d'un réseau d'appareils mettant en oeuvre le procédé conforme à l'invention, - la figure 2 est un schéma représentant l'organisation logique d'un appareil de la figure 1. Sur les différentes figures, les mêmes éléments portent des références identiques. Le réseau de la figure 1 est constitué dans le présent exemple de réalisation d'un bus série conforme au standard IEEE 1394 -1995. Ce bus, référencé 1, relie des appareils 2, 4, 5 et 6. On entend par 'appareil' un ensemble physiquement distinct relié au réseau. Chaque appareil peut comporter un ou plusieurs sous-appareils, tels que le sous-appareil 3. Ces sous-appareils peuvent être des ressources, qui sont des fonctionnalités d'appareils Les ressources forment des modules logiciels ('software elements' en langue anglaise) au sens du document 'HAVi' mentionné plus loin. A titre d'exemple (voir figure 2), un appareil A est un décodeur de télévision numérique, tandis qu'un autre appareil, I'appareil B, est un magnétoscope. Le décodeur A possède deux ressources, à savoir un tuner 12 et un démultiplexeur 13. Le magnétoscope B possède également deux ressources: un tuner 14 et la fonctionnalité d'enregistrement 15. Chacun des appareils A et B comporte une application (respectivement 18 et 19) qui est une interface utilisateur graphique, qui permet à un utilisateur de gérer directement les fonctionnalités de chaque appareil. L'interface utilisateur de l'appareil A permet selon le présent exemple de réalisation de gérer l'enregistrement, par un autre appareil du réseau, de programmes issus du démultiplexeur 13. Une ressource peut être résidente, c'est à dire présente dès l'origine dans un appareil, mais peut également être téléchargée. Chaque appareil comporte également un registre (respectivement référencé 16, 17 pour chacun des appareil A et B). Le registre fait l'objet d'une demande de brevet français au nom de la demanderesse, déposée le 23 avril 1998 et portant le numéro 9805110. Il est d'autre part décrit dans le document 'The HAVi Architecture Specification of the Home Audio/Video interoperability (HAVi) Architecture' en date du 11 mai 1998 en sa version 0.8 et mis à disposition du public depuis le 15 mai 1998 sur les sites Internet notamment des entreprises Sony, Philips, Toshiba, Sharp et Hitachi. On se référera également à ces documents pour de plus amples renseignements sur les divers éléments du réseau, la présente description se limitant aux éléments nécessaires pour l'explication de l'invention. Le registre d'un appareil (aussi appelé 'registre local' pour cet appareil, par opposition à des 'registres distants' résidant dans d'autres o0 appareils) participe à la gestion de l'ensemble des ressources de cet appareil. Pour cet effet, le registre comporte une table dans laquelle viennent s'enregistrer les autres ressources de l'appareil, en indiquant leurs attributs (type de la ressource, identificateur de la ressource dans le réseau,...). Lorsqu'un module logiciel doit communiquer avec un autre module logiciel local, il peut obtenir la liste de ces modules par l'intermédiaire du registre local, qui possède une adresse locale connue. Lorsqu'un module logiciel doit communiquer avec un module logiciel distant d'un autre appareil, il peut obtenir l'adresse ('SEID') du module logiciel distant en passant par le registre local. Un module logiciel peut déterminer une liste de modules correspondant à certains critères de recherche, indépendamment de la localisation de ces modules, en transmettant une requête au registre local qui propage cette requête aux registres distants. La requête comporte sous forme de paramètres les critères de sélection des modules logiciels recherchés, par exemple le type de module (afficheur, enregistreur,...). A ce titre, les ressources d'un appareil s'enregistrent également au niveau du registre local, au même titre que les autres modules logiciels. Un module téléchargé s'enregistre auprès du registre de l'appareil qui fait office de plate-forme d'exécution de ce module. Une application peut être de l'un des deux profils suivants Utilisateur ou Machine. Le profil Utilisateur correspond à une application qui interagit directement avec l'utilisateur, comme par exemple l'interface utilisateur graphique 18 de l'appareil A. Le profil Machine correspond à une application qui n'est pas contrôlée directement par un utilisateur, mais qui met par exemple en oeuvre une action programmée. Une application peut contrôler une ressource. Une application peut également être une ressource et à ce titre être contrôlée par une autre application. Selon le présent exemple de réalisation, une application de profil Utilisateur aura une prépondérance sur une application de profil Machine lorsqu'il s'agira de résoudre un conflit de réservation d'une ressource. On dira que le profil Utilisateur possède un niveau de priorité plus élevé que le profil Machine. Selon une variante de réalisation, d'autres profils d'applications sont prévus: Arrière plan, Installation, Sécurité et Système, correspondant respectivement à des applications de faible priorité occupées à des tâches de fond (par exemple nettoyage de données obsolètes), des applications utilisées pendant l'installation et la configuration du réseau, des applications informant l'utilisateur de certains événements importants (alarmes de sécurité par exemple), et des applications système (par exemple les registres et les gestionnaires de ressources). Une ressource possède un certain nombre de propriétés Une ressource peut être de nature dite statique ou dynamique. Une ressource dynamique peut être divisée en plusieurs parties indépendantes, moyennant la spécification de paramètres adéquats. Typiquement, la bande passante est une ressource dynamique: une application réservant une bande passante devra spécifier la largeur de bande à réserver. Une ressource de nature statique est une ressource ne pouvant être réservée de cette manière. Une ressource dynamique possédera un état de réservation qui correspond à la quantité restante disponible. Une ressource statique peut être dans un parmi trois états de réservation, un état dit disponible, un état dit partagé, et un état dit verrouillé. Dans l'état disponible, la ressource n'est contrôlée par aucune application. Dans l'état partagé, la ressource est contrôlée par au moins une application, mais d'autres applications peuvent néanmoins utiliser la ressource, avec certaines restrictions concernant les commandes de contrôle admises pour ces autres applications. Dans l'état verrouillé, la ressource est contrôlée par au moins une application et rejettera toute commande de contrôle en provenance d'une autre application. D'autre part, on associera à chaque ressource un descripteur, c'est à dire une structure de données ou encore enregistrement, comportant des valeurs de variables identifiant les fonctionnalités de la ressource, ainsi qu'une adresse dans le réseau. Comme déjà mentionné, ce descripteur est enregistré au niveau du registre local. Selon le présent exemple de réalisation, le descripteur de ressource indique le domaine d'activité de la ressource (par exemple audio/video, chauffage, appareils ménagers,...), le type de la ressource, qui indique sa fonction (syntoniseur, décodeur, modem,...), le niveau d'accessibilité (ressource 'locale', accessible uniquement par des applications résidant dans le même appareil, ou ressource 'publique', accessible également par des applications exécutées sur des plates- formes autres que l'appareil dans lequel réside l'application publique). La gestion des ressources est basée sur un mécanisme de réservation. Une réservation est nécessaire pour la mise en oeuvre de commandes de contrôle et plus généralement pour tout accès en écriture changeant l'état d'une ressource. Une réservation n'est généralement pas nécessaire pour un accès en lecture. Une fois une réservation acceptée, I'application devient une application cliente de la ressource: elle en a le contrôle, mais elle n'est pas nécessairement la seule application à être dans ce cas, d'o la nécessité d'un mécanisme de résolution de conflits d'accès à la ressource. Chaque appareil dispose d'un module logiciel appelé 'gestionnaire des ressources'. Dans le réseau de la figure 2, les gestionnaires des ressources des appareils A et B sont référencés respectivement 20 et 1 1. Ces modules collaborent avec les registres. Tandis que les registres maintiennent localement une liste des modules logiciels (ressources, applications,...) disponibles, le gestionnaire des ressources gère les informations relatives à l'accessibilité et à l'état de ces ressources. Selon le présent exemple de réalisation, un gestionnaire de ressources gère les ressources locales. Les informations maintenues par les registres sont relativement statiques, tandis que celles maintenues par les gestionnaires de ressources sont susceptibles d'évoluer rapidement, d'o la séparation des deux types de services. Selon le présent exemple de réalisation, un gestionnaire de ressources obtient la liste des ressources locales auprès du registre local. Les ressources non résidentes sont ainsi facilement accessibles au gestionnaire de ressources. Par exemple, lorsqu'un module de contrôle de fonction ('FCM' selon terminologie HAVi) est déchargé à partir d'un appareil audio-vidéo de base ('BAV' selon la terminologie HAVi), ce module de contrôle s'enregistre auprès du registre local de l'appareil lui servant de plate-forme d'exécution, tel qu'un appareil audio-vidéo à fonctionnalités complètes ('FAV'). Les principes utilisés pour le réservation sont les suivants - avant de lancer une commande de contrôle d'une ressource, une application doit réserver cette ressource auprès du gestionnaire des ressources de l'appareil dans lequel réside la ressource, et - une application doit libérer une ressource qu'elle n'utilise plus. Selon le présent exemple de réalisation, une application souhaitant effectuer une réservation détermine l'adresse du gestionnaire des ressources de l'appareil dans lequel réside la ressource par l'intermédiaire du registre de l'appareil dans lequel réside l'application. Une fois l'adresse obtenue, I'application peut contacter le gestionnaire des ressources en vue de s'informer de l'état de la ressource. Le fait de passer par le gestionnaire des ressources au lieu de s'adresser directement à la ressource permet de maintenir les informations relatives à la disponibilité des ressources d'un appareil de manière centralisée au niveau de cet appareil. Par contre une fois la réservation obtenue, I'application ayant effectuée cette réservation obtient le contrôle de la ressource et adresse ses commandes de contrôle directement à la ressource. Le gestionnaire des ressources n'est contacté par la suite que pour indiquer que la ressource a été libérée. Pour chaque ressource, le gestionnaire des ressources maintient une structure de données dite 'structure de contention', qui contient les informations suivantes: (1) Informations statiques Ce type d'information n'a à priori pas vocation à évoluer. Ces informations sont chargées par le gestionnaire de ressources à partir des ressources. (a) Le mode de contrôle de la ressource Le mode de contrôle peut être l'un des suivants: Transparent, Partageable, Exclusif. Dans le cas d'un contrôle partageable, on indiquera également le mécanisme de résolution de conflits d'accès partagés: Répartition des applications en application primaire et applications secondaires, ou égalité de traitement pour toutes les applications. (b) Nombre maximum d'applications supportées s Ce champ est utilisé en cas de mode partageable ou exclusif. La ressource indique le nombre maximal d'applications supportées simultanément, le minimum étant 1. (2) Informations dynamiques (a) Informations relatives aux applications contrôlant la ressource Parmi les données mémorisées relatives à chaque application, on trouvera: - le profil de l'application (Utilisateur ou Machine), - le cas échéant, s'il s'agit d'une application primaire ou secondaire (voir ci-dessous), - des données dites privées, réservées à une utilisation non encore définie, - un champ texte comportant un descriptif du motif de la réservation (par exemple 'Enregistrement de la Chaîne Z'). (b) Etat actuel de la ressource: Disponible, Partagé, Verrouillé (c) Nombre d'applications contrôlant la ressource (d) Liste des applications contrôlant la ressource (e) Liste des applications en attente de pouvoir contrôler la ressource (par exemple parce que le nombre maximal d'applications pour cette ressource a été dépassé). Les applications, comme les ressources, sont identifiées par une adresse définie dans le document HAVi et portant le nom 'SEID'. La ressource elle-même doit également maintenir un minimum de données relatives aux applications qui la contrôlent, en vue de la mise en oeuvre des mécanismes de préemption et de négociation. En cas de mise en oeuvre du mécanisme de répartition en application primaire et applications secondaires, il faudra mémoriser au moins l'identificateur de l'application primaire. Dans le mode de contrôle Transparent, la ressource accepte un contrôle simultané sans restriction de la part de plusieurs applications, sans faire de distinction entre les applications. Dans le mode Partageable, plusieurs applications peuvent contrôler en même temps la ressource, mais cette dernière mettra en oeuvre des procédés de résolution de conflit d'accès et de partage de ressource si les commandes des applications risquent de conduire à un fonctionnement incorrect. Un exemple est celui du décodeur A de la figure 2. Le tuner de cet appareil est réglé pour la réception d'un signal en provenance d'un transpondeur particulier, correspondant à un certain flux multiplexé. Dans ce flux, le démultiplexeur a la capacité de repérer les paquets correspondant à un service ou à un autre, et d'extraire ces paquets vers les applications clientes. En supposant qu'un flux donné véhicule une dizaine de services, des applications distinctes peuvent utiliser la ressource démultiplexeur pour accéder à des services identiques ou différents. Le démultiplexeur fonctionne alors comme un serveur. Un conflit apparaît lorsqu'une application veut changer de transpondeur: ceci implique que toute autre application perdra l'accès aux services transmis sur le transpondeur actuel. Selon l'invention, le procédé de résolution préféré d'un tel conflit est le suivant: les applications clientes d'une ressource sont classées en applications clientes primaires et secondaires. Une seule application peut être une application primaire pour une ressource: c'est celle qui a réservé la ressource en premier. Toutes les autres applications sont des applications secondaires. La ressource accepte toutes les commandes en provenance de l'application primaire, mais peut n'accepter que certaines commandes, et ce de façon limitée, de la part des applications secondaires. Les commandes des applications secondaires ne sont prises en compte que dans la mesure o elles n'entrent pas en conflit avec les commandes de lI'application primaire. Dans l'exemple du démultiplexeur donné plus haut, seule l'application primaire a la possibilité de changer de transpondeur. Les applications secondaires ont simplement le droit de choisir un service sur le transpondeur actuel. Selon une variante de réalisation, I'application primaire informe son utilisateur final (par exemple le téléspectateur) des perturbations que son action peut entraîner. Selon le présent exemple de réalisation, les applications secondaires ont toutes des possibilités de commande identiques. On distingue deux procédés: selon le premier procédé, une application ne peut perturber les commandes précédemment transmises à la ressource par une autre application ('principe du respect mutuel'), tandis que selon le second procédé, une application peut perturber une autre application. Dans tous les cas, ce qu'est une 'perturbation' d'une application secondaire par une autre dépend de la nature de la ressource contrôlée et c'est cette dernière qui devra trancher. Selon le présent exemple de réalisation, c'est le principe du respect mutuel qui est mis en oeuvre en ce qui concerne les conflits d'accès entre applications secondaires. Selon une variante de réalisation, comme déjà mentionné en relation avec l'application primaire, une application secondaire avertit, s'il y a lieu, son utilisateur final des restrictions imposées à son action. Selon une autre variante de réalisation, le principe d'égalité de traitement des applications secondaires est appliqué à toutes les applications: il n'y a pas dans ce cas d'application primaire. Dans le mode Exclusif, la ressource ne pourra être contrôlée que par une seule application à un moment donné. La ressource mémorise au moins l'identité de cette application, ainsi que son niveau de priorité(type Utilisateur ou Machine selon le présent exemple de réalisation). A titre d'exemple, on prendra la commande des mécanismes d'un magnétoscope, comme l'appareil B de la figure 2. Un conflit peut apparaître si une application demande l'enregistrement d'une émission, tandis qu'une autre application demande un peu plus tard l'éjection du support d'enregistrement. Dans ce cas, la première application aura un contrôle exclusif. A titre d'exemple, la table 1 donne pour une ressource partageable des informations mémorisées au niveau de chaque ressource: Application Profil Accès Dans queue l____ ____ __ __ __ _d'attente A1 UTILISATEUR Primaire Non A2 I A2 MACHINE Secondaire Non A3 UTILISATEUR Lecture Oui _ _ __ _ _ IL I Ou _ Table 1 Selon le type de ressource, le mode de contrôle peut différer pour différentes commandes. Par exemple, seules les commandes qui changent l'état d'une ressource peuvent générer des conflits et justifier de ce fait un mode de contrôle exclusif ou partageable, tandis que toutes les autres commandes, accès en lecture, demandes d'événements sont gérés selon le mode transparent. Pour réserver une ressource, une application transmet une commande correspondante au gestionnaire des ressources local à la ressource. Cette commande comporte en tant que paramètres les informations relatives à l'application inscrites par la suite dans la structure de contention au niveau du gestionnaire des ressources. Aucune réservation n'est effectuée par une application pour une ressource en mode transparent. Selon le présent exemple, une réservation est effectuée pour l'obtention immédiate du contrôle d'une ressource. Selon l'état actuel de la ressource, trois cas peuvent se présenter: - La réservation est acceptée et l'application devient l'application primaire ou une application secondaire. C'est le cas lorsque la ressource est initialement respectivement dans l'état disponible ou partageable. - La réservation est rejetée car la ressource est verrouillée (par exemple parce que le nombre maximal d'applications a été atteint). L'application peut requérir, sous la forme d'un drapeau dans la commande de réservation, d'être placée dans la queue d'attente de cette ressource, et d'obtenir une notification de la part du gestionnaire des ressources lorsqu'il lui aura automatiquement attribué un nouveau niveau d'accès (soit un accès secondaire devenant primaire, soit une application dans la file d'attente devenant application secondaire ou primaire).. L'adresse de l'application est alors mémorisée dans une pile de la structure de contention de la ressource appropriée. - La mise en attente de l'application si son profil est tel qu'il lui permet de négocier le titre d'application primaire avec l'application primaire actuelle. Le mécanisme de négociation ou de préemption est, selon le présent exemple, mis en oeuvre par le gestionnaire des ressources. Le gestionnaire des ressources transmet en retour vers l'application le résultat de la réservation. Si la réservation est acceptée, le message comporte également l'information selon laquelle l'application est primaire ou secondaire. Lorsque l'application a obtenu le contrôle de la ressource et a terminé son action, elle transmet une commande de libération de la ressource au gestionnaire des ressources. Ce dernier efface alors l'application et les informations s'y rapportant de la structure de contention appropriée. C'est également le cas pour une application en attente n'ayant plus besoin d'une ressource pour laquelle elle a tenté d'effectuer une réservation dans le passé, elle doit libérer la ressource. Selon le présent exemple de réalisation, deux mécanismes sont prévus pour effectuer le remplacement d'une application primaire par une autre application: la préemption et la négociation. Le type de mécanisme est identifié dans la commande de réservation envoyée par une application au gestionnaire des ressources. Lorsqu'une application souhaite négocier le statut d'application primaire avec l'actuelle application primaire, elle envoie un message en ce sens au gestionnaire des ressources, qui à son tour transmet un message à l'application primaire. Celle-ci peut soit accepter, soit refuser de céder sa place. Une application de type Utilisateur peut par exemple transmettre la demande à l'utilisateur lui-même. Une application peut également mettre en oeuvre le mécanisme de préemption pour s'approprier le statut d'application primaire. Dans ce cas, le gestionnaire des ressources vérifie que cette application a bien la priorité pour faire cette requête, par rapport à la priorité de l'application primaire actuelle. S'il autorise la préemption, le gestionnaire des ressources envoie une commande de transfert, que l'application primaire a l'obligation d'accepter. Un temps donné est alors accordé à l'application primaire pour libérer la ressource. Si ce temps n'est pas respecté, le gestionnaire des ressources effectue le transfert d'office de la ressource. En liaison avec le mécanisme de répartition des applications clientes en application primaire et applications secondaires, la résolution des conflits pour la position d'application primaire lors de la réservation répond aux règles suivantes, sachant que l'on se place dans le cas o seuls les profils Utilisateur et Machine existent: (1) Une application de profil Utilisateur a toujours priorité sur une application de profil Machine. (2) La première application réservant une ressource partageable devient l'application primaire. Une application primaire peut interférer avec lescommandes d'applications secondaires. Une application secondaire ne peut interférer avec une commande de l'application primaire. (3) Une application de profil Utilisateur n'est jamais soumise au droit de préemption d'une autre application (Utilisateur ou Machine) sans phase de négociation. (4) Quand une application primaire libère une ressource, c'est l'application secondaire ayant le niveau de priorité le plus élevé qui devient application primaire. Dans le cas o plusieurs applications secondaires possèdent ce niveau de priorité, c'est l'application la plus ancienne qui devient application primaire. Une application en attente prend alors la place de l'application secondaire. Quatre cas de conflit peuvent se présenter, selon le profil de I'application primaire et celui de l'application cherchant à effectuer une réservation (on supposera ici qu'il y a négociation chaque fois qu'au moins une des deux applications est de profil Utilisateur): (a) L'application primaire a un profil Utilisateur et l'application requérant la réservation a un profil Machine: Dans ce cas, la ressource transmet un message à l'application Utilisateur pour vérifier si ce dernier peut céder la main. Si c'est le cas, l'application de profil Machine devient l'application primaire. Sinon, l'application Machine abandonne sa tentative. Un exemple correspondant à ce cas est celui d'un téléspectateur regardant un service diffusé sur un transpondeur A, tandis qu'un magnétoscope préprogrammé doit enregistrer un service sur un transpondeur B, utilisant le même tuner. (b) L'application primaire a un profil Machine et l'application requérant la réservation a un profil Utilisateur: Avant de remplacer l'application primaire Machine par l'application Utilisateur, le gestionnaire des ressources informe l'application Utilisateur des conséquences potentielles de ce remplacement et lui demande une confirmation du remplacement, en lui donnant la possibilité de laisser l'application primaire finir sa tâche. Un exemple correspondant à ce cas est celui o un magnétoscope enregistre un service d'un transpondeur A, tandis qu'un téléspectateur souhaite regarder un service sur un transpondeur B, utilisant le même tuner. Le téléspectateur est alors averti que l'enregistrement en cours devra être arrêté s'il confirme sa décision. (c) L'application primaire a un profil Utilisateur et l'application requérant la réservation a également un profil Utilisateur: Dans ce cas, I'application primaire décidera de garder ou d'abandonner son niveau primaire: le principe est le même que dans le cas (a). Un exemple correspondant à ce cas est celui o un premier téléspectateur regarde un service sur un premier transpondeur (dont il a le contrôle par l'intermédiaire d'une application primaire), tandis qu'un second téléspectateur souhaite regarder un autre service d'un autre transpondeur, en utilisant le même tuner. Le second téléspectateur ne pourra régler le tuner sur la fréquence du nouveau transpondeur qu'avec l'accord du premier téléspectateur. (d) L'application primaire a un profil Machine et l'application requérant la réservation a un également un profil Machine: Etant donné que selon le présent exemple, toutes les applications de profil Machine ont la même priorité, I'application primaire termine sa tâche sans être remplacée. De manière plus générale, quand plus de deux profils existent, le comportement du système est décrit par la table 2. Dans la variante de réalisation comportant plus de deux profils mentionnée ci-dessus, les profils Sécurité et Système ont à titre d'exemple des niveaux de priorité plus élevés que le profil Utilisateur. Il n'y a jamais de préemption d'une application de profil utilisateur par une application de niveau de sécurité identique ou inférieur sans phase de négociation. Cependant, selon l'exemple décrit par la table 2, il n'y a pas de négociation lorsque l'application primaire a un profil Utilisateur, mais que l'application cherchant à obtenir le contrôle possède un niveau de priorité strictement supérieur. Profil/Priorité Priorité de Mécanisme lancé Nouvelle de l'application par le gestionnaire application primaire Il'application requérant la des ressources primaire réservation Utilisateur Priorité Préemption Application supérieure requérant réservation Utilisateur Priorité Négociation Application identique ou primaire actuelle ou inférieure Application requérant réservation Priorité Priorité Préemption Application différente supérieure requérant d'Utilisateur réservation Priorité Priorité Requête rejetée ou Application différente identique ou mise en attente primaire actuelle d'Utilisateur inférieure Table 2 Revendications 1. Procédé de gestion de priorités d'accès d'applications à des ressources d'appareils connectés par un réseau de communication, caractérisé en ce que ledit procédé comporte les étapes: - d'attribution d'un niveau primaire de droits d'accès à une application effectuant la réservation d'une ressource, - d'attribution d'un niveau secondaire de droits d'accès à d'autres applications effectuant une réservation de ladite ressource, les droits d'accès du niveau secondaire étant tels qu'ils n'interfèrent pas avec les droits d'accès du niveau primaire. 2. Procédé selon la revendication 1, caractérisé en ce qu'une ressource admet simultanément des réservations par au moins N applications, avec N supérieur ou égal à 1. 3. Procédé selon la revendication 2, caractérisé en ce qu'une application effectuant une tentative de réservation d'une ressource déjà réservée par N applications est mise dans une file d'attente, en attendant la libération de la ressource par l'une des N applications. 4. Procédé selon l'une des revendications précédentes, caractérisé en ce que chaque application possède le profil correspondant à un niveau de priorité. 5. Procédé selon la revendication 4, caractérisé en ce qu'un des niveaux de priorité caractérise une application apte à être directement commandée par un utilisateur. 6. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'une application requiert le statut d'application primaire à une application primaire actuelle par un procédé de négociation comportant l'étape d'acceptation ou de refus du remplacement par I'application primaire actuelle. 7. Procédé selon la revendication 6, caractérisé en ce que le procédé de négociation est mis en oeuvre lorsque l'application primaire possède le niveau de priorité caractérisant une application apte à être commandée directement par un utilisateur et que le niveau de priorité de l'application requérant le statut d'application primaire possède un niveau de priorité identique ou plus faible. 8. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'une application requiert le statut d'application primaire à une application primaire actuelle par un procédé de préemption comportant l'étape d'abandon forcé dudit statut par l'application primaire actuelle. 9. Procédé selon la revendication 8, caractérisé en ce que le procédé de préemption est mis en oeuvre lorsque l'application requérant le statut d'application primaire possède un niveau de priorité plus élevé que le niveau de priorité de l'application primaire actuelle. 10. Procédé selon la revendication 3, caractérisé en ce que la mise en attente d'une application dans une file d'attente n'est effectuée que si cela est spécifié par cette application. 11. Appareil dans un réseau de communication domestique comportant au moins une ressource locale apte à être réservée par d'autres appareils connectés au réseau et des moyens de connexion audit réseau, caractérisé en ce qu'il comporte en outre un gestionnaire des ressources (11; 20) apte à mémoriser des informations statiques et/ou dynamiques relatives à l'ensemble des ressources locales et des applications ayant réservé une ressource locale, lesdites informations identifiant pour chaque ressource réservée l'unique application possédant les droits d'accès les plus étendus à cette ressource.