INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Le dispositif de chauffe est par exemple adapté pour apporter un flux de chaleur vers l’enceinte, déterminé de manière à ce qu’une variation de température moyenne dans l’enceinte soit supérieure ou égale à 5°C par minute, pour la durée de l’étape d’apport de chaleur.
Les cellules sont notamment des cellules de type électrochimique, par exemple des cellules lithium-ion.
Le procédé est par exemple mis en œuvre par un module de contrôle électronique, comprenant un processeur et une mémoire et contrôlant chaque capteur.
Chaque capteur peut être choisi parmi un capteur de température, un capteur de pression, un capteur de courant électrique, un capteur de tension électrique, un détecteur de flux gazeux et un détecteur de gaz.
Un tel capteur permet de détecter le début de l’emballement thermique dans la batterie de manière rapide et fiable.
Le détecteur de gaz est par exemple un détecteur de CO, CO2, H2 et/ou HF.
la représente un schéma fonctionnel d'un procédé de prédiction conformément à la présente invention.
Comme représenté sur la , le procédé selon l’invention comprend une étape 31 d’évaluation des différentes caractéristiques des signes cutanés à partir d’une image d’entrée.
Selon l’invention, on réalise une analyse holistique avec une cartographie globale multizones permettant une évaluation globale ainsi qu'une évaluation ciblée.
Par exemple, on calcule le poids de la zone des yeux par rapport au visage global en âge apparent.
Plus de 20 traits du visage peuvent être automatiquement capturés : plus de signes analysés signifie une évaluation plus spécifique et plus précise pour chaque signe cutané.
Chaque partie du visage sera analysée :
Haut avec rides du front,
Yeux avec paupière tombante, pattes d'oie, poches, rides périorbitaires, cernes,
Nez/joues avec texture, pores, taches pigmentaires, sillon nasogénien,
Bouche avec commissures des lèvres,
Partie inférieure du visage avec ptose.
Dans une étape 11, ces caractéristiques évaluées à partir de l’image d’entrée sont comparées à des caractéristiques de référence pré enregistrées dans une base de données.
Dans une étape 41, les réponses de l’utilisateur à un questionnaire concernant ses habitudes de vies peuvent enregistrées et être traitées dans une base de données.
Ces réponses peuvent, par exemple, appartenir à des catégories telles que des caractéristiques physiques de l’utilisateur, son lieu de vie, la démographie de son lieu d’habitation, des informations nutritionnelles, des informations sur l'utilisation des cosmétiques, des informations environnementales, des informations sur l'utilisation des produits de beauté, le mode de vie, les habitudes alimentaires, l'emplacement géographique de la résidence, l'emplacement du travail, les habitudes de travail, habitudes de sommeil, habitudes d'exercice, habitudes de relaxation, habitudes de soins de beauté, habitudes de tabagisme et de consommation d'alcool ; habitudes d'exposition au soleil, l’utilisation d'écran solaire, la propension à bronzer, le nombre de coups de soleil et de coups de soleil graves, les restrictions alimentaires, les compléments alimentaires ou vitamines, les habitudes de voyage, les informations sur la forme physique, les réactions indésirables aux produits, l'utilisation de produits de soins de beauté antérieurs et leur efficacité, les loisirs, l’état civil, les pays et région de naissance, si le sujet est citadin, périurbain ou rural, la taille de la zone urbaine dans laquelle vit le sujet, si le sujet est retraité.
Dans une étape 42, le contexte de vie de l’utilisateur peut être enregistré et traité additionnellement dans la même base de données.
Ce mode de réalisation permet d’évaluer plus précisément les vulnérabilités sur l’ordinateur. En particulier, il permet de tester si un programme de protection donné protège effectivement contre l’exploitation d’une vulnérabilité informatique donnée.
Si plusieurs programmes de protection sont installés, cela permet en outre d’identifier les programmes de protection inefficaces.
Selon un deuxième aspect, l’invention propose un procédé d’identification mis en œuvre par un dispositif de gestion de sécurité, pour identifier l’exploitabilité d’une vulnérabilité informatique dans au moins un ordinateur, ledit procédé comportant des étapes de : - réception en provenance dudit au moins un ordinateur, d’un signal comprenant un indicateur de l’exploitabilité de ladite vulnérabilité dans un ensemble de processus associés à une combinaison d’espaces de nommage dudit au moins un ordinateur ; - ajout à une liste dudit signal.
Corrélativement, l’invention propose un module d’identification dans un dispositif de gestion de sécurité, pour identifier l’exploitabilité d’une vulnérabilité informatique dans au moins un ordinateur, ledit module comportant : - un sous-module de réception, en provenance dudit au moins un ordinateur, d’un signal comprenant un indicateur de l’exploitabilité de ladite vulnérabilité dans un ensemble de processus associés à une combinaison d’espaces de nommage dudit au moins un ordinateur ; - un sous-module d’ajout à une liste dudit signal.
L’invention propose un procédé permettant d’identifier, à partir d’un dispositif (par exemple un serveur), une vulnérabilité informatique donnée dans un ordinateur ou un parc d’ordinateurs, ainsi que les combinaisons d’espaces de nommage dans lesquelles cette vulnérabilité est exploitable.
Les étapes du procédé d’identification décrit ci-dessus peuvent être répétées pour une pluralité de vulnérabilités informatiques données.
Cette identification de vulnérabilités informatiques et de leur exploitabilité permet avantageusement de faciliter l’orchestration de la sécurité sur le parc d’ordinateurs par un administrateur central contrôlant le dispositif de gestion de sécurité.
À cet effet, l’invention propose de mettre en commun les messages provenant des ordinateurs dans lesquels une ou plusieurs vulnérabilités exploitables ont été détectées, en ajoutant ces messages dans une liste.
Cette liste permet notamment à l’administrateur de prendre des décisions concernant la gestion de la sécurité dans le parc d’ordinateurs. Par exemple, la présence de certaines vulnérabilités dans des espaces de nommage particuliers peut inciter à installer des programmes de sécurité pour renforcer la sécurité des processus associés à ces espaces de nommage.
Selon un mode de réalisation de l’invention, le procédé d’identification comporte une étape d’envoi audit au moins un ordinateur, d’un identifiant de ladite vulnérabilité.
Cet envoi permet à l’administrateur du dispositif de gestion de sécurité de décider quels programmes de détection seront exécutés sur les ordinateurs du parc informatique. En effet, ce mode de réalisation permet, dans un mode de réalisation du procédé de détection décrit précédemment, d’installer et d’exécuter le programme de détection en réponse à l’envoi de l’identifiant de vulnérabilité par le dispositif de gestion de sécurité.
Par conséquent, l’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un dispositif informatique ou plus généralement dans un ordinateur. Ce programme comporte des instructions permettant la mise en œuvre d’un procédé tel que décrit ci-dessus.
L’invention vise aussi un support d'informations ou un support d’enregistrement lisibles par un ordinateur et/ou un dispositif informatique, et comportant des instructions d’un programme d'ordinateur tel que mentionné ci-dessus.
L’invention concerne également un dispositif d’élaboration dynamique d’une infrastructure de données dans un réseau de communication, ladite infrastructure comprenant un ensemble de ressources mises à disposition par une pluralité d’entités, ledit dispositif étant apte à déterminer un ensemble de ressources pour la mise en œuvre d’un service de données, et comprenant : - un module d’obtention, apte à obtenir ’une requête d’instanciation dudit service, ladite requête comprenant un paramètre relatif à un utilisateur du service et un paramètre relatif à la zone géographique dans laquelle ledit service doit être instancié, - un module de détermination, apte à déterminer une entité de la pluralité, apte à contribuer à la mise en œuvre dudit service, en fonction des paramètres obtenus dans la requête d’implémentation, - un émetteur, apte à envoyer à un dispositif d’orchestration des ressources de ladite entité déterminée une première demande de déploiement d’une ressource dans l’infrastructure de données, ladite première demande comprenant les paramètres obtenus et un critère de conformité de la ressource avec l’infrastructure de données, - un récepteur, apte à recevoir en provenance du dispositif d’orchestration de ladite entité de la pluralité d’un message d’accord comprenant une identification de la ressource à déployer dans l’infrastructure de données.
Pour des raisons de clarté et de concision, la description qui suit fait référence à un réseau de caméras IP intelligentes dans un contexte VSaaS, et à une caméra virtuelle installée dans un serveur cloud. Mais l’invention trouve son application dans d’autres contextes, en particulier pour tout service intéressé par l’analyse de données, notamment de données vidéos et/ou audio et/ou de data (données numériques) et/ou de métadonnées. L’invention s’applique également à des dispositifs électroniques autres que des caméras IP intelligentes (par exemple des caméras non intelligentes – sans IA -, des consoles de jeu vidéo, des téléphones intelligents, des tablettes, des capteurs, Smart TV, …) ; ainsi qu’à des entités informatiques autres que des caméras virtuelles, par exemple un VMS, une partie de serveur informatique sur lequel est installé le VMS, une passerelle informatique (notamment une passerelle EDGEWAY® commercialisé par la société EDGEWAY VISION) ou un routeur installés dans le LAN, etc.
Caméra virtuelle ViC (figures 3 à 8) Pour configurer et/ou contrôler les données vidéo et/ou audio obtenues à partir de caméras physiques PhC1-PhC3, il est généralement nécessaire de passer par une interface de programmation d’applications, communément dénommée API, qui est une composante logicielle du VMS. Le VMS fournit notamment une interface à l’utilisateur final lui permettant de contrôler et/ou de configurer les caméras IP et d’interagir avec les données qu’elles fournissent.
Dans un contexte Vsaas, les caméras PhC1-PhC3 sont habituellement des caméras propriétaires, c’est-à-dire provenant d’un même constructeur. Elles contiennent entre autres une API permettant de configurer et/ou contrôler leurs paramètres de fonctionnement. Cette API est habituellement spécifiquement développée par ce constructeur et généralement seulement compatible avec les caméras IP de ce constructeur. Par exemple, la configuration et/ou le contrôle des fonctionnalités et des paramètres de fonctionnement des caméras IP commercialisées par le constructeur Axis® sont effectués de manière privilégiée via une API propriétaire dénommée Vapix® spécialement développée par Axis®. Les instructions de configuration et/ou de contrôle sont établies selon ce protocole propriétaire Vapix®. Si l’utilisateur installe des caméras IP d’un autre constructeur dans un environnement Axis®, par exemple des caméras IP de la marque Dahua®, les fonctionnalités et/ou les paramètres de fonctionnement de ces dernières pourront plus difficilement être configurés et/ou contrôlés depuis l’API Vapix®.
En outre, chaque caméra IP est généralement configurée et/ou contrôlée de manière singulière. L’utilisateur configure et/ou contrôle chaque caméra depuis l’API du VMS, lequel transmet à chacune desdites caméras IP un fichier de configuration qui lui est propre. S’il y a un nombre N de caméras IP, le VMS transmet N fichiers de configuration, chaque fichier modifiant une ou plusieurs fonctionnalités et/ou un ou plusieurs paramètres de fonctionnement propres à la caméra IP concernée. Il en résulte que la conception, la configuration et/ou le contrôle d’un réseau de caméras IP sont relativement complexes et longs, et nécessitent de solliciter des ressources informatiques, notamment pour la transmission des fichiers de configuration.
La solution décrite ci-après vise à remédier à tout ou partie des inconvénients précités. Elle vise notamment à atteindre un ou plusieurs des objectifs suivants : - permettre de configurer et/ou contrôler de manière simple et rapide un réseau de caméras IP, notamment des caméras IP provenant de différents constructeurs ; - simplifier la conception et le pilotage d’un réseau de caméras IP ; - réduire les ressources informatiques permettant de configurer et/ou contrôler un réseau de caméras IP ; - permettre à un utilisateur final de concevoir un parc de caméras IP provenant de différents constructeurs et de configurer et/ou contrôler ces caméras, de façon simple, rapide et sécurisée. - rendre une caméra 100% ONVIF.
La caméra virtuelle (entité informatique) recense les caméras IP installées dans un ou plusieurs réseaux. Selon un mode de réalisation, les caméras IP sont configurables et supporte chacune au moins un profil ONVIF, chaque dit profil ONVIF étant défini par des fonctionnalités ONVIF. La caméra virtuelle agrège une ou plusieurs fonctionnalités ONVIF qui sont communes aux profils ONVIF desdites caméras IP, laquelle caméra virtuelle est configurée pour collecter et agréger des données d’entrée provenant desdites caméras IP.
L’utilisateur peut ainsi maintenant simplement configurer et/ou contrôler une caméra virtuelle pour configurer et/ou contrôler l’ensemble des caméras IP de son réseau. En d’autres termes, au lieu de configurer et/ou contrôler chaque caméra IP d’un réseau, on configure et/ou contrôle uniquement une caméra virtuelle. La configuration et/ou le contrôle des caméras IP depuis la caméra virtuelle sont transparents pour l’utilisateur. L’utilisateur n’a donc qu’une caméra virtuelle à gérer et non pas toutes les caméras IP. Un seul fichier de configuration est transmis par la caméra virtuelle aux caméras IP, de manière à modifier et/ou adapter leur configuration en fonction d’une ou plusieurs fonctionnalités ONVIF communes.
En outre, les profils ONVIF (acronyme anglais de Open Network Video Interface Forum) permettent d’utiliser des protocoles de communication standards en s’affranchissant des protocoles de communication propriétaires. La caméra virtuelle présente ainsi une interopérabilité lui permettant d’interagir avec n’importe quelle caméra IP supportant un profil ONVIF, sans restriction d'accès ou de mise en œuvre. L’utilisateur peut donc concevoir son réseau en utilisant des caméras IP provenant de différents constructeurs alors même que ces caméras sont initialement paramétrées pour fonctionner et communiquer selon un protocole propriétaire.
Ainsi, la conception d’un réseau de caméras IP s’en trouve grandement simplifiée. Et la configuration et/ou le contrôle d’un tel réseau de caméra IP consomment moins de ressources informatiques en comparaison des solutions de l’art antérieur précitées.
Sur la , l’installation comprend une pluralité de caméras IP de vidéosurveillance, référencées PhC1-PhC3, installées en réseau dans une zone géographique d’intérêt Zi à surveiller. Cette zone peut être une zone privée (par exemple des bureaux, un parking) ou publique (par exemple un aéroport, une gare ferroviaire, une ou plusieurs rues). Ces caméras PhC1, PhC2, PhC3 sont des caméras physiques, c’est-à-dire réelles. Le réseau peut comporter de deux à plusieurs dizaines, voire plusieurs centaines de caméras IP.
Chaque caméra IP est configurée pour générer des données vidéo et éventuellement d’autres données telles que des données audio et/ou des métadonnées permettant notamment de décrire des contenus vidéo et/ou audio (heure, date, localisation, données de position PTZ, résolution d’image, niveau de bruit, zoom, résultats d’analyse, données textuelles, …).
Chaque caméra IP PhC1, PhC2, PhC3 filme tout ou partie de la zone Zi à surveiller, l’ensemble desdites caméras générant des données vidéo différentes de ladite zone. De manière classique, ces données vidéo sont obtenues par des capteurs d'image tels que des capteurs CCD (pour l’acronyme anglais de Charged Coupled Device) ou des capteurs CMOS (pour l’acronyme anglais de Complementary Metal Oxide Semiconductor). Les données vidéo peuvent être des données en temps réel et/ou des données enregistrées, des données d'image fixe et/ou des données d'image en mouvement. Une ou plusieurs des caméras PhC1, PhC2, PhC3 peuvent être des caméras pan-tilt-zoom (PTZ) capables d'effectuer un panoramique, un zoom et/ou une inclinaison de l’objectif. Les données audio peuvent être générées par un microphone installé sur la caméra PhC1, PhC2, PhC3. Et les métadonnées peuvent être générées par des ressources informatiques et/ou des applications informatiques spécifiquement intégrées dans la caméra PhC1, PhC2, PhC3.
Les caméras IP sont des caméras classiques du commerce provenant d’un même constructeur ou de constructeurs différents. À titre d’exemple, la caméra PhC1 est une caméra Axis® commercialisée sous la référence « M2026-LE Mk II Network Camera », la caméra PhC2 est une caméra Axis® commercialisée sous la référence « M1135-E Network Camera » et la caméra PhC3 est une caméra Dahua® commercialisée sous la référence « DH-IPC-C22EP ». Ces caméras IP sont initialement adaptées pour que la configuration et/ou le contrôle de leurs fonctionnalités et de leurs paramètres de fonctionnement puissent être effectués via une API propriétaire spécialement développée par leur constructeur. L’utilisateur n’a donc pas à choisir des caméras d’un seul constructeur pour construire son réseau. Selon un autre mode de réalisation, tous ou partie des caméras PhC1, PhC2, PhC3 sont des caméras virtuelles.
Selon un mode de réalisation, chacune des caméras PhC1, PhC2, PhC3 supportent au moins un profil ONVIF. Par exemple, la caméra PhC1 supporte les profils ONVIF G, S et T, la caméra PhC2 les profils ONVIF G et S, et la caméra PhC3 uniquement le profil ONVIF S. Les caméras PhC1, PhC2, PhC3 peuvent supporter d’autres profils ONVIF, notamment un profil Q et/ou un profil M.
Un profil ONVIF est défini par plusieurs fonctionnalités, elles-mêmes définies par un ou plusieurs paramètres de fonctionnement ou de configuration ou de réglage, ces termes étant considérés comme des synonymes. Les profils ONVIF sont par exemple définis par une configuration vidéo, une configuration audio, une configuration PTZ, et une configuration de métadonnées. Une configuration vidéo peut notamment inclure une fonctionnalité de diffusion vidéo (Video Streaming), une fonctionnalité d’encodage vidéo (Video Encoder Configuration), une fonctionnalité d’enregistrement vidéo (Recording Control), etc. Une configuration audio peut notamment inclure une fonctionnalité de diffusion audio (Audio Streaming), une fonctionnalité d’encodage audio (Audio Encoder Configuration), etc. Une configuration PTZ peut notamment inclure une fonctionnalité de déplacement (PTZ Move), une fonctionnalité de préréglage (PTZ Presets), etc. Une configuration de métadonnées peut notamment inclure une fonctionnalité de diffusion de métadonnées (Metadata Streaming), etc.
Chaque fonctionnalité est définie par des paramètres de fonctionnement. Par exemple, la fonctionnalité de diffusion vidéo peut être définie par un type de protocole de communication (RTSP, RTP, HTTP, TCP, UDP, …), par un type de format de compression vidéo (MJPEG, MPEG-4, H.264, H.265, …), etc. La fonctionnalité de diffusion audio peut être définie par un type de format de compression audio (G.711, G.726, MP3, ..), un débit ou une fréquence d'échantillonnage, etc. La fonctionnalité de déplacement PTZ peut être définie par une vitesse de déplacement, une inclinaison de l’objectif, un zoom, etc. Et la fonctionnalité de diffusion de métadonnées peut être définie par un type de standard, de format, de compression, etc.
RESUME Pour atteindre cet objectif, selon un mode de réalisation on prévoit un procédé de formation d’une couche à base d’un matériau diélectrique sur une couche à base d’un matériau III-V gravé. Le procédé comprend au moins les étapes suivantes : Fournir au moins une couche à base d’un matériau III-V, de préférence III-N, dite couche III-V, présentant une face avant, Graver au moins une partie de la couche III-V à partir de la face avant de sorte à exposer une surface de la couche III-V dite surface gravée, Exposer au moins la surface gravée à un traitement plasma de O 2 , de N 2 , ou d’un mélange de O 2 et de N 2 , cette étape étant réalisée à une température T traitement avec T traitement Déposer une couche à base d’un matériau diélectrique, dite couche diélectrique, au moins sur la surface gravée.
L’étape de traitement plasma mise en œuvre dans le procédé selon l’invention permet d’améliorer fortement la qualité de la couche de matériau III-V, typiquement de GaN gravé. Le travail à basse température permet notamment d’obtenir une couche de GaN gravé fortement stabilisée, permettant ainsi de faciliter et d’accélérer la manipulation des échantillons, ce qui résulte en un gain de productivité. Les échantillons doivent en effet être déplacés d’un réacteur à un autre, par exemple du réacteur où a eu lieu le traitement plasma au réacteur où a lieu le dépôt de la couche diélectrique en Al 2 O 3 par exemple. Dans le cadre du développement de la présente invention il a été remarqué qu’avec des températures plus élevées, la couche de matériau III-N est moins stable, ce qui pose des problèmes en termes de robustesse du procédé. En outre dans le cadre du développement de la présente invention il a été observé de manière inattendue que cet abaissement de la température conduit à une qualité d’interface entre le matériau III-N gravé et le matériau diélectrique bien meilleure que ce qui était prévisible. Bien au contraire, dans ce contexte l'homme du métier aurait été incité à appliquer des températures élevées pour recristalliser le matériau III-V se trouvant en surface et qui est altéré par la gravure.
L’amélioration de la qualité de la couche de GaN gravé induit elle-même une forte amélioration de la qualité de l’interface GaN gravé/diélectrique, notamment du point de vue de ses propriétés électriques.
Le procédé selon l’invention permet ainsi d’améliorer considérablement la productivité par rapport à une solution de type ALE, tout en offrant une qualité d’interface très satisfaisante. Il est cependant possible que le procédé selon l’invention soit utilisé conjointement à une gravure de type ALE.
Il est à noter que les traitements subséquents à une étape de dépôt de GaN épitaxié non gravé ne sont pas adaptés au traitement d’une couche de GaN gravé, ou sont du moins beaucoup moins efficaces. En effet, la surface d’une couche de GaN épitaxié non gravé est relativement stable car la couche a généralement passé un temps important, souvent de quelques heures à quelques mois, à l’air. La stœchiométrie de la couche de GaN épitaxié s’en retrouve stabilisée, ce qui rend peu réactive la surface de la couche, contrairement à la surface d’une couche de GaN gravé. Ainsi, la stratégie d’application d’un traitement plasma proposée dans la présente demande pour modifier chimiquement la surface du GaN et améliorer ainsi la qualité de l’interface avec le diélectrique aura peu d’effets sur les surfaces de GaN épitaxiées. Sur les surfaces épitaxiées non gravées, les traitements plasma constituent plutôt des stratégies de nettoyage et ne permettent pas la reconstruction structurelle que permet le procédé selon l’invention utilisé sur une couche de GaN gravé.
On prévoit en outre un procédé de réalisation d’un dispositif microélectronique comprenant la formation d’une couche à base d’un matériau diélectrique sur une couche à base d’un matériau III-V gravé en mettant en œuvre le procédé de formation mentionné ci-dessus, le dispositif microélectronique étant pris parmi un transistor et une LED.