INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Les sites ont été préalablement triés et affectés d'étiquettes (ou tags en terminologie anglo-saxonne)
pour constituer de ce fait une liste stockée dans un premier fichier.
Supposons maintenant que le lien de composition entre G et 1 soit rompu, et remplacé par un lien entre H et 1, comme le montre la figure 187.
Pour chaque site SITETAG ayant un custom tag Ordre = ordre associé à ce site pour cette catégorie Pour chaque ligne de résultat renvoyée par SITETAG Insérer dans le tableau de résultat les colonnes Clé,ordre,ListeChamps,SITETAG Fin Pour Fin Pour Transformation des données en requêtes La transformation du tableau de résultat avec la première méthode utilise le code indiqué en annexe 2.
Pour rendre ce code indépendant de la catégorie, la seconde méthode propose l'algorithme suivant : consolida tion=QueryNew ("Si te, cle" & ListeChamps) Pour chaque ligne LIGNETABLEAU du tableau de résultats Créer une nouvelle ligne dans la requête de consolidation Dans la première colonne de la requête, insérer la colonne site de LIGNETABLEAU Dans la seconde colonne de la requête, insérer la colonne cle de LIGNETABLEAU
Pour chaque ELEMENT de ListeChamps Insérer la colonne ELEMENT dans la colonne correspondante de LIGNETABLEAU Fin Pour Fin Pour Envoi des paramètres à la page de comparaison des prix via XML Cela se fait par la fonction javascript envoi.
Utilisation du XML : OUTPUT="wresul tat-requete'r> permet de transformer du code cfml en code xml qui reçoit le contenu de la requête " consolidation " et renvoit une chaîne de caractères en xml contenant tous les résultats de la requête. On insère cette chaîne dans la table resultatxml de la BDD. On passe ensuite l'ID du contenu inséré dans le form afin de récupérer les données dans la page de comparaison.
Affichage des informations Avec la seconde méthode, la consolidation se fait désormais sur le champ CLE et non plus sur le champ ISBN.
Pour chaque catégorie de produit, seules certaines informations sont alors affichées sur la page de consolidation : ce sont celles dont le METACHAMP correspondant possède une propriété METACHAMP~ordreCons strictement supérieure à 0.
Certains champs sont aussi affichés en entête du tableau.
L'algorithme d'affichage est donc par exemple le suivant : Pour tout les METACHAMP dont METACHAMP ordreCons > 0 Récupérer le nom du champ NOMMETACHAMP, la valeur LARGEURMETACHAMP correspondant au champ METACHAMP~largeurCons et le champ METACHAMP~enteteCons Pour tout les METACHAMP dont METACHAMP~enteteCons > 0 Créer une colonne de tableau HTML dont l'intitulé est NOMMETACHAMP et la largeur LARGEURMETACHAMP Fin Pour Fin Pour Pour chaque ligne LALIGNE de la requête consolidation //lère ligne Pour tout les METACHAMP dont METACHAMP~ordreCons > 0 et METACHAMP enteteCons >0 Créer une colonne de tableau HTML dont le contenu est la colonne correspondante de LALIGNE et de largeur LARGEURMETACHAMP Fin Pour //2nde ligne Pour tout les METACHAMP dont METACHAMP~ordreCons > 0 et METACHAMP~enteteCons =0 Afficher l'intitulé NOMMETACHAMP et le contenu qui est la colonne correspondante de LALIGNE Fin Pour Fin Pour La page de comparaison (annuaire/comparaison.cfm) peut quant à elle être décrite comme suit :
Récupération des données du XML On récupère l'ensemble des informations contenues dans la table Resultatxml grâce au champ Id passé en hidden dans le form précédent.
On fait le traitement inverse à celui effectué dans consolidation.cfm On récupère ainsi la requête " consolidation avec toutes les infos. Pour isoler le produit en question, il suffit de vérifier si le champ " cle" de la requête consolidation correspond bien au champ " cle passé en url via la fonction javascript envoi () Enfin la fiche descriptive du produit s'obtient de la façon suivante On a récupéré au préalable le champ MetaCat-fiche-custom et MetaCat-Id grâce au paramètre " cat " passé en url.
Si le champ est nul, on inclut la fiche générique " annuaire/fiche~custom/fiche~generique.cfm " du produit qui ne présente aucune particularité ( en boucle, les intitulés et contenus des champs sont affichés ligne par ligne ). Si le champ web~photo du webmarchand est non nul, on place la photo s'il elle existe sur la droite de la fiche.
Si le champ est non nul, on inclut la fiche customisée nommée " fiche#MetaCat-Id# " où les champs peuvent être disposés d'une manière spécifique selon la catégorie.
Comme il va de soi et comme il résulte de ce qui précède la présente invention n'est pas limitée au mode de réalisation plus particulièrement décrit.
Elle en autorise au contraire toutes les variantes et notamment celles où les moyens d'interrogation sont vocaux et le dispositif est un téléphone mobile.
ANNEXE 1 select cw.ordre from categorie~webmarchand as cw, webmarchand as w where w.web tag = '#inde#' and cw.web~id = w.web~id
ANNEXE 2 QuerySetCell (consolidation, "Auteur", ListGetAt (resul tat~tab [ind] , 4, ", ") )> QuerySetCeII(consolidation,"Edition ListGetAt(resultat tab(indJ,5,"," " ))> QuerySetCell (consolidation, "prix" , ListGetAt (resultat~tab[ind], 6,","))
N-1. Agencement du dispositif La figure 55 représente un agencement d'un dispo sitif à semiconducteurs 5000 conformément à une quatorzième forme de réalisation préférée de la présente invention.
Sur la figure 55, la partie de circuit HF est représentée comme étant disposée sur un substrat SOI SBA incluant le substrat en silicium 1, un film d'oxyde ense- veli 2A disposé sur le substrat en silicium 1 et une couche SOI 3A disposée sur le film d'oxyde enseveli 2A.
L'écran PG 105 comprenant les régions SOI 251 à 257 disposées selon une relation de contact intime est formé dans la couche SOI 3A dans une relation de correspon dance avec la région dans laquelle est prévue l'inductance en spirale SI (dont la configuration dans le plan est représentée sur la figure 70). L'écran PG 105 de la figure 55 a un agencement similaire à celui du dispositif à semi conducteurs 5000 décrit en référence à la figure 18. L'écran PG 105 comporte en outre des régions SOI 258 et 259 non représentées.
La surface supérieure de l'écran PG 105 est recouverte par le film d'oxyde d'isolation 17 placé dans un sillon, qui est parallèle au film d'oxyde d'isolation par tielle.
Un transistor MOS Q40 est formé en position adja cente au film d'oxyde d'isolation 17 placé dans un sillon. Le transistor MOS Q40 possède un film isolant de grille GZ disposé sur une région SOI définie par le film d'oxyde d'isolation 17 placé dans un sillon, une électrode de grille GT disposée sur le film d'isolation de grille GZ, un film de siliciure GS disposé sur l'électrode de grille GT et des films d'isolation de parois latérales GW1 et GW2 disposés de manière à recouvrir les surfaces latérales du film d'isolation de grille GZ, l'électrode de grille GT et le film de siliciure GS.
Une région de source/drain SD2 située du même côté que le film d'isolation de paroi latérale GW2 possède une largeur supérieure à celle d'une région de source/drain SD1 située sur le côté opposé. Le film d'isolation de paroi latérale GW2 s'étend sur la région de source/drain SD2.
Un film de siliciure SS1 est disposé dans la sur face de la région de source/drain SD1 à l'extérieur du film d'isolation de paroi latérale GW1, et un film de siliciure SS2 est disposé dans la surface de la région de source/drain SD2 à l'extérieur du film d'isolation de paroi latérale GW2. Ceci conduit au fait que l'électrode de grille GT est décalée vers la région de source/drain SD1, ce qui est connu sous l'expression grille décalée. La grille décalée, qui peut réduire la concentration du champ électrique dans la région de drain pour accroitre la ten sion de claquage du transistor MOS, est une structure appropriée pour des dispositifs à semiconducteurs.
Les films de siliciure SS1 et SS2 sont connectés par les parties de contact CP5 et CP6 de manière à recou vrir respectivement des lignes d'interconnexion WL5 et WL6.
Les constituants du dispositif à semiconducteurs 5000, qui sont similaires à ceux du dispositif à semicon ducteurs 500 de la figure 18, sont désignés par les mêmes chiffres de référence et on n'en donnera pas une descrip tion de façon particulière.
Une couche poreuse PR3 est disposée sur la couche SOI 3A représentée sur la figure 55.
La couche poreuse PR3 comprend une pluralité de trous formés au moyen du processus d'anodisation et s'éten dant à partir de la surface du substrat en silicium 1, à l'intérieur de ce dernier. Les trous sont remplis par un état de quasi-vide ou par un isolant.
Cette interruption du trajet du courant de Fou cault produit par l'inductance en spirale SI sert à réduire la dissipation de puissance induite par voie électromagné tique dans le substrat SOI 3A.
N-2. Procédé de fabrication En référence aux figures 56 à 59, on va décrire un procédé de formation du substrat SOI SBA incluant la couche SOI et la couche poreuse PR3 formée dans la couche.
Un procédé de formation d'un substrat SOI incluant une couche SOI dans laquelle est formée une couche poreuse, est décrit dans les figures 1 à 9 de la demande de brevet japonais N 11-165951 (1999).
On va décrire le procédé sur la base de la des cription donnée précédemment. Tout d'abord, lors de l'étape illustrée sur la figure 56, on forme la couche poreuse PR3 ayant une épaisseur d'environ 1 gm dans une surface princi pale d'un substrat en silicium 1D, au moyen du procédé d'anodisation. Après formation de la couche poreuse PR3, on peut naturellement appliquer un traitement thermique à une température de 1000 C ou plus dans une atmosphère d'hydrogène pendant quelques secondes, comme décrit précé demment, de manière à supprimer l'ouverture des trous res pectifs par réduction, ce qui permet d'obtenir des cavités situées à l'intérieur des trous respectifs et de lisser la surface supérieure de la couche poreuse PR3.
On peut former une pluralité de sillons (ou de trous) par attaque chimique au lieu d'utiliser le procédé d'anodisation, pour former la couche poreuse PR3.
La zone Z11est une zone qui n'est jamais couverte par la page PIdu plan supérieur. La zone Z11 contient donc en permanence la partie correspondante de la page P2 du plan inférieur.
Et lorsque la page P1du plan supérieur est décalée (situation de la figure 15), la zone Z12 présente la partie correspondante de la page P2 du plan inférieur, cette page occupant alors la somme des zones Z11et Z 12.
Dans l'exemple de la figure 20, les régions grisées (ici les zones Z12 et Z13) désignent des endroits où la présence du pointeur n'a pas d'effet sur le système, tandis que les régions blanches (ici les zones Z1 1 et Z14) désignent des régions pour lesquelles l'entrée du pointeur dans l'une de celles-ci provoque une action, comme on le détaillera plus loin.
Le mode de collecte est modélisé par une classe WayToComputePerf qui possède l'attribut dataFlow désignant un sens de
flux de données conformément au type d'énumération FlowEnum. Comme pour un indicateur QoS 103, le calcul d'un indicateur de performance peut être fait dans les deux sens de flux de données de l'équipement et de manière différente selon le sens. Si l'indicateur est de type calculé, la classe WayToComputePerf peut être associée à la classe Computation qui définit une règle de calcul/récupération de l'indicateur par outil de collecte.
Comme décrit précédemment, cette règle de calcul peut prendre optionnellement en paramètres d'autres indicateurs de performance PerformanceIndicator dans le cas où l'indicateur de performance décrit est lui-même composé d'autres indicateurs. Si l'indicateur est de type basique, il n'a pas de règle de calcul/récupération mais il possède un point de mesure théorique défini par une classe TheoreticalMeasurementPoint associée à la classe WayToComputePerf et sur lequel on pourra obtenir sa valeur. La classe TheoreticalMeasurementPoint décrit le point de mesure théorique d'un indicateur de performance de type basique. Il n'y a qu'un seul et unique point de mesure pour un indicateur. Si l'indicateur est de type calculé, il n'a pas de point de mesure associé. La classe possède un attribut point désignant le point de mesure théorique conformément au type TheoreticalPointEnum.
L'annexe 3 illustre le fichier XML correspondant à la grammaire DTD du modèle SLA qui vient d'être décrite dans le langage UMK lors de l'étape S2 du procédé représenté sur la figure 4. Les mêmes règles de traduction définies pour la grammaire du modèle de service ont été appliquées pour ce fichier. L'annexe 4 illustre un exemple de modèle SLA 90 obtenu de l'étape S5 et conforme à la grammaire DTD décrite dans l'annexe 3.
Le modèle SLA 90 illustré s'applique à la technologie à relais de trame (Frame Relay) d'un opérateur nommé op pour un contrat de niveau nommé siluer.
La figure 9 illustre la structure d'un modèle 110 de description d'au moins un outil SLA 120, qui utilise lors de l'étape S3 du procédé la grammaire d'un modèle de description d'outils SLA. Un modèle 110 de description d'outils SLA définit, pour une technologie donnée et un
équipement donné, des outils 120 nécessaires à la mesure de la qualité de service décrite dans un modèle SLA et s'appuyant sur un modèle 80 de service donné. Le modèle 110 illustré de description d'outils SLA est décrit par la classe SlaToolsPackage qui possède les attributs : # version désignant la version du modèle d 'outils SLA ; # serviceType désignant le type de service auquel est associé le modèle 110 de description d'outils SLA ; # manufacturer désignant le nom du constructeur de l'équipement (un routeur par exemple) supporté par ce modèle d'outils SLA ; # equipment désignant le nom de l'équipement supporté par ce modèle d'outils SLA ; et # equipmentVersion désignant la version de l'équipement supporté par ce modèle d'outils SLA.
La classe SlaToolsPackage peut contenir, comme illustré : # au moins un mode de collecte utilisable pour le modèle SLA, en l'occurrence : # un mode de collecte par agent représenté par une classe AgentData, dont les données proviennent d'un agent 18 ; # un mode de collecte par journal représenté par une classe LogData, dont les données proviennent d'un journal 20,22, 67 ; # un mode de collecte par alarmes représenté par la classe AlarmData, dont les données proviennent d'alarmes filtrées enregistrées dans le journal 65 ; et,en option, # un mode de collecte par application tierce (autre que OpenMaster dans l'exemple illustré), représenté par la classe ApplData et dont les données proviennent de l'application tierce ;et # au moins une description de configuration d'application, autre que les outils de collecte et utile pour la mesure de qualité de service, et représentée par la classe ConfigData.
La classe AgentData représente le mode de collecte par agent 18 d'un outil. Elle possède l'attribut toolName désignant le nom de l'agent
18. Elle décrit en option des informations de configuration nécessaires à cet outil, telles que celles représentées par la classe Mib illustrée dans la figure 4 et concernant les modules de base Mib supportés par l'agent et ceux définis pour les types de composant du modèle de service correspondant, et celles représentées par la classe File illustrée dans la figure 4 et contenant les fichiers d'installation automatique et les fichiers de collecte, dans les journaux 20,22 et 67, d'indicateurs à installer et, de préférence, le ou les fichiers de configuration spécifiques à l'agent.
La classe LogData représente le mode de collecte par journal 20,22, 67 d'un outil. Elle décrit en option des informations de configuration nécessaires à cet outil, telles que celles relatives à la classe AgentData et contenues dans les classes Mib et File. La classe LogData possède les attributs : # toolName désignant le nom de l'outil de collecte par journal ; # logName désignant le nom du journal 20,22, 67 d'indicateurs collectés par l'outil désigné par toolName ; # logDir désignant le répertoire où doit être installé le journal désigné par logName ; # namingRule désignant la règle de nommage des instances dans le journal désigné par logName ; et # repatriationMode désignant le mode de rapatriement du journal désigné par logName.
La classe AlarmData représente le mode de collecte par alarmes d'un outil. Elle possède l'attribut toolName désignant le nom de l'outil collectant les alarmes, par exemple l'outil 64. Elle décrit en option des informations de configuration nécessaires à l'outil, telles que celles relatives à la classe AgentData et contenues dans les classes Mib et File.
La classe ApplData représente le mode de collecte par une application tierce. Elle possède l'attribut toolName désignant le nom de l'application tierce et décrit en option les informations de configuration nécessaires à cet outil, telles que celles relatives à la classe AgentData et contenues dans les classes Mib et File.
La classe ConfigData représente la description de la configuration d'une application, hors outil de collecte, à configurer pour la mise en #uvre de la mesure de la qualité. L'application à configurer peut être en l'occurrence une application 42 d'OpenMaster ou une application tierce. La classe ConfigData possède l'attribut toolName désignant le nom de l'application à configurer et contient en option les fichiers nécessaires à la configuration ou à l'installation automatique de l'application.
L'annexe 5 illustre le fichier XML correspondant à la grammaire du modèle de description d'outils SLA qui vient d'être spécifiée dans le langage UML lors de l'étape S3 du procédé. Les mêmes règles de traduction définies pour la grammaire du modèle de service et la grammaire du modèle SLA ont été appliquées pour ce fichier. L'annexe 6 illustre un exemple de modèle 110 de description d'outils SLA obtenu de l'étape S6 et conforme à la grammaire DTD décrite dans le fichier de l'annexe 5.
On peut constater que les grammaires actuelles référencent des fichiers de collecte et des fichiers de modèles de rapports. Ces fichiers sont actuellement externes et suivent un format de texte (ascii) spécifique à l'offre Report du produit OpenMaster@ du demandeur. La spécification d'une grammaire DTD pour ces modèles est envisageable. Il sera alors possible de référencer dans les grammaires DTD des modèles SLA et des modèles de description d'outils SLA, les grammaires DTD des fichiers de collecte et des modèles de rapports.
gne; - le dispositif est disposé sur la surface extérieure de la glace de protection du projecteur; - le dispositif comporte au moins deux sections comprenant chacune une première et une deuxième partie, l'angle au sommet de la première partie sensiblement prismatique de chaque section étant différent - le dispositif comporte au moins deux sections comprenant chacune une première et une
deuxième partie, le profil des stries de la deuxième partie de chaque section étant différent.
La présente invention a encore pour objet un gabarit pour la mise en oeuvre du procédé
décrit plus haut.
Selon l'invention, le gabarit délimite la deuxième région de la glace de protection du
projecteur sur laquelle doit être disposé le dispositif d'adaptation.
Selon d'autres caractéristiques avantageuses et non limitatives du gabarit selon l'invention, le gabarit est adapté à la forme totale de la glace de protection du projecteur de
croisement et il délimite la deuxième région de la glace de protection du projecteur sur la-
quelle doit être disposé le dispositif d'adaptation.
La présente invention a enfin pour objet un projecteur de croisement du genre ellipti-
que pour véhicule automobile, comportant, en amont d'une glace de protection non déviatrice ou faiblement déviatrice de la lumière, une source lumineuse émettant des rayons lumineux
vers un miroir récupérateur et concentrateur qui les renvoie en direction d'une lentille conver-
gente pour former, en coopération avec un cache un faisceau de croisement comportant de part et d'autre d'un axe optique une demi-coupure supérieure sensiblement horizontale s'étendant d'un côté de l'axe optique et une demni-coupure située au-dessus de l'horizontale s'étendant de -6- l'autre côté de l'axe optique, le faisceau de croisement étant susceptible d'être adapté selon un
procédé tel que décrit plus haut.
Selon la présente invention, la glace de protection est munie d'un gabarit de pose tel
que décrit ci-dessus.
Le troisième mode de réalisation est particulièrement avantageux. Un procédé selon ce troisième mode de réalisation peut comporter les étapes suivantes: 1. Introduction d'une dispersion de particules décrite ci-dessus dans un milieu aqueux comprenant un sel d'un diacide carboxylique avec une diamine.
2. Polycondensation en phase fondue. 3. Mise en forme.
Les particules selon l'invention contenues dans la dispersion ne floculent pas lorsqu'elle sont introduites dans le milieu aqueux contenant le sel.
L'étape d'évaporation de l'eau et de polycondensation en phase fondue est réalisée selon les procédés usuels de fabrication du polyamide 66. La concentration en sel dans la solution aqueuse est généralement comprise entre 50 et 70%. Les monomères pour l'obtention du polymère sont principalement un acide dicarbolylique et une diamine, introduits sous forme de sel, par exemple un adipate d'hexaméthylène diamonium. On peut utiliser en complément de ces monomères difonctionnels, des comonomères monofonctionnels (limiteurs de chaînes), difonctionnels, ou multifonctionnels, avec un nombre de fonctions supérieur ou égal à trois. Un exemple de comonomère difonctionnel pouvant être est le caprolactame. L'utilisation d'un comonomère monofonctionnel peut être avantageuse afin de contrôler la cinétique de réaction de polycondensation et d'éviter éventuellement des phénomènes de prise en masse à l'intérieur du réacteur de polymérisation. A titre d'exemple de comonomère monofonctionnel convenable pour un tel contrôle, on peut citer les acides monocarboxyliques comme l'acide acétique.
L'étape de mise en forme consiste généralement à couler le matériau sous forme fondue à travers un orifice afin de former un jonc, à le refroidir, puis à granuler les composé solidifié. La composition être toutefois directement filée en sortie du dispositif de polymérisation.
D'autres détails ou avantages de l'invention sont illustrés par les exemples donnés ci-dessous uniquement à titre indicatif.
Exemple 1: Réalisation d'une dispersion de particules comprenant un dépôt Matières premières utilisées: KLEBOSOL 30R50 (Sol de silice commercialisé par la société Hoechst) Solution aqueuse d'oxychlorure de zirconium à 100 g/l en Zr02 Solution aqueuse de soude 4M.
Conditions opératoires: Dans un réacteur de 8 litres muni d'une agitation de type ancre tournant à 300 tours/mn on introduit 4000 g d'eau désionisée et 800 g de KLEBOSOL 30R50. Le pH du milieu réactionnel est ajusté à 7,5 par ajout de quelques gouttes de la solution aqueuse d'oxychlorure de zirconium. La masse réactionnelle est chauffée jusqu'à 60'C, cette température est maintenue pendant toute le durée de la réaction. A 60"C, on ajoute de façon continue 240 ml de la solution aqueuse de ZrOCI2 à 10%, le débit d'introduction est fixé à 2.5 mi/mn. Pendant l'introduction de l'oxychlorure de zirconium le pH est maintenu constant à l'aide d'une introduction simultanée de soude (solution 4 M). Après la fin d'introduction de la solution d'oxychlorure la température est maintenue à 60 'c pendant 1 heure. La conductivité du milieu réactionnel est de 11.6 mS. La masse réactionnelle est ensuite diafiltrée jusqu'à atteindre une conductivité de 1.5 mS (conductivité du perrnéat).
On ajoute ensuite, à pH 7,5 et à 60 OC et de façon continue, 240 ml de la solution aqueuse de ZrOCI2 à 10%, le débit d'introduction est de 2.5 ml/mn. Pendant l'introduction de l'oxychlorure de zirconium le pH est maintenu constant à l'aide d'une introduction simultanée de soude (solution 4 M). Après la fin d'introduction de la solution d'oxychlorure la température est maintenue à 60 OC pendant 1 heure. Le taux massique Zr02/SiO2 est alors de 20%.
Après refroidissement, la masse réactionnelle est partiellement désionisée par diafiltration jusqu'à atteindre une conductivité de 1 mS. La dispersion est concentrée par ultrafiltration jusqu'à atteindre un extrait sec de 15%.