INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
&fet~min~l~over~w, &fet~in~parallel); node~width = DeviceL ReqERC fet~max~l~over~w ; free fet tree(fet tree ptr,fet tree ptr); } ~ ~ else node~width = (type == NTYPE) ? CheckLatchDefaultNWidth ReqERC : CheckLatchDefaultPWidth~ReqERC ; /* La valeur L/W totale pour ce trajet dépend d'une somme pondérée des L/W des transistors FET de transfert le long du trajet. Cette valeur dépend également du fait qu'il s'agit d'un trajet élévateur ou abaisseur. */.. pfet~vt~drop = nfet~vt~drop = FALSE ; if (type == PTYPE) total~loverw = (DeviceL~ReqERC/node~width) * PMobility~ReqERC * CheckLatchPFETPassingVDD~ReqERC ; else total loverw = (DeviceL~ReqERC/node~width) * CheckLatchNFETPassingGND~ReqERC ; for (i = NUM~PASSCKT~FETS - 1 ; i > 0; i--) { is~npass = (npass~fets[i] != NULL) ? TRUE : FALSE ; is~ppass = (ppass~fets[i] != NULL) ? TRUE : FALSE ; if (!is~ppass && !is~npass) continue ; if (is~ppass) { pfet~loverw = PMobility~ReqERC * ((ppass~fets[i])->len / (ppass~fets[i])->wid) ; } if (is npass) { nfet~loverw = (npass~fets[i])->len (npass~fets[i])->wid ; } /* La valeur L/W pour cet étage de transistors FET de transfert dépend du fait qu'il s'agit d'un trajet élévateur ou abaisseur et du fait qu'il s'est produit ou non une baisse de Vt le long de ce trajet */ if (type == NTYPE) { /* trajet abaisseur */ pscale = pfet~vt~drop ? CheckLatchPFETPassingGND~Vt~ReqERC : CheckLatchPFETPassingGND~ReqERC ; nscale = nfet~vt~drop ? CheckLatchNFETPassingGND~Vt~ReqERC : CheckLatchNFETPassingGND~ReqERC ; } else { /* trajet élévateur */ pscale = pfet~vt~drop ? CheckLatchPFETPassingVDD~ReqERC ; nscale = nfet~vt~drop ? CheckLatchNFETPassingVDD~Vt~ReqERC : CheckLatchNFETPassingVDD~ReqERC ; } pfet~loverw *= pscale ; nfet~loverw *= nscale ; if (is~npass && is~ppass) { stage~loverw = (nfet~loverw * pfet~loverw) / (nfet~loverw + pfet loverw) ; } else if (is~npass && !is~ppass) { stage~loverw = nfet~loverw ; } else { stage~loverw = pfet~loverw ; } total~loverw += stage~loverw ; /* Pour l'ensemble suivant de transistors FET de transfert, se rappeler s'il s'est produit une baisse de Vt. */ if ( is ppass && !is~npass) pfet~vt~drop # = TRUE ; if (!is~ppass && is~npass) nfet-vt-drop # = TRUE ; } /* Si ce noeud actuel est pire que la proposition actuelle la pire, enregistrer l'information. */ if (total~loverw > *wc~loverw) { *wc~width = node~width ;
*wc~node = node ; *wc~loverw = total~loverw ; for (i = 0 ; elem~pr npass-fets[NUM~PASSCKT~FETS], ppass~fets[NUM~PASSCKT~FETS] ; double wc~loverw = 0.0 ; int i ; for (i = 0 ; < NUM~PASSCKT~FETS; i++) { npass~fets[i] = ppass~fets[i] = NULL ; } push~node~set~mark(node) ; find checklatch driver r(node, wc~~node, type, wc~width, &wc~loverw, ppass~fets, npass~fets, 0, wc~ppass~fets, wc npass-fets, wc~levels) ; clear node marks() ; } /* Renvoi de VRAI si ce noeud peut être déterminé comme étant le noeud de réaction d'une structure de circuit de verrouillage. */ int NIsFeedBack(node) node pr node ; { elem pr elem ; int n~feedback = FALSE, p~feedback = FALSE ; if (!NIsLatch(node)) return FALSE ; for~gate~elems(elem, node) { if(EIsFeedback(elem)) if (ETypeIsN(elem)) n~feedback = TRUE ; if (ETypeIsP(elem)) p~feedback = TRUE ; } end~gate~elems if (n~feedback && p~feedback) return TRUE ; else return FALSE ; } /* Ecrire un dossier avec 3 circuits pour chaque noeud de circuit de verrouillage. C'est le sous-programme à niveau supérieur pour créer les dossiers de contrôle de circuits de verrouillage. */ check~latch~node(node)
node~pr node ; { FILE *MYDECK ; elem~pr pullup~npass~fets[NUM~PASSCKT~FETS], pullup~ppass~fets[NUM~PASSCKT~FETS] ; elem~pr pulldown~npass~fets[NUM~PASSCKT~FETS], pulldown~ppass fets[NUM~PASSCKT~FETS] ; elem~pr elem; node~pr pdriver~node = NULL, ndriver~node = NULL ; double m~w[NUM~CKLATCH~FETS], m~1[NUM~CKLATCH~FETS] ; int i, lmodel[NUM~CKLATCH~FETS] ; int pullup~levels = 0, pulldown~levels = 0 ; charmessage[MAXSTRING]; /* Sauter ce noeud si c'est la sortie de l'inverseur à action directe. */ if (NIsFeedBack(node)) return ; for (i = 0 ; pullup~ppass-fets[i] = pulldown~npass~fets[i] = pulldown ppass-fets[i] = NULL ; } /* Détermination des largeurs et des longueurs des transistors FET pour ce noeud */ if (find~checklatch~latchfets(node, &m~w[0], &m~l[0])) return ; find~checklatch~driver(node, &pdriver~node, PTYPE, &m~w[6], pullup~ppass~fets, pullup~npass~fets, &pullup~levels) ; find~checklatch~driver(node, &ndriver~node, NTYPE, &m~w[5], pulldown~ppass~fets, pulldown~npass~fets, &pulldown~levels) ; if (!pdriver~node p !ndriver~node) return ; /* Les transistors NFET sont présents en un nombre impair et les transistors PFET sont présents en des nombres pairs. */ for (i = 1 ; CheckLatchLongNLength~ReqERC ? TRUE : FALSE ; for (i = 2 ; CheckLatchLongPLength~ReqERC ? TRUE : FALSE ; MYDECK = start~deck(CHECKLATCH~SIM, node); declare~passfet~ckt(MYDECK, "pulldown~passfet~ckt", pulldown~ppass~fets, pulldown~npass~fets ) ; declare~passfet~ckt (MYDECK, "pullup~passfet~ckt", pullup~ppass~fets, pullup~npass~fets ) ; declare~vth~ckt(MYDECK, lmodel) ; declare~set0~ckt(MYDECK, lmodel) ; declare~setl~ckt(MYDECK, lmodel) ; add~checklatch~comments~to deck(MYDECK, pulldown~ppass~fets, pulldown~npass~fets, pullup~ppass~fets, pullup~npass~fets, ndriver~node, pdriver~node) ; /* Insérer un message concernant le nombre total de niveaux */ if ((pullup~levels ≥ NUM~PASSCKT~FETS) Il (pulldown~levels ≥ NUM~PASSCKT~FETS)) { sprintf(message,"Erreur Modèle : Total de transistors FET de transfert abaisseurs %d Total de transistors FET de transfert élévateurs %d Limite du modèle %d", pullup~levels, pulldown~levels, NUM~PASSCKT~FETS -1) ; add~comment~to~deck(MYDECK, message) ; } add~ckt~header~to~deck(MYDECK, "cktl", CHECKLATCH~QUERY) ;
fprintf(MYDECK,"Vl 100 0 dc=%. 4e \n", CheckLatchSupplyVoltage~ReqERC); add~vth~ckt~to~deck(MYDECK, m~w, m~1) ; add~set0~ckt~to~deck(MYDECK, m~w, m~1) ; add~setl~ckt~to~deck(MYDECK, m~w, m~1) ; end~deck (MYDECK); }
La présente invention concerne un système accueil téléphonique de correspondants en cas d'indisponibilité un souscripteur.
) Lorsque le dispositif d'adaptation 10 est mis en place sur la deuxième région II de la
tion représentée en FI,', comme on l'a représenté sur la Figure 5B.
- 1- On a donc bien réalisé la modification de la géométrie du faisceau lumineux imposée par le changement du sens du trafic avec des moyens aussi simples à mettre en oeuvre et aussi peu onéreux que le cache vacancier décrit plus haut, tout en conservant l'intégralité du flux
) Bien entendu, la partie sensiblement prismatique du dispositif d'adaptation 10 peut être constituée d'un prisme proprement dit, comme on l'a représenté suI la Figure 4, ou elle peut être constituée par un prisme de Fresnel, comme on l'a représenté sur la Figure 6. Dans un tel prisme de Fresnel, au moins l'une des faces, par exemple la face 12, est discontinue et formée
Io sente ainsi comme un empilement de prismes élémentaires, de même angle au sommet ou ayant des angles au sommet voisins, et par exemple évoluant d'un angle au suivant d'un même incrément. Les stries horizontales 16 formées sur la face 12 du dispositif d'adaptation peuvent avoir un profil sensiblement triangulaire, ainsi qu'on l'a représenté sur la Figure 7A,
On peut encore améliorer le faisceau obtenu à l'aide du dispositif d'adaptation qui vient d'être décrit. En effet, on voit sur la Figure 5B que le faisceau lumineux comporte un endroit recevant à la fois les parties FI et FI,', cette superposition pouvant être nuisible à
lement les rayons lumineux traversant la deuxième région Il de la surface de la glace de pro-
Le filet selon ce brevet US 4 549 754 présente en coupe un fond qui n'est pas symétrique mais qui comporte un arrondi dont le centre est décalé vers le flanc d'engagement (opposé au flanc porteur) et dont le rayon est augmenté d'environ 50% par rapport au rayon API et vaut 1,45 mm (0,057").
Cet arrondi se raccorde tangentiellement au flanc porteur alors qu'il se raccorde par un profil moins critique avec le flanc d'engagement : simple segment de droite ou rayon de ,81 mm (0,032") suivi d'un segment de droite.
Le fond du filet est alors davantage creusé que dans un filet API et nécessite donc une très grande épaisseur de tube de départ pour tailler les filets.
Une telle disposition n'est pas envisageable pour les colonnes de tubes destinées à l'exploitation des puits lorsque celles-ci sont soumises à la fois à des sollicitations statiques et dynamiques.
On rencontre maintenant de telles exigences de tenue aux sollicitations dans les colonnes sous-marines reliant le fond de la mer aux plates-formes d'exploitation mer des hydrocarbures.
De telles colonnes de tubes dits "risers" dans le langage anglo-saxon de l'homme métier sont en effet soumises aux sollicitations cycliques causées notamment par courants qui induisent des mises en vibration de la colonne, par la houle, par marées et le déplacement éventuel des plates-formes elles-mêmes.
On rencontre également de telles exigences de tenue aux sollicitations dans des puits terrestres, notamment lors de la descente en rotation de tubes pour cimenter les puits dans le cas très fréquent de puits déviés de la verticale présentant des coudes. C'est pourquoi on a cherché à améliorer les joints filetés tubulaires . pour tubes de cuvelage, de production ou pour "risers" de manière à augmenter leur résistance à la fatigue.
La demande de brevet WO 98I50 720 décrit un tel joint fileté tubulaire amélioré.
Les filetages décrits dans ce document possèdent des filets trapézoïdaux dérivés des filets dits "buttress" de la spécification API 5B.
La forme trapézoïdale des filets limite le risque de déformation des eléments filetés susceptible de conduire à leur déboîtement lors du vissage notamment par survissage. Les fonds de filets sont substantiellement rectilignes et se raccordent à chacun des flancs par un arrondi dont le rayon est compris entre 10 et 50% de la largeur totale du fond de filet (et préférentiellement entre 16 et 26% de cette largeur totale), l'arrondi se terminant tangentiellement au flanc et au fond de filet.
Les hauteurs des filets sont telles qu'on évite toute interférence radiale entre fond de sommet d'un filetage et sommet de filet correspondant du filetage conjugué en maintenant entre eux un jeu radial d'au moins 0,25 mm (0,010").
Compte tenu des filetages donnés en exemple, les arrondis en fond filet sont de l'ordre de 0,5 mm contre 0,15 mm pour les rayons spécifiés par l'API De tels rayons peuvent sembler faibles si on les compare à ceux tiges de forage mais la forme trapézoïdale des filets mis en oeuvre ne permet pas de réaliser d'aussi grands rayons que dans le cas des filets triangulaires à moins d'accepter de réduire de manière rédhibitoire la surface portante des flancs en contact.
filetages selon ce document WO 98l50 720 ne sont en outre pas adaptés à des filets dits interférents qui présentent une interférence radiale entre sommets de filet filetage et fonds de filet correspondant du filetage conjugué. Les filets présentés sont du type coin à largeur variable comme ceux décrits dans le brevet Re 30 647. On a cherche dans la présente invention à réaliser un élément fileté tubulaire mâle femelle pour joints filetés tubulaires, qui soit particulièrement résistant à la fois a) aux sollicitations statiques, notamment de traction axiale, de compression axiale, flexion, de torsion, de pression intérieure ou extérieure, de déboîtement lors vissage, simples ou combinées (par exemple traction + pression intérieure) ; b) aux sollicitations cycliques.
On a désigné un tel élément fileté dans la suite du présent document comme possédant profil anti-fatigue.
On a aussi cherché à ce que l'élément fileté tubulaire selon l'invention puisse être réalisé avec toutes sortes de filetages, coniques, cylindriques, combinés cylindro- coniques, a ou plusieurs étages, à filets trapézoïdaux ou triangulaires, interférents ou non interférents ; les filetages non interférents pourront par exemple être du type décrit dans demande EP 454 147 à contact simultané des deux flancs avec ceux du filet conjugue (dits encore "rugged thread"), à frettage axial ou de type coin à largeur variable comme décrit par exemple dans le brevet US Re 30 647.
On a en outre cherché à ce que l'élément fileté puisse être facilement réalisé et facilement contrôlé.
Présence d'anticorps (Ac) anti IL10 de type IgG et de type IgA dans le sérum Expérience de vaccination 2 : Vaccination anti-VEGF de la souris par l'induction d'une immunité systémique et mucosale avec formation préférentielle d'anticorps spécifique de classe IgG et IgA.
Protocole d'immunisation Jour 0 : Injection IM d'une suspension d'immunogène VEGF (20 g) dans l'ISA 51 préparée à l'exemple 1.
Jour 7, jour 14, jour 21 :Administration intranasale à l'aide de pipette Hamilton de 10 l d'une suspension aqueuse contenant 20 g d'immunogène et 5 g de LT enchâssés dans un gel de phosphate de calcium.
Les souris contrôles reçoivent les mêmes préparations sans immunogène Suivi : On sacrifie les animaux 15 jours après la dernière immunisation et on constate l'absence de toxicité (mesurée par l'absence de signes cliniques (comportement ; poils ; poids) et par examen anatomique après autopsie.
Réaction immunitaire testée par la présence dans le sérum d'anticorps de type IgG et IgA , mesurée par ELISA et exprimée par la densité optique 15 jours après la dernière instillation.
Souris contrôle (D.O) Souris immunisées (D.O) Ac anti VEGF classe IgG 0,27 1,64 Ac anti VEGF classe IgA 0,15 1,118 @
Résultats : Innocuité clinique et absence de lésions anatomiques.
Présence d'anticorps anti VEGF de type IgG et de type IgA dans le sérum.
Expérience de vaccination 3 : Vaccination anti p53 de la souris par l'induction d'une immunité systémique et mucosale avec formation préférentielle d'anticorps spécifique de classe IgG et IgA Protocole d'immunisation Jour 0 : Injection IM d'une suspension d'immunogène p53 (20 g) dans l'ISA 51 préparée comme à l'exemple 1.
Jour 7, jour 14, jour 21 : Administration intra nasale à l'aide de pipette Hamilton de 10 l d'une suspension aqueuse contenant 20 g d'immunogène et 5 g de LT enchâssés dans un gel de phosphate de calcium.
Les souris contrôles reçoivent les mêmes préparations sans immunogène Suivi : On sacrifie les animaux 15 jours après la dernière immunisation et on constate l'absence de toxicité (mesurée par l'absence de signes cliniques (comportement ; poils poids) et par examen anatomique après autopsie.
Réaction immunitaire testée par la présence dans le sérum et dans la salive d'anticorps de type IgG et IgA , mesurée par ELISA et exprimée par la densité optique 15 jours après la dernière instillation.
Innocuité clinique et absence de lésions anatomiques.
Présence d'anticorps anti p53 de type IgG et de type IgA dans le sérum et dans la salive.
sérum Souris contrôle (D.O) Souris immunisées (D.O) @ Ac anti p53 classe IgG 0,184 1,492 ! Ac anti p53 classe IgA 0,208 1,071 salive Souris contrôle (D.O) Souris immunisées (D.O) Ac anti p53 classe IgG 0,184 1,5 Ac anti p53 classe IgA 0,208 0,980
Une troisième série (206) de boutons permet de provoquer l'affichage d'écran permettant de consulter les paramètres de fonctionnement du juke-box. Chaque bouton (206.1 à 206.7) correspond en fait à l'affichage des paramètres identifiés dans chaque table des groupes de tables JUK PASSWORD, TUNE COST, JUK REMOTE CONTROL, JUK MIXAGE, JUK ISP CREDIT, JUK OTHER SETTING, fig. 3A et 3C, dont l'argument identifiant le juke-box correspond à l'identifiant affiché dans le premier zone (201.1) d'affichage du premier écran (200, fig. 5A). Ainsi, la sélection d'un boutons (206.1 à 206.7) déclenche dans un premier temps une collecte d'informations dans le groupe de tables JUK AAA correspondant au bouton, pour trouver la table dont le numéro d'identifiant de juke-box correspond au numéro souhaité. Puis une collecte d'information dans la table IB AAA groupe de table associé à la table JUK AAA est réalisée pour déterminer valeur des paramètres correspondant à l'identifiant du jeu de paramètre trouvé dans la table du groupe de tables JUK AAA. A titre d'exemple non limitatif la selection d'un premier bouton (206.1) de sélection de la troisième série declenche une collecte d'informations dans les tableaux JUK MIXAGE, fig. 3A IB MIXAGE, fig. 3A pour afficher dans un troisième écran (220) paramètres de réglage du son sur le juke-box choisi dans le premier écran. troisième écran (220) est uniquement destiné à la consultation, il ne comprend pas de zone de saisie. Les différents paramètres de volume maximum (221.4) volume (221.1), basse (221.2), aiguë (221.3), pour la voie de droite et la voie de gauche réglage du son pour chaque zone (221 a, 221 b) sont affichés dans des zones (221) d'affichage. Des zones d'affichage permettent de visualiser les paramètres de volume pour chacun des dispositifs suivants, un microphone (222.1), une source auxiliaire (222.2), une musique de fond (222.3).
Une quatrième série (207) du boutons de sélection permet l'affichage d'écran permettant de gérer les juke-box et notamment les communications entre le serveur et les juke-box. Un premier bouton (207.1) provoque la collecte d'informations par le serveur dans les groupes de tables INSTRUCTION, fig. 3F, INSTRUCTION DEF, et INS XXX, pour afficher dans un quatrième écran (230) la liste des instructions qui doivent être envoyées vers le juke-box selectionné dans le premier écran (200), et affiché dans une première zone (234) d'affichage. Ce quatrième écran (230) comprend donc une zone (231) qui permet à la fois de visualiser les instructions déjà prévues, ou de modifier ces instructions ou encore d'ajouter de nouvelles instructions. Le quatrième écran (230) comprend un bouton de sauvegarde (232) permettant de valider les instructions saisies ou modifiées dans la zone (231) de saisie jusqu'à la date d'envoi déterminée. Cette validation provoque également la mise à jour des groupes de tables INSTRUCTION, INSTRUCTION_DEF, et INS XXX.
Un deuxième bouton (207.2) provoque, après collecte d'informations dans le groupe de tables PLAY LOG, fig. 3A, l'affichage d'un écran visualisant, exemple l'historique de toutes les chansons jouées sur le juke-box identifié le numéro d'identifiant affiché dans la première zone (201.1) du premier ecran (200). Un troisième bouton (207.3) provoque, après collecte d'informations dans le groupe de tables SYSTEM LOG, fig. 3A, l'affichage d'un écran visualisant, par exemple l'historique de toutes les actions exécutées sur le juke-box identifié par le numéro d'identifiant affiché dans la première zone (201.1) du premier écran (200). Ces actions sont, par exemple, l'introduction successive d'une somme d'argent dans le monnayeur du juke-box.
quatrième bouton (207.4) provoque, après collecte d'informations dans groupe de tables COMMAND, l'affichage d'un écran visualisant, par exemple l'historique de toutes les commandes qui vont être exécutées sur le juke- identifié par le numéro d'identifiant affiché dans la première zone (201 du premier écran (200). Un cinquième bouton (207.5) provoque, après collecte d'informations dans un groupe de tables JUK CONNECTION, l'affichage écran visualisant, toutes les connexions établies entre le serveur et le juke- identifié par le numéro d'identifiant affiché dans la première zone (201.1 premier écran (200) lors de la connexion de ce dernier avec le serveur. sixième bouton (207.6) provoque, après collecte d'informations dans le groupe de tables LOG_RECEPTION, fig. 3E, l'affichage d'un écran visualisant l'historique de tous les fichier de compte rendu reçus par le serveur et envoyés par le juke-box identifié par le numéro d'identifiant affiché dans la première zone (201.1) du premier écran (200). Un septième bouton (207.7) provoque, après collecte d'informations dans le groupe de tables EXECUTED INSTRUCTION, fig. 3F, l'affichage d'un écran visualisant, l'historique toutes les instructions exécutées sur le juke-box identifié par le numéro d'identifiant affiché dans la première zone (201.1) du premier écran (200).
Un cinquième écran (240) permet de maintenir à jour la banque de chansons contenue dans la base de données. Cet écran (240) permet notamment d'ajouter des albums ou de modifier les données de la banque de chansons, notamment lorsque les droits de diffusion sont obtenus et/ou lorsque les chansons sont traitées pour être téléchargées sur les juke-box.
cinquième écran (240) comprend donc essentiellement des zones (241 à 241.4) de saisie permettant d'indiquer toutes les informations sur les albums. Chaque zone (241) de saisie correspond à un argument du tableau ALBUM, fig. 3A de base de données. Une première zone (241.1) contient l'identifiant de l'album. Une deuxième zone (241.2) contient le nom de l'album. troisième zone (241.3) contient le nom de l'artiste interprète de l'album. quatrième zone (241.4) contient le nom de la maison de disques. Le cinquieme écran (240) comprend également une fenêtre (243) déroulante permettant d'afficher liste des chansons de l'album identifié par son identifiant. Ainsi, la validation la saisie par une sélection d'une première zone (242) de sélection déclenche mise à jour par le serveur du tableau ALBUM, fig. 3A qui, soit modifie les arguments correspondants si la saisie consiste en une modification d'un album existant, soit ajoute une table dans le groupe de tables lorsque la saisie correspond à l'ajout d'un nouvel album dans la banque de chansons.
sixième écran (250) permet d'établir des listes de chansons (master). listes peuvent ensuite être utilisées pour servir de point de départ pour l'initialisation de la liste de chansons disponibles sur un juke-box. Le sixième écran comprend une pluralité de zone de saisie permettant d'identifier la liste (251.1), par exemple, de décrire succinctement la liste (251.2) et de définir le type de liste (251.3) , c'est-à-dire s'il s'agit d'une liste en cours de réalisation ou d'une liste définitive. Chaque zone de saisie (251.1 à 251 correspond en fait à un argument du tableau MASTER, fig. 3B. Le sixième écran (250) comprend également une première fenêtre (252) déroulante comprenant la liste des chansons de la banque de chansons et une deuxième fenêtre (253) comprenant la liste des chansons déjà sélectionnées pour faire partie de la liste en cours. Le sixième écran (250) comprend également bouton (254) de sauvegarde permettant de valider la liste établie. Cette sélection provoque soit la création d'une table dans le groupe de tables spécifiques MASTER, fig. 3B et la création pour chaque chanson de la nouvelle liste d'une table dans le groupe de tables spécifiques MASTER CATALOGUE fig. 3B, s'il s'agit d'une nouvelle liste, soit provoque l'ajout ou la suppression d'une table dans le groupe de tables spécifiques MASTER CATALOGUE, fig. 3B s'il s'agit de la mise à jour d'une liste existante.
Un septième tableau (260) permet de visualiser toutes les rangées tableau PUBLISHER. Cette collecte particulière d'information est réalisée par serveur et permet de gérer les droits d'auteur associés à chaque éditeur. Pour ce faire, le septième écran (260) comprend une fenêtre déroulante (261) constituée d'une pluralité de lignes. Chaque ligne comprend un premier champ (261.1) représentant l'identifiant de l'artiste, un deuxième champ (261.2) représentant le nom de l'artiste, c' -à-dire dans ce cas le nom de la compagnie d'édition, un troisième champ (261.3) représentant le nom de l'administrateur de la compagnie d'édition, un quatrième champ (261.4) permettant de savoir si l'éditeur est dans le catalogue, et une série de champs (261.5à 261.9) permettant de déterminer si l'éditeur accorde ou non les droits de reproduction et de diffusion. Ainsi, un premier champ (261.5) indique à quelle date l'autorisation écrite de diffusion a été accordée. Un deuxième champ (261.6) indique depuis quelle date la signature pour autorisation est en attente. Un troisième champ (261.7) indique depuis quelle date le contrat relatif à l'accord sur la diffusion des champs est en attente de commentaires. Un quatrième champ (261.8) indique à quelle date un accord verbal a été obtenu. Un cinquième champ (261.9) indique depuis quelle date il n'y a plus d'accord de diffusion.