INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Le piston 4 comprend au moins une fente 16 agencée sur sa périphérie. La fonction de la fente 16 est de permettre l’alimentation en produit, depuis le réservoir 5 jusqu’à la chambre avant 8.
La fente 16 est agencée de manière à se trouver au droit de la lumière 11 du réservoir 5, lorsque le piston 4 se trouve dans une première zone intermédiaire d'alimentation en produit ( et ). La première zone intermédiaire est située entre la position rétractée et la position étendue. Lorsque la fente 16 se trouve au droit de la lumière 11, du produit est transvasé dans la fente 16 depuis le réservoir 5, via la lumière 11.
En dehors de la première zone intermédiaire d’alimentation, le piston 4 obture la lumière 11. Le piston 4 obture notamment la lumière 11 dans la position rétractée. Cette caractéristique permet d’éviter les fuites de produit lorsque le module 1 n’est pas utilisé.
Selon des modes de réalisation de l’invention, représentés par exemple sur les figures 1 à 4 et 9 à 13, le piston 4 présente une forme cylindrique, et comprend une fente 16 de forme cylindrique s'étendant sur une circonférence complète du piston 4. La longueur de la fente 16 selon l’axe longitudinal du piston est choisie en fonction du débit de produit souhaité. En effet, plus la fente 16 est longue, plus la quantité de produit qui passera du réservoir 5 à la fente 16 pendant la course du piston 4 sera grande. Cette caractéristique permet donc d’ajuster le débit de produit. Cette caractéristique permet également lors du réglage de sortie de l’aiguille 2 d’augmenter automatiquement la quantité d’encre.
Selon un autre mode de réalisation de l’invention, représenté sur la , le piston 4 présente une forme cylindrique, et comporte plusieurs fentes 16 1 à 16 n , n’étant un entier positif. Les fentes 16 1 à 16 n présentent chacune une forme sensiblement rectangulaire et sont de dimensions différentes. Les fentes 16 1 à 16 n sont disposées à différentes positions sur une circonférence du piston 4. Le nombre de fentes 16 1 à 16 n est par exemple de quatre. Ce nombre n’est pas limitatif.
Lorsque le piston 4 comporte plusieurs fentes 16 1 à 16 n , le piston 4 est mobile en rotation autour de son axe, pour permettre la sélection de la fente 16 1 à 16 n à utiliser pour l'alimentation en produit. La rotation du piston 4 peut être réalisée manuellement. On appelle « fente à utiliser » la fente 16 1 à 16 n qui se trouvera au droit de la lumière 11 durant la course du piston 4. Cette caractéristique permet de régler encore plus précisément le débit de produit, et de modifier ce débit au cours du processus de tatouage.
Selon un autre mode de réalisation de l’invention, représenté sur la , le module 1 comprend plusieurs aiguilles 2 1 à 2 m , m étant un entier positif, disposées dans un même plan. Le piston 4 comporte ici une fente 16 de forme sensiblement rectangulaire, disposée de manière à se trouver au droit de la lumière 11 dans la première zone intermédiaire d’alimentation. Comme décrit précédemment, les dimensions de la fente 16 sont choisies en fonction du débit de produit souhaité.
La fixation de l’aiguille 2 au piston 4 peut être réalisée en insérant l’extrémité proximale de l’aiguille 2 dans le piston 4, selon son axe longitudinal. Un collage de l’extrémité proximale dans le piston 4 peut en outre être réalisé.
D’autres moyens peuvent être utilisés pour rendre l’aiguille 2 et le piston 4 solidaires en translation. Par exemple, dans le cas de plusieurs aiguilles 2 1 à 2 m disposées dans un même plan, un organe de fixation 17 ( ) peut être prévu pour recevoir l’extrémité proximale de chaque aiguille 2 1 à 2 m . L’organe de fixation 17 est ensuite fixé au piston 4.
4. Chambre avant
La chambre avant 8 du canal 6 est située en aval de la lumière 11, et s’étend jusqu’à proximité de l’extrémité libre 7 du canal 6.
On appelle « chambre avant » la partie aval du canal 6, dans laquelle l’extrémité distale de l’aiguille 2 se trouve lorsqu’elle est en position rétractée.
Notamment, la présente invention trouve une application avantageuse pour la mise en œuvre de système d’aide à la décision en temps-réel, par exemple permettant une optimisation des ressources matérielles (e.g. les salles de réunion d’un bâtiment) ou temporelles (e.g. l’emploi du temps d’un utilisateur).
Selon un mode de réalisation, une dite recommandation d’activités est envoyée uniquement à un utilisateur. En variante, une dite recommandation d’activités est envoyée à une pluralité d’utilisateurs.
Selon un mode de réalisation, une dite première activité est une activité réalisée par une ou plusieurs personnes situées dans le premier lieu (e.g. le début d’une présentation). En variante, ladite première activité est une activité associée au premier lieu, et ainsi à un changement dans le premier lieu (e.g. lancement d’un diaporama).
Selon un mode de réalisation , ladite au moins une recommandation d’activités est générée en outre en fonction d’une deuxième activité détectée en cours de réalisation par ledit au moins un utilisateur.
Selon ce mode de réalisation, l’activité d’un utilisateur est détectée, puis utilisée pour générer la recommandation d’activités envoyée à l’utilisateur. De la sorte, ce mode de réalisation permet d’adapter dynamiquement les recommandations d’activités fournies à un utilisateur en fonction de sa situation actuelle. Ainsi, ce mode de réalisation contribue à améliorer la pertinence des recommandations d’activités proposées à l’utilisateur.
Selon un mode de réalisation , ledit au moins un lien (entre ledit au moins un utilisateur et ladite au moins une première activité) comprend un lien dit fixe entre ledit au moins utilisateur et au moins une personne associée à ladite au moins une première activité, le lien fixe étant enregistré dans une base données et étant obtenu à partir d’un identifiant dudit au moins un utilisateur et d’un identifiant de ladite au moins une personne (associée à ladite au moins une première activité).
Ce mode de réalisation est avantageux en ce qu’il permet de générer des recommandations d’activités en fonction de relations interpersonnelles définies dans une base de données. Plus généralement, ce mode de réalisation permet de personnaliser les recommandations fournies aux utilisateurs.
Selon un mode de réalisation , ledit au moins un lien (entre ledit au moins un utilisateur et ladite au moins une première activité) comprend un lien dit dynamique entre ledit au moins un utilisateur et ladite au moins une première activité, le lien dynamique étant déterminé en fonction dudit au moins un utilisateur et de ladite au moins une première activité.
Ce mode de réalisation permet d’adapter au cours du temps les recommandations d’activités envoyées à un utilisateur en fonction d’un contexte courant et, ainsi, contribue à fournir des recommandations à jour aux utilisateurs.
Selon un mode de réalisation , le procédé comprend en outre un envoi, à un terminal d’un autre utilisateur (distinct dudit au moins un utilisateur), d’une autre recommandation d’activités générée en fonction de : ladite au moins une recommandation d’activités (envoyée audit au moins un utilisateur) ; et d’un lien entre l’autre utilisateur et ladite au moins une recommandation d’activités.
Dans ce mode de réalisation, la recommandation d’activités faite à un deuxième utilisateur est réalisée en fonction de la recommandation faite à un premier utilisateur et du lien entre ces utilisateurs. Autrement dit, il est proposé ici d’utiliser un mécanisme d’inférence (i.e. de réaction en chaîne) entre les recommandations fournies aux utilisateurs. Ce mode de réalisation permet de coordonner les activités de plusieurs utilisateurs. Ce mode de réalisation est particulièrement avantageux pour optimiser de manière collective la gestion de ressources partagées entre plusieurs utilisateurs (e.g. des salles de réunions).
Selon un mode de réalisation , ladite au moins une recommandation d’activités et une information représentative de ladite au moins une première activité détectée sont envoyées (via un réseau de communication) audit au moins un terminal dudit au moins un utilisateur.
Dans ce mode de réalisation, il est proposé de transmettre à l’utilisateur, en plus de la recommandation, l’activité détectée ayant déclenchée l’émission de cette recommandation. De la sorte, ce mode réalisation permet de contextualiser les recommandations d’activités proposées aux utilisateurs. Ce mode de réalisation permet ainsi de motiver l’envoi de recommandations auprès des utilisateurs et contribue à améliorer la pertinence de celles-ci pour les utilisateurs.
Selon un mode de réalisation , ladite au moins une recommandation d’activités est générée par un réseau de neurones.
Ce mode de réalisation permet d’optimiser de manière automatique la génération des recommandations à partir de données d’entrainement ou d’apprentissage en vue d’améliorer la pertinence des recommandations fournies aux utilisateurs. Autrement dit, ce mode de réalisation permet d’apprendre automatiquement à générer des recommandations pertinentes pour les utilisateurs.
Selon un mode de réalisation , le procédé comprend une mise à jour de paramètres (e.g. des poids) du réseau de neurones à partir d’une donnée indiquant si ledit au moins un utilisateur a suivi ou non ladite au moins une recommandation d’activités.
Deux exemples alternatifs de modes de réalisation physique des architectures systèmes sont décrits ici : soit le coprocesseur est apte à recevoir directement les images IMG acquises, le coprocesseur associant alors des données PIL de pilotage sous forme de métadonnée à chaque image et transmettant au processeur lesdites images IMG_M avec métadonnée associée ; soit le coprocesseur n’est pas apte à recevoir les images IMG acquises; notamment de par des limitations dues à son architecture; les images IMG acquises sont alors directement transmises par le système d’acquisition SA au processeur. Dans ce cas, l’association entre la nouvelle image acquise et les données PIL de pilotage de la métadonnée peut être réalisée par le processeur en utilisant l’horodatage enregistré par le processeur au moment où l’image IMG acquise parvient au processeur. En effet, même avec un processeur, appelé aussi plateforme, non temps réel, il peut être attribué à la tâche d’enregistrement de l’horodatage une priorité très élevée de manière à ce que l’horodatage soit enregistré aussitôt la réception de l’image IMG acquise par le processeur ; l'horodatage est alors sauvegardé par une tâche très courte et hautement prioritaire à la réception de l'interruption de rappel d'image prête (de l’anglais « call-back interrupt »), l'interruption servant à notifier le processeur que l'image a été copiée en mémoire et est disponible pour traitement.
Le premier mode de réalisation ; dans lequel le coprocesseur reçoit les images IMG acquises et les retransmet, est illustré par la . Par processeur et coprocesseur il n’est fait ici aucune indication de dépendance de l’un par rapport à l’autre, mais une simple différenciation des deux. Dans le mode de réalisation illustré sur cette figure le système synchrone SSY est un processeur temps réel PROC_TR, appelé aussi coprocesseur, et le système asynchrone SAS est un processeur non temps réel PROC_NTR appelé ici aussi processeur.
Toutes les étapes du système synchrone SSY sont dans ce premier mode de réalisation effectuées par le processeur temps réel PROC_TR, ce dernier recevant des CONS de pilotage, et : - lors d’une étape E_PIL de pilotage il PROC_TR élabore des données de pilotage PIL conformes aux consignes CONS et pilote de manière synchrone le système d’acquisition SA : capteur d’images SA1 et motorisation SA4, et le système d’éclairage SE conformément aux consignes en leur appliquant des données de pilotage PIL conformes aux consignes CONS, une image IMG est alors acquise par le système d’acquisition SA et transmise au processeur temps réel PROC_TR ; - puis lors d’une étape E_HOR le processeur temps réel PROC_TR crée une table de données de pilotage horodatées pour l’image IMG acquise et reçue ; - et lors de l’étape E_MET le processeur temps réel PROC_TR ajoute les données horodatées sous forme de métadonnées à ladite image IMG, générant ainsi l’image IMG_M avec métadonnée associée.
Toutes les étapes du système asynchrone SAS sont encadrées en pointillés et sont dans ce premier mode de réalisation effectuées par le processeur non temps réel PROC_NTR, ce dernier PROC_NTR recevant ladite image IMG_M avec métadonnée associée, et : - lors d’une étape E_TRA le processeur non temps réel PROC_NTR traite la donnée reçue, c’est-à-dire l’image IMG_M avec métadonnée associée en l’analysant, plus particulièrement en effectuant une analyse statistique de l’intensité et/ou de la position des yeux dans ladite image IMG_M avec métadonnée associée, et ; - étape E_CON de détermination des nouveaux paramètres de consigne CONS sous-forme de paramètres d’exposition et/ou éclairage et/ou création / mise à jour de la trajectoire des yeux pour l’acquisition suivante d’image.
Un second premier mode de réalisation ; dans lequel le coprocesseur ne reçoit pas les images IMG acquises, est illustré par la , les images IMG arrivant directement au processeur non temps réel PROC_NTR, ainsi: - comme dans le mode de réalisation précédent, lors d’une étape E_PIL de pilotage il PROC_TR élabore des données de pilotage PIL conformes aux consignes CONS et pilote de manière synchrone le système d’acquisition SA : capteur d’images SA1 et motorisation SA4, et le système d’éclairage SE conformément aux consignes en leur appliquant des données de pilotage PIL conformes aux consignes CONS; - puis, comme dans le mode de réalisation précédent, lors de l’étape E_HOR le processeur temps réel PROC_TR crée une table de données de pilotage horodatées pour l’image IMG acquise et reçue.
Dans ce mode de réalisation, l’image IMG est alors acquise par le système d’acquisition SA et transmise au processeur non temps réel PROC_NTR, le processeur non temps réel PROC_NTR exécutant des étapes du système synchrone SSY et du système asynchrone SAS, toutes les étapes du système asynchrone SAS étant encadrées en pointilles : - lors de l’étape E_ASS le processeur non temps réel PROC_NTR associe image IMG aux bonnes métadonnées grâce à l’horodatage TS, générant ainsi l’image IMG_M avec métadonnée associée ; - comme dans le mode de réalisation précédent, lors de l’étape E_TRA le processeur non temps réel PROC_NTR traite la donnée reçue, c’est-à-dire l’image IMG_M avec métadonnée associée en l’analysant, plus particulièrement en effectuant une analyse statistique de l’intensité et/ou de la position des yeux dans ladite image IMG_M avec métadonnée associée, et ; - étape E_CON de détermination des nouveaux paramètres de consigne CONS sous-forme de paramètres d’exposition et/ou éclairage et/ou création / mise à jour de la trajectoire des yeux pour l’acquisition suivante d’image.
Pour ce second mode de réalisation deux différentes alternatives sont décrites ici, ainsi : - une première alternative consiste en un compteur physique partagé entre le coprocesseur temps réel PROC_TR et le processeur non temps réel PROC_NTR, l’horodatage TS étant alors envoyé à la fois au deux processeurs PROC_TR et PROC_NTR, le processeur non temps réel PROC_NTR requérant alors au coprocesseur temps réel PROC_TR les données de pilotage correspondant à l’horodatage TS reçu ; - une seconde alternative ne comporte pas de compteur physique partage, mais consiste en un compteur logiciel au sein du processeur non temps réel PROC_NTR et un autre compteur logiciel, indépendant du premier compteur, au sein du coprocesseur temps réel PROC_TR, l’horodatage TS de l’image IMG acquise étant associé à ladite image acquise par le processeur non temps réel PROC_NTR. Le processeur non temps réel PROC_NTR doit alors connaitre le décalage entre les deux horodatages TS indépendants. Ce décalage peut être mesuré à la réception de la première image IMG, en comparant l’horodatage TS du processeur non temps réel PROC_NTR et l’horodatage TS du coprocesseur temps réel PROC_TR qui est enregistré sous forme de métadonnée dans ladite première image. Il est en effet possible qu’il existe un décalage entre les deux horodatages TS, notamment une dérive avec le temps, ce mode de détermination permet lors de la première acquisition d’image après le réveil du dispositif de déterminer ce décalage de manière à le connaitre pour toute la série d’acquisition, le considérant préférentiellement comme fixe pendant cette session de travail. En outre, cette dérive peut être compensée en appliquant un filtre de manière à adapter continûment le décalage sur la base des derniers offsets mesurés.
La illustre un dispositif de traitement d’images selon l’invention, et plus particulièrement conforme au second mode de réalisation, dans sa première alternative, et comportant les composants suivants : - un processeur non temps réel PROC_NTR, ici processeur principal, opérant un système d’exploitation non conçu pour le traitement temps réel, par exemple ARM Cortex-A53 sous linux ; - un coprocesseur temps réel PROC_TR, opérant un système d’exploitation conçu pour le traitement temps réel de données, par exemple un Cortex M7 + FreeRTOS ; - un compteur commun d’horodatage partage entre le processeur non temps réel PROC_NTR et le coprocesseur temps réel PROC_TR ; - un canal de communication entre le processeur non temps réel PROC_NTR et le coprocesseur temps réel PROC_TR ; - un canal de communication entre le coprocesseur temps réel PROC_TR et le système d’acquisition d’images SA.
Le coprocesseur PROC_TR est connecte directement au capteur d’image du système d’acquisition d’images SA et au système d’éclairage SE, et plus précisément a des diodes électroluminescentes DEL du système d’éclairage SE.
Le coprocesseur PROC_TR contrôle: - le moment de déclenchement exact du système d’acquisition de l’image (puis le temps exact auquel l’image est acquise, capturée) ; - le temps exact auquel les données PIL de pilotage (par exemple exposition et gain) sont appliquées, ainsi que potentiellement leur durée d’application ; - le temps exact auquel les intensités des DEL du système d’éclairage SE sont mises à jour, potentiellement à chaque trame .
Dans cet exemple une puce IMX8MPLUS est utilisée et à l’intérieur de la puce se trouvent : un processeur principal non temps réel PROC_NTR : A53, et un coprocesseur temps réel PROC_TR : Cortex M7, et l’unique horloge, ou compteur, physique HW_TS est à l’intérieur de la puce, et partage car accessible à la fois au processeur PROC_NTR A53 et au coprocesseur PROC_TR M7.
La illustre en partie le fonctionnement de cette architecture, pour raison de clarté toutes les étapes ne sont pas représentées, les composants ou étapes exécutées par le processeur non temps réel PROC_NTR sont entourés en pointilles et les composants ou étapes exécutées par le processeur temps réel PROC_TR sont entourés en traits pleins et les composants physiques sont représentés dans des zones hachurées.
Le composant BIO initialise, puis éteindra, au moyen de signaux d’initialisation et d’arrêt, le programme P_SA de pilotage de la caméra du système d’acquisition d’images, le programme P_SA communique des consignes à P_I2C de M7 . Le programme P_I2C communique avec le capteur d’image du système d’acquisition d’images SA notamment au moyen d'un protocole de type I2C. Puis, la première image acquise IMG, et plus généralement le flux d’images IMG, transitent par le composant MIPI de réception, avant d’être envoyée au processeur non temps réel PROC_NTR, et en parallèle le coprocesseur temps réel PROC_TR échantillonne , c’est-à-dire récupère la valeur courante, le compteur partagé HW_TS au moment où l'image est acquise puis le processeur PROC_NTR échantillonne le compteur partagé HW_TS un court instant plus tard, dès qu'il reçoit l'image via le call-back interrupt, c’est ainsi qu’est attribué l’horodatage correspondant au moment de l’acquisition de ladite image et de sa réception, qui l’enregistre dans une mémoire locale sous forme de table TAB, qui contient notamment pour un capteur infra rouge du système d’acquisition les données de pilotage, ou paramètres de configuration, du moment de l’acquisition de chaque image IMG: horodatage TS du moment de l’acquisition de ladite image, durée d’exposition de ladite image IMG , gain de ladite image IMG, modulation de largeur d’impulsion de la source de lumière infrarouge au moment de l'acquisition de ladite image IMG, et pour un capteur lumière rouge vert bleu RGB du système d’acquisition les données de pilotage, ou paramètres de configuration, du moment de l’acquisition de chaque image IMG : horodatage TS du moment de l’acquisition de ladite image IMG, durée d’exposition de ladite image IMG , gain de ladite image IMG, modulation de largeur d’impulsion de la source de lumière blanche au moment de l'acquisition de ladite image IMG, cette table TAB du coprocesseur M7 temps réel PROC_TR fournit alors les données nécessaires à l’étape d’association E_ASS exécutée par le processeur non temps réel PROC_NTR qui peut alors synchroniser l’image reçue IMG acquise à l'instant TS avec les données de pilotage appliquées audit instant horodaté TS par ajout de métadonnées a l’image IMG créant l’image IMG_M avec métadonnée associée. Les métadonnées associées pour chaque image et pour chaque capteur sont alors ici: la durée d’exposition, le gain, la modulation de largeur d’impulsion de la source de lumière infrarouge, modulation de largeur d’impulsion de la source de lumière blanche, la distance à l’objet capturé sur l’image (déterminée par analyse 3D et/ou à partir de la distance inter pupilles ou autre).
Il est alors procédé par le processeur non temps réel PROC_NTR à l’étape E_TRA de traitement de cette (ou plusieurs, telles que les deux dernières) image IMG_M avec métadonnée associée par algorithme CAG.
Puis le processeur PROC_NTR envoie au coprocesseur PROC_TR des consignes CONS pour la future acquisition comprenant notamment : la durée d’exposition, le gain, la modulation de largeur d’impulsion de la source de lumière infrarouge, modulation de largeur d’impulsion de la source de lumière blanche. En variante, les consignes CONS peuvent consister en ces mêmes paramètres (exposition, gain) pour une future trame paire d’acquisition et pour une future trame impaire d’acquisition.
Puis à l’étape E_PIL est commandé, par le coprocesseur PROC_TR, le futur déclenchement des capteurs du système d’acquisition SA et d’une source de lumière DEL du système d’éclairage SE selon les nouvelles données PIL de pilotage synchronisées, ici ces données étant les mêmes que les consignes CONS et ne nécessitant pas de traitement additionnel. En parallèle, le coprocesseur PROC_TR enregistre ces nouvelles données avec leur horodatage de l’horloge HW_TS dans la mémoire locale du coprocesseur PROC_TR comme explicité précédemment.
Lorsque le cœur est un substrat poreux ou lorsque le cœur est un gaz, le pigment interférentiel de l’invention peut être obtenu par dépôt de la couche de matériau comprenant du sulfure de zinc sur un cœur support solide, que l’on dissout ensuite totalement ou partiellement pour obtenir un gaz ou un substrat poreux, respectivement.
Le dispositif de recommandation d’activités, le système, le programme d’ordinateur et le support d’informations proposés disposent des avantages décrits ci-dessus en lien avec le procédé de recommandation d’activités proposé.
La et la représentent respectivement un exemple d’architecture d’un système et des étapes d’un procédé de recommandation d’activités selon un mode de réalisation de l’invention ;
La , la et la représentent des exemples de données obtenues et traitées par un système de recommandation d’activités selon un mode de réalisation de l’invention ;
La représente un exemple d’architecture logicielle et matérielle d’un système de recommandation d’activités selon un mode de réalisation de l’invention ; et
La présente invention concerne un procédé et un dispositif de recommandation d’activités pour un utilisateur, et un système, un programme d’ordinateur, et un support d’informations associés.