INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Selon un mode de mise en œuvre particulier de l'invention, le serveur NP new peut émettre une requête (E231) à destination du contrat intelligent SC UE afin d’obtenir une empreinte numérique des données personnelles de l’utilisateur stockées lors de l’étape E130 (données certifiées au sens de l’invention). La requête est reçue par le contrat intelligent SC UE lors de l’étape E232. Le contrat intelligent SC UE émet une réponse (E233) comprenant l’empreinte numérique préalablement stockées. La réponse est reçue par le serveur NP new lors de l’étape E234. Le procédé compare ensuite l’empreinte numérique reçue en provenance du contrat intelligent (E234) de l’utilisateur avec une empreinte numérique obtenue via l’application d’une fonction cryptographique H’ aux données personnelles M obtenu lors de l’étape E230. A noter que la fonction cryptographique H’ est obtenue par le procédé (i.e par le serveur NP new ) préalablement. Selon un mode de mise en œuvre particulier de l'invention, la fonction cryptographique H’ correspond à la fonction cryptographique H.
Lorsque la comparaison est positive, c’est-à-dire que les données correspondent, le procédé continue. Dans le cas contraire le procédé s’arrête et un message d’erreur est envoyé à destination du terminal de l’utilisateur (non représenté).
Lors de l’étape E235, l’opérateur de télécommunications NP new génère une clef de chiffrement symétrique ( ) et chiffre cette clef via la clef de chiffrement de l’utilisateur obtenue (Pub UE ).
Ensuite, les données personnelles (M) de l’utilisateur sont chiffrées via la clef de chiffrement .
Lors de l’étape E236, l’opérateur de télécommunications NPnew envoie les données personnelles de l’utilisateur chiffrées à destination de l’espace de stockage numérique ESN.
Alternativement les données personnelles M ne sont pas chiffrées et sont stockées au sein de l’espace de stockage numérique ESN lors de l’étape E237.
Les données sont reçues et stockées lors de l’étape E237 par l’entité ESN. En réponse, l’entité ESN envoie (E238) au serveur NP new une adresse de stockage des données (par exemple une CID ( )) permettant de retrouver sans ambiguïté les données au sein de l’espace de stockage numérique ESN. Le CID est reçue par le procédé lors de l’étape E239.
Lors de l’étape E240, le procédé émet à destination du contrat intelligent SC UE (alternativement ou cumulativement à destination du terminal UE et/ ou de l’adresse Addr UE ), grâce par exemple à l’adresse AddrSC UE obtenue lors de l’étape E216, une requête de fin d’enregistrement (notification au sens de l’invention) comprenant une donnée de statut d’enregistrement. La donnée de statut d’enregistrement peut comprendre le CID ( ), et/ou une empreinte numérique des données M (Hash(M)). A noter que l’empreinte numérique des données M peut être le résultat de l’application de la fonction cryptographique H aux données personnelles M ou bien d’une autre fonction cryptographique H’’ connue par exemple de l’opérateur de télécommunications NP new .
L’entité de gestion 100 peut donc transmettre une liste d’obstacles prévus au véhicule connecté V, chaque obstacle prévu pouvant être couplé à une série d’informations complémentaire telles que la trajectoire prévue de l’obstacle (s’il est en déplacement), sa position et sa vitesse prévue à tel instant, ou toute autre information pertinente, lesdites informations complémentaires pouvant être associées à une probabilité de réalisation. La transmission d’informations au sujet d’un obstacle O prévu ou d’un véhicule V’ susceptible d’être croisé par le véhicule connecté V peut se faire sous la forme d’une suite de points de géolocalisation GPS successifs, auxdits points de géolocalisation étant associés une information donnant la probabilité de présence de l’obstacle O ou du véhicule V’ au point de géolocalisation en fonction des instants à venir dans un futur proche. Cette information peut être limitée en transmettant uniquement le point de géolocalisation GPS et l’instant à venir pour lesquels le croisement du véhicule connecté V avec un véhicule V’ ou un obstacle O est le plus probable.
La transmission de cette liste d’obstacles prévus peut se faire avant l’arrivée du véhicule V dans la zone Z à faible couverture réseau, afin de s’assurer que la transmission ne sera pas empêchée par la baisse de ressources réseau offertes par le réseau N dans la zone Z à faible couverture.
Le véhicule V pourra ensuite, à la sortie de la zone Z à faible couverture réseau, envoyer des informations à l’entité de gestion 100, si les capacités réseaux le permettent. Ces informations permettront de confirmer ou d’infirmer la présence des obstacles fixes O dans la zone Z à faible couverture réseau, et également si le véhicule connecté V a bien croisé le véhicule V’ ou non. Ce véhicule V’ peut effectivement avoir changé de direction ou bien s’être arrêté après avoir été détecté comme se dirigeant vers la zone Z. Le véhicule connecté V devra donc confirmer ou infirmer son croisement avec le véhicule V’ pour améliorer les prévisions de l’entité de gestion 100. Cet envoi d’informations de confirmation ou d’infirmation pourra se faire à la sortie de la zone Z à faible couverture réseau pour profiter du retour d’une bonne capacité en ressources réseau de la part du réseau N.
Procédé et dispositif de contrôle de système d’aide à la conduite d’un véhicule basé sur une limite de vitesse La présente invention concerne les procédés et dispositifs de contrôle d’un ou plusieurs systèmes d’aide à la conduite embarqué dans un véhicule. La présente invention concerne également un procédé et un dispositif de détermination d’une information représentative de limite de vitesse pour véhicule, par exemple automobile. La présente invention concerne également un procédé et un dispositif de contrôle d’un véhicule, notamment un véhicule autonome.
Cependant, lorsque le véhicule circule sur une route à plusieurs voies de circulation, certains panneaux indiquant une limite de vitesse installés en bord de route ne s’appliquent qu’à une seule des voies par exemple, qui ne correspond pas toujours à la voie sur laquelle se trouve le véhicule.
La détection d’un tel panneau peut alors entrainer la génération d’une information erronée sur la limite de vitesse applicable au véhicule.
Un autre objet de la présente invention est d’améliorer le contrôle d’un système ADAS du véhicule, notamment un système utilisant une information sur la limite de vitesse applicable, par exemple le système SLI ou ISA.
Un autre objet de la présente invention est d’améliorer la reconnaissance automatique d’une limite de vitesse applicable à un véhicule.
Selon un premier aspect, la présente invention concerne un procédé de contrôle d’un système d’aide à la conduite, dit système ADAS, embarqué dans un premier véhicule, le premier véhicule circulant sur une voie courante d’une portion de route comprenant une pluralité de voies ayant un même sens de circulation, une voie de la pluralité correspondant à une voie de sortie ou d’insertion de ladite portion de route, le procédé comprenant les étapes suivantes :
- détection d’un panneau de limitation de vitesse à partir de données d’image reçues d’une première caméra embarquée dans le premier véhicule ;
Selon un mode particulier de réalisation de l’invention, les contrats intelligents peuvent être répartis au sein d’une pluralité de chaînes de blocs.
Selon un mode particulier de réalisation de l’invention, les fonctionnalités des contrats intelligents (SC reg , SC UE , SC UB , SC NPB , SC NP ) peuvent être regroupées au sein d’un ou d’une pluralité de contrats intelligents.
Au cours d’une première étape E101, le terminal UE émet une requête à destination du contrat intelligent SC reg . Cette requête peut contenir le nom (NP) de l’opérateur de télécommunications auquel l’utilisateur souhaite souscrire, une empreinte numérique d’un « nonce » et un identifiant de l’utilisateur et/ou de son terminal. Le « nonce » est par exemple un nombre aléatoire généré par une application exécutée par le terminal UE de l’utilisateur. L’empreinte numérique est par exemple calculée grâce à une fonction cryptographique H (par exemple l’algorithme « Keccak-256 »). La requête est reçue par le contrat intelligent SC reg lors de l’étape E102. A l’étape E103a le contrat intelligent SC reg vérifie si un contrat intelligent appartenant à l’utilisateur a préalablement été déployé au sein de la chaîne de blocs BC. Si ce n’est pas le cas, le contrat intelligent SC reg déploie le contrat intelligent SC UE de l’utilisateur (E104). Une fois le contrat intelligent SC UE déployé, le contrat intelligent SC reg enregistre l’utilisateur (E103b) en ajoutant (E105) le couple « identifiant d’utilisateur / adresse du contrat intelligent de l’utilisateur » au sein du contrat intelligent SC UB .
A l’étape E106a, le contrat intelligent SC reg émet une requête à destination du contrat intelligent SC NPB afin de vérifier si le nom de l’opérateur de télécommunications reçu (E102) est bien un opérateur de télécommunications connu et approuvé par l’entité qui a déployé la chaîne de blocs BC (c’est-à-dire l’entité qui gère le système). La requête est reçue par le contrat intelligent SC NPB lors de l’étape E107a. Une réponse est ensuite émise (E107b) à destination du contrat intelligent SC reg puis reçue lors de l’étape E106b. Si le nom de l’opérateur de télécommunications n’est pas validé par le contrat intelligent SC NPB alors le procédé se termine. Un message d’erreur est émis par le contrat intelligent SC reg à destination du terminal UE (non représenté). Dans le cas contraire, lors de l’étape E108, le contrat intelligent SC reg émet une requête à destination du contrat intelligent de l’opérateur SC NP comprenant par exemple, alternativement ou cumulativement, les données suivantes : l’identifiant reçu lors de l’étape E102 ; l’adresse du contrat intelligent SC UE (AddrSC UE ) ; l’empreinte numérique du nonce reçue lors de l’étape E102 ; un paramètre Type req indiquant le type de requête, par exemple positionné à la valeur 1 pour un premier enregistrement (le contrat intelligent SC UE n’existait pas préalablement) ou bien à la valeur 2 pour une demande de changement d’opérateur de télécommunications de la part de l’utilisateur.
Les données sont reçues (E110) puis stockées par le contrat intelligent de l’opérateur SC NP .
Lors de l’étape E111, le contrat intelligent SC reg émet une réponse à destination du terminal UE qui peut comprendre l’adresse du contrat intelligent SC UE (AddrSC UE ) et/ou un lien (par exemple une URL) d’une page internet opérée par l’opérateur de télécommunications permettant à l’utilisateur de s’enregistrer. Le terminal utilisateur UE reçoit la réponse (E112) puis émet (E113) à destination de l’URL (c’est-à-dire du site internet de l’opérateur de télécommunications NP) une requête (requête d’enregistrement au sens de l’invention) qui comprend alternativement ou cumulativement l’identifiant de l’utilisateur, le « nonce » (donnée de transaction au sens de l’invention) et l’adresse du contrat intelligent SC UE (AddrSC UE ). Dans l’exemple décrit ci-après, l’identifiant de l’utilisateur correspond à l’identifiant que celui-ci utilise pour s’authentifier au niveau de la chaîne de blocs BC (son adresse au sein de la chaîne de blocs Addr ue ).
Selon un mode de mise en œuvre particulier de l'invention, les étapes E111, E112, E113 correspondent à l’émission par le contrat intelligent SC reg d’une requête de redirection à destination du terminal UE vers l’URL de l’opérateur de télécommunications, la requête de redirection étant une requête d’enregistrement au sens de l’invention et enrichie par le terminal UE avec alternativement ou cumulativement l’adresse du contrat intelligent SC UE (AddrSC UE ), le « nonce » et l’identifiant de l’utilisateur au sein de la chaîne de blocs (Addr ue ).
La requête d’enregistrement est reçue par l’opérateur de télécommunications NP lors de l’étape E114. L’opérateur NP vérifie ensuite la validité de la requête d’enregistrement via une requête de vérification émise (E115) à destination de son contrat intelligent SC NP . Cette requête de vérification comprend alternativement ou cumulativement l’adresse du contrat intelligent SC UE (AddrSC UE ), le « nonce » et l’identifiant de l’utilisateur au sein de la chaîne de blocs (Addr ue ). La requête est reçue par le contrat intelligent SC NP à l’étape E116. Grâce à l’adresse du contrat intelligent SC UE (AddrSC UE ) et/ou à l’identifiant de l’utilisateur (Addr ue ) obtenu(s), le contrat intelligent SC NP obtient (E117) l’empreinte numérique du « nonce » de l’utilisateur stockée lors de l’étape E110. Le contrat intelligent SC NP qui détient la fonction cryptographique H calcule l’empreinte numérique du « nonce » reçu lors de l’étape E116 et la compare (E117) à celle obtenue lors de l’étape E110. Dans le cas où les empreintes numériques correspondent alors la requête d’enregistrement est validée et le contrat intelligent SC NP répond (E118) positivement à la requête de vérification émise lors de l’étape E115.
Dans le cas contraire le contrat intelligent SC NP répond (E118) négativement à la requête de vérification émise lors de l’étape E115. Lors de l’étape E119, l’opérateur de télécommunications NP reçoit la réponse à la demande de vérification de la requête d’enregistrement et émet le statut de l’enregistrement (par exemple valide ou non valide) à destination du terminal UE (E120). Le statut est ensuite reçu par le terminal UE lors de l’étape E121. Dans le cas où le statut est négatif, le processus s’arrête (non représenté). Dans le cas contraire, la requête émise par l’opérateur NP comprend en outre une URL d’un formulaire.
Selon un mode de mise en œuvre particulier de l'invention, le procédé peut lors de l’étape E115 émettre à destination du contrat intelligent SC NP une demande de donnée de référence. Cette demande peut comprendre l’adresse du contrat intelligent SC UE (AddrSC UE ) et/ou l’identifiant de l’utilisateur au sein de la chaîne de blocs (Addr ue ). La requête est reçue par le contrat intelligent SC NP à l’étape E116. Grâce à l’adresse du contrat intelligent SC UE (AddrSC UE ) et/ou à l’identifiant de l’utilisateur (Addr ue ) obtenu(s), le contrat intelligent SC NP obtient (E117) l’empreinte numérique du « nonce » de l’utilisateur stockée lors de l’étape E110. Le contrat intelligent SC NP envoie une réponse (E118) à destination du serveur NP, réponse qui peut comprendre l’empreinte numérique du « nonce » stockée lors de l’étape E110. Dans ce cas l’empreinte numérique du « nonce » (H(nonce)) stockée lors de l’étape E110 correspond à la donnée de référence au sens de l’invention. La donnée de référence est reçue par le serveur NP lors de l’étape E119. Le contrat intelligent SC NP compare (E119) ensuite la donnée de référence avec une empreinte numérique obtenue via l’application d’une fonction cryptographique H au « nonce » obtenu lors de l’étape E114. A noter que la fonction cryptographique H est obtenue par le procédé (i.e par le serveur NP) préalablement à l’étape E115. Dans le cas où les empreintes numériques correspondent alors la requête d’enregistrement est validée. L’opérateur de télécommunications NP émet ensuite le statut de l’enregistrement (par exemple valide ou non valide) à destination du terminal UE (E120). Le statut est ensuite reçu par le terminal UE lors de l’étape E121. Dans le cas où le statut est négatif, le processus s’arrête (non représenté). Dans le cas contraire, la requête émise par l’opérateur NP comprend en outre une URL d’un formulaire.
Lors de l’étape E122, l’utilisateur du terminal UE rempli le formulaire avec ses données personnelles (M) puis envoie le formulaire complété ainsi qu’une clef de chiffrement publique Pub UE lui appartenant, par exemple obtenue depuis l’élément sécurisé du terminal UE, à destination de l’opérateur de télécommunications NP. Les données personnelles (M) et la clef (Pub UE ) sont reçues par l’opérateur de télécommunications NP lors de l’étape E123.
Selon un mode de mise en œuvre particulier de l'invention, les données personnelles de l’utilisateur peuvent être obtenues par le serveur NP via un tiers de confiance. Dans ce cas, l’URL du formulaire n’est pas envoyée au terminal UE lors de l’étape E120 et seule une clef de chiffrement publique appartenant à l’utilisateur / terminal de l’utilisateur (Pub UE ) est envoyée à destination de l’opérateur de télécommunications NP lors de l’étape E122.
Lors de l’étape E124, l’opérateur de télécommunications NP génère une clef de chiffrement symétrique (S k ) et chiffre cette clef via la clef de chiffrement de l’utilisateur obtenue (Pub UE ).
Ensuite, les données personnelles (M) de l’utilisateur sont chiffrées via la clef de chiffrement S k .
Lors de l’étape E125, l’opérateur de télécommunications NP envoie les données personnelles de l’utilisateur chiffrées à destination d’un espace de stockage numérique ESN.
Alternativement les données personnelles M ne sont pas chiffrées et sont stockées au sein de l’espace de stockage numérique ESN lors de l’étape E126.
Il est à noter que toute technique d’encodage (respectivement de modulation) connue de l’homme du métier pour la mise en œuvre de communications VLC peut être utilisée. Ainsi, le choix d’une technique particulière d’encodage (respectivement de modulation) ne représente qu’une variante d’implémentation de l’invention.
Dans le mode de réalisation décrit ici en référence à la , ledit élément émetteur ELE_TX est apte à la fabrication de l’enveloppe de l’habitacle de la voiture. Dit encore autrement, ledit élément émetteur ELE_TX est configuré de manière structurelle pour faire partie de ladite enveloppe.
Par exemple, ledit élément émetteur ELE_TX est le toit de l’habitacle de la voiture.
Selon un exemple plus spécifique, ledit toit est vitré.
Encore d’autres exemples d’éléments aptes à la fabrication de l’enveloppe de l’habitacle de la voiture peuvent être envisagés. Ainsi, ledit élément émetteur ELE_TX peut être l’un quelconque parmi : une vitre latérale, un pare-brise, une lunette arrière, un panneau de porte, un tableau de bord, etc.
Le fait de considérer que l’élément émetteur ELE_TX est apte à la fabrication de l’enveloppe de l’habitacle de la voiture ne constitue qu’une variante d’implémentation de l’invention, et rien n’exclut d’envisager encore d’autres variantes. Par exemple, ledit élément émetteur ELE_TX peut former un équipement dudit habitacle.
Par exemple, ledit élément émetteur ELE_TX peut être un appui-tête fixé à un siège de l’habitacle, un siège, un accoudoir, un pare-soleil, un rétroviseur intérieur, etc.
Selon encore un autre exemple, ledit élément émetteur ELE_TX n’appartient pas à l’habitacle (aussi bien en tant qu’enveloppe qu’en tant qu’équipement) et correspond à un rétroviseur extérieur de la voiture.
D’une manière générale, aucune limitation n’est attachée à la nature dudit élément émetteur ELE_TX dès lors que ce dernier est apte à émettre vers l’habitacle de la voiture, au moyen d’au moins une source lumineuse, au moins un signal lumineux VLC comportant des données encodées par le module émetteur MOD_TX.
Il est à noter que lorsque l’élément émetteur ELE_TX prend la forme d’un vitrage, la coopération entre la diode et ledit vitrage peut être réalisée de différentes manières. Par exemple, la diode peut être fixée sur une surface interne du vitrage ou bien encore, dans le cas où le vitrage est feuilleté, être intégrée au feuilletage de ce dernier. Ces aspects sont bien connus de l’homme du métier et sortent du cadre de la présente invention, si bien qu’ils ne sont pas davantage détaillés.
Dans le mode de réalisation décrit ici en référence à la , le module émetteur MOD_TX n’est pas intégré à l’élément émetteur ELE_TX. Autrement dit, le module émetteur MOD_TX est agencé, dans la voiture, à distance de l’élément émetteur ELE_TX (i.e. est externe à l’élément émetteur ELE_TX) et est connecté à ce dernier grâce à des moyens de connexion (moyens filaires ou non filaires, bus informatique, etc.). En particulier, ces moyens de connexion sont aptes à l’échange de données, signaux, commandes, etc. selon tout protocole connu de l’homme du métier.
Le fait de considérer un module émetteur MOD_TX externe à l’élément émetteur ELE_TX ne constitue cependant qu’une variante d’implémentation de l’invention. Rien n’exclut toutefois d’envisager d’autres variantes selon lesquelles, par exemple, le module émetteur MOD_TX est intégré à l’élément émetteur ELE_TX. De telles dispositions sont avantageuses en ce qu’elles permettent un gain de place.
Ainsi, à titre illustratif, dans le cas d’un élément émetteur ELE_TX prenant la forme d’un vitrage feuilleté, le module émetteur MOD_TX peut être intégré dans le feuilletage.
L’ensemble récepteur ENS_RX, quant à lui, comporte un élément, dit « élément récepteur » ELE_RX, comprenant des moyens de détection de lumière (i.e. des moyens photosensibles) configurés pour recevoir (détecter) ledit au moins un signal VLC émis au sein de l’habitacle par ladite diode de l’élément émetteur ELE_TX, ainsi que pour être connecté à un module récepteur VLC MOD_RX appartenant également audit ensemble récepteur ENS_RX.
Plus particulièrement, dans le mode de réalisation décrit ici, lesdits moyens de détection de lumière sont un photodétecteur. De manière connue en soi, ledit photodétecteur (encore appelé photorécepteur) est un dispositif récepteur sensible à des modulations à très haute fréquence de l'intensité d’un signal lumineux (en particulier, dans le cas d’espèce, à celui d’un signal VLC). Il s’agit par exemple une photodiode en silicium de type PIN, ou bien encore d’un module photovoltaïque.
Le fait de considérer ici un photodétecteur en tant que moyen de détection de lumière ne constitue cependant qu’une variante d’implémentation de l’invention. Rien n’exclut d’envisager d’autres variantes, comme par exemple un module photovoltaïque. D’une manière générale, tout moyen de détection de lumière connu de l’homme du métier peut être utilisé dans le cadre de la présente invention.
La est une représentation graphique de l'évolution de la vitesse de phase du mode de cisaillement (axe vertical, en m/s) en fonction de la fréquence (axe horizontal en MHz) sur un substrat POI qui comprend une couche de LiTaO 3 (YXl)42° de 600nm, une couche additionnelle de 100 nm, une couche diélectrique de 400 nm, et un substrat support de Silicium, la couche additionnelle pouvant comprendre du Carbone diamant, du GaN, du ZnO, du LiNbO 3 .
La est une représentation graphique de l'évolution de la vitesse de phase du mode de cisaillement (axe vertical, en m/s) en fonction de la fréquence (axe horizontal en MHz) sur un substrat POI qui comprend une couche de LiTaO 3 (YXl)42° de 600nm, une couche additionnelle de 100 nm, une couche diélectrique de 400 nm, et un substrat support de Silicium, la couche additionnelle pouvant comprendre du SiN, du poly-Si, de l’AlN, de l’Al 2 O 3 .
Ainsi, à l’exception du carbone diamant, le même comportement est observé lorsque la vitesse de mode tend vers la vitesse de l'onde de cisaillement dans le silicium aux basses fréquences. La diminution de ladite vitesse mode équivaut à augmenter la longueur d'onde du mode considéré pour une fréquence donnée, et réduit ainsi l'influence de la structure composite du substrat POI.
La présente invention telle que décrite précédemment couvre une pluralité d’aspects qui peuvent être considérés de manière indépendante ou en combinaison afin d’optimiser (réduire) le coefficient TCF 1 à des valeurs inférieures à 20 ppm/K, avantageusement inférieures à 15 ppm/K, encore plus avantageusement inférieures à 10 ppm/K, dès lors que la fréquence de fonctionnement du dispositif et en particulier du filtre à ondes élastiques de surface est inférieure à 1 GHz.
Le paramètre de modulation de phase de l’unité de modulation de phase 3446 peut être contrôlé par une unité de contrôle 3448 qui peut être par exemple un générateur de tension configuré pour émettre un signal radiofréquence permettant de générer une modulation de phase sinusoïdale. Ce signal radiofréquence peut avoir une phase nulle et dépendre d’une fréquence . Une telle modulation de phase notée peut être définie, en fonction d’un paramètre correspondant à la profondeur de modulation, selon l’équation (10) suivante :