FR3095111A1 - Dispositif électronique porte-cartes connecté et système de gestion de cartes - Google Patents

Abstract

DISPOSITIF ÉLECTRONIQUE PORTE-CARTES CONNECTÉ ET SYSTÈME DE GESTION DE CARTES Le dispositif porte-cartes (DEC) comprend une pluralité de compartiments de rangement (EP1 à EP8) destinés au rangement d’une pluralité de cartes. Conformément à l’invention, le dispositif porte-cartes comprend une pluralité de capteurs de couleur (CS1 à CS8) associés respectivement aux compartiments de rangement, les capteurs de couleur étant agencés de façon à fournir des signatures chromatiques détectées pour chacun des compartiments de rangement, et les signatures chromatiques détectées étant utilisées pour déterminer la présence ou l’absence d’une carte dans un compartiment de rangement par une comparaison avec des signatures chromatiques de référence. Fig.3

Description

DISPOSITIF ÉLECTRONIQUE PORTE-CARTES CONNECTÉ ET SYSTÈME DE GESTION DE CARTES

L’invention concerne de manière générale le domaine de la gestion d’objets et documents sensibles sous la forme de carte. Plus particulièrement, l’invention se rapporte à un dispositif électronique porte-cartes connecté conçu pour contenir et gérer l’utilisation d’une pluralité de cartes telles que des cartes de paiement. L’invention se rapporte aussi à un système de gestion de cartes dans lequel s’intègre le dispositif porte-cartes.

De nos jours, le nombre de cartes qu’une personne porte avec elle dans sa vie quotidienne est élevé et ce nombre a tendance à croître. Ces cartes sont par exemple des cartes de paiement, des cartes de fidélité ou de club, des cartes d’accès et autres et des documents personnels importants comme une carte d’identité, un permis de conduire, une carte d’assuré social, etc.

Le format de carte le plus largement répandu est le format « ID-1 », dit « format carte bancaire », qui est défini par la norme internationale ISO/CEI 7810. Le format « ID-1 » s’est imposé pour les cartes de paiement, à bande magnétique et/ou puce électronique, telles que les cartes bancaires (cartes de crédit, cartes de débit, cartes de retrait, etc.), les cartes cadeaux, les cartes de carburant et autres.

Le format carte bancaire a tendance à se généraliser et différents documents sensibles, comme une carte d’identité, une carte d’assuré social et autres, sont également fournis sous ce format et intègre une puce électronique d’authentification des données.

La multiplication des cartes pose à leur détenteur un certain nombre de difficultés liées notamment à leur rangement et gestion, au suivi de leur utilisation et à la sécurité. En cas de perte ou de vol d’une carte, en particulier d’une carte de paiement, le préjudice subi par le détenteur peut être important.

Différents dispositifs électroniques sont connus dans l’état de la technique et apportent des réponses partielles aux difficultés rencontrées par les détenteurs de cartes.

Ainsi, le document WO2019021050A1 divulgue un portefeuille intelligent muni d’un module de géolocalisation de type « GPS », de modules de communication de type « Bluetooth » et « WiFi », ainsi que d’une carte téléphonique d’identification d’abonné dite carte « SIM », d’une caméra et d’un capteur de luminosité. Ce dispositif est conçu pour des cartes bancaires et autres. La carte SIM autorise une connexion au réseau téléphonique de communication de données pour la transmission des coordonnées de géolocalisation. La caméra et son capteur de luminosité associé permettent de prendre des images des carte bancaires, ces images étant destinées à être sauvegardées dans un téléphone intelligent appairé, dit « smartphone », ou un serveur informatique distant.

Le document CN106174948A décrit également un portefeuille intelligent appairé avec un smartphone et qui est conçu pour contenir des cartes bancaires. Le dispositif comporte un module de géolocalisation « GPS ». L’ouverture du dispositif est autorisée à travers une reconnaissance d’empreinte.

Le document US10185955B1 divulgue un boîtier électronique conçu pour contenir plusieurs cartes bancaires. Le boîtier comporte des moyens de communication sans contact de type « NFC » et permet ainsi une transaction sans contact entre une carte bancaire sélectionnée et un terminal de paiement.

Il est également connu dans l’état de la technique un système de carte universelle, comme celui divulgué par le document US9129270B2, destiné à émuler une pluralité de cartes bancaires. Dans ce système, les données des différentes cartes sont mémorisées dans la carte universelle qui peut être configurée pour émuler une carte sélectionnée. La carte universelle est appairée avec un smartphone et des fonctions de géolocalisation et de suivi et gestion des cartes émulées sont prévues.

Par ailleurs, le document GB2387930A décrit un portefeuille équipé d’un assistant électronique. L’assistant électronique comprend un clavier, un écran et une unité électronique de traitement avec des moyens de mémorisation de données. L’assistant électronique permet un suivi financier à travers des saisies de différentes opérations de paiement effectuées avec des cartes bancaires. Aucun moyen de communication de données et de connectivité réseau n’est prévu dans ce dispositif.

Il est souhaitable de procurer un dispositif porte-cartes connecté d’un type nouveau et un système de gestion de cartes associé autorisant une utilisation aisée et confortable d’une pluralité de cartes, tout en apportant une gestion complète de l’utilisation de celles-ci et des fonctions de sécurité incluant notamment des alertes et la géolocalisation.

Selon un premier aspect, l’invention concerne un dispositif électronique porte-cartes connecté comprenant une pluralité de compartiments de rangement destinés au rangement d’une pluralité de cartes. Conformément à l’invention, le dispositif électronique porte-cartes comprend une pluralité de capteurs de couleur associés respectivement aux compartiments de rangement, les capteurs de couleur étant agencés de façon à fournir des signatures chromatiques détectées pour chacun des compartiments de rangement, et les signatures chromatiques détectées étant utilisées pour déterminer la présence ou l’absence d’une carte dans un compartiment de rangement par une comparaison avec des signatures chromatiques de référence.

Le dispositif électronique porte-cartes de l’invention est adaptée pour la gestion de tous types de cartes, de différentes natures et ayant un format normalisé ou pas. Ainsi, une carte pourra être une carte bancaire, carte de paiement, carte de club, carte de fidélité, carte nationale d'identité et/ou un autre document sensible sous forme de carte. Des compartiments de différentes dimensions pourront être prévus dans le dispositif électronique porte-cartes pour y loger des cartes de formats différents. Le dispositif pourra prendre différentes formes selon l’application, par exemple, un étui, un porte-documents, un sac à main, une mallette, une valise et autre contenant fixe ou en mobilité, de tout format, matière et dimensions. Par ailleurs, dans certaines formes de réalisation, le dispositif électronique pourra être prévu pour le rangement et la gestion de cartes sous la forme d’objets colorés sensiblement planaires et n’ayant pas nécessairement une forme rectangulaire.

Selon une caractéristique particulière, le dispositif électronique porte-cartes comprend des moyens de connexion à au moins un réseau de communication des données et des moyens de géolocalisation coopérant avec au moins un système de géolocalisation du type constellation de satellites, du type positionnement par réseau d’objets connectés et/ou du type positionnement par bornes « WiFi » et/ou « Bluetooth ».

Selon une autre caractéristique particulière, le dispositif électronique porte-cartes comprend des moyens de communication locale de données de type « Bluetooth » pour un appairage avec un dispositif informatique.

Selon encore une autre caractéristique particulière, le dispositif électronique porte-cartes comprend des moyens de connexion à un réseau téléphonique de communication de données à haut débit et des moyens de communication « WiFi » configurables en borne d’accès « WiFi » au réseau Internet.

Selon encore une autre caractéristique particulière, le dispositif électronique porte-cartes comprend un boîtier rigide ayant un verrou électrique commandable à distance ou un boîtier formé de deux coques rigides articulées rabattables, et comprend une carte électronique de commande, un verrou électrique commandable à distance, un écran tactile, un connecteur de type « USB » ou « microUSB », et/ou des moyens d’alimentation électrique ayant une batterie électrique rechargeable par induction électrique et/ou par connexion filaire à un réseau d’alimentation électrique.

Selon encore une autre caractéristique particulière, la carte électronique de commande du dispositif électronique porte-cartes comprend un coprocesseur cryptographique et des moyens sécurisé de stockage en mémoire d’au moins une clé de cryptage.

Selon un autre aspect, l’invention concerne aussi un ensemble appairé comprenant un dispositif informatique et au moins un dispositif électronique porte-cartes tel que décrit brièvement ci-dessus, le dispositif informatique et le dispositif électronique porte-cartes étant appairés à travers une liaison de communication locale, et le dispositif informatique hébergeant une application logicielle dédiée à la gestion et à l’exploitation du dispositif électronique porte-cartes.

Selon une caractéristique particulière, le dispositif informatique dans l’ensemble appairé est un téléphone intelligent dit « smartphone », une tablette informatique ou un ordinateur, et/ou le dispositif informatique et/ou le dispositif électronique porte-cartes comportent des moyens de détection d’éloignement agencés de façon à émettre une alerte en cas d’un éloignement détecté entre ces dispositifs.

Selon un autre aspect, l’invention concerne aussi un système de gestion de cartes comprenant au moins un serveur informatique relié à travers un réseau de communication de données de type Internet à une pluralité de dispositifs porte-cartes décrits brièvement ci-dessus et/ou une pluralité d’ensembles appairés décrits brièvement ci-dessus, le serveur informatique hébergeant un module logiciel système qui gère une pluralité de comptes d’utilisateur auxquels sont associés les dispositifs porte-cartes et/ou les ensembles appairés, et/ou comprenant une unité de stockage de données dans laquelle des données d’utilisateur sont stockées de manière sécurisée.

Selon une caractéristique particulière, le système de gestion de cartes comprend un module logiciel d’exploitation de données d’utilisateur, le module logiciel étant chargé de traiter des données d’utilisateur disponibles et de restituer celles-ci sous la forme de documents numériques directement utilisables par l’utilisateur, les documents numériques comprenant des tableaux, des relevés, des fiches, des notes et/ou d’autres documents, et les données d’utilisateur comprenant des données fournies par au moins un dispositif porte-cartes de l’utilisateur et relatives à l’utilisation des cartes, des données d’organismes auxquels sont rattachées les cartes et récupérées par le système de gestion de cartes à travers des interfaces de type API, des données saisies par l’utilisateur et associées à son compte d’utilisateur et/ou des données d’application logicielle d’agenda d’utilisateur installée dans le dispositif informatique de l’utilisateur et/ou auxquelles le système de gestion de cartes a accès.

D’autres avantages et caractéristiques de la présente invention apparaîtront plus clairement à la lecture de la description détaillée ci-dessous de plusieurs formes de réalisation particulières de l’invention, en référence aux dessins annexés, dans lesquels :

La Fig.1 est une vue d’ensemble simplifiée d’une forme de réalisation particulière du système de gestion de cartes selon l’invention.

La Fig.2 est une première vue en perspective d’une forme de réalisation particulière d’un dispositif porte-cartes selon l’invention.

La Fig.3 est une deuxième vue en perspective du dispositif porte-cartes de la Fig.2.

La Fig.4 est une troisième vue en perspective du dispositif porte-cartes de la Fig.2.

La Fig.5 est un diagramme explicatif relatif à l’identification des cartes dans les compartiments de rangement à partir de signatures chromatiques fournies par des capteurs de couleur.

La Fig.6 est un bloc-diagramme simplifié d’une carte électronique de commande incluse dans le dispositif porte-cartes.

La Fig.7 est un premier algorithme simplifié d’un processus de commande mis en œuvre dans le dispositif porte-cartes pour l’identification des cartes dans les compartiments de rangement.

La Fig.8 est un deuxième algorithme simplifié du processus de commande mis en œuvre dans le dispositif porte-cartes pour l’identification des cartes dans les compartiments de rangement.

La Fig.9 est un bloc-diagramme simplifié relatif à la gestion de zones sûres par le processus de commande mis en œuvre dans le dispositif porte-cartes.

La Fig.10 est un bloc-diagramme simplifié montrant un exemple illustratif d’un traitement de données d’utilisateur effectué par un module logiciel d’exploitation de données d’utilisateur compris dans le système de gestion de cartes de l’invention.

En référence à la Fig.1, le système de gestion de cartes SGC est déployé à travers au moins un réseau de communication IT, comme l’Internet, et comporte notamment une pluralité de dispositifs porte-cartes connectés DEC, qui appartiennent à des utilisateurs UR du système, et au moins un serveur informatique SRC.

Les dispositifs porte-cartes connectés DEC des utilisateurs UR sont appairés respectivement avec des dispositifs informatiques des utilisateurs UR, typiquement leurs smartphones SPH, mais aussi leurs tablettes informatiques ou ordinateurs.

Dans la suite, pour la commodité de la description, il est considéré que le dispositif porte-cartes DEC d’un utilisateur est appairé au smartphone SPH de celui-ci, sauf s’il est indiqué autrement.

Chaque smartphone SPH héberge une application logicielle dédiée APPLI qui est destinée à la gestion du dispositif porte-cartes DEC apparié et qui supporte les fonctionnalités du dispositif, y compris sa configuration initiale ou paramétrage. La connectivité d’appairage entre le dispositif porte-cartes DEC et le smartphone SPH est assurée typiquement par une liaison locale de communication de données BL de type « Bluetooth ». L’application dédiée APPLI échange des données avec un logiciel système SW hébergé dans le serveur informatique SRC. Une liaison de communication de données est établie à cette fin entre le smartphone SPH et le serveur informatique SRC, à travers un réseau téléphonique de communication de données et le réseau IT. Le logiciel système SW assure notamment la commande du fonctionnement général du système de gestion de cartes SGC à travers l’exécution d’instructions de code et un stockage des données des utilisateurs.

Le système de gestion de cartes SGC utilise des ressources matérielles et logicielles qui sont accessibles à travers le réseau IT. Dans cet exemple particulier de réalisation, il est considéré que le système de gestion de cartes DCS utilisent des ressources matérielles et logicielles implantées dans un service d’informatique en nuage SCP, dit « cloud » en anglais. Le logiciel système SW est ici implanté dans au moins un serveur informatique SRC du service d’informatique SCP. Plus précisément, le logiciel système SW est hébergé dans une unité de stockage de données DS formée d’un ou plusieurs disques durs dédiés au système SGC.

Le serveur informatique SRC comprend une unité de traitement UC (incluant un ou plusieurs processeurs ainsi que des mémoires mortes dites « ROM » et des mémoires vives de travail dites « RAM ») couplée à l’unité de stockage de données DS, un module de sécurité autonome HSM, pour « Hardware Security Module » en anglais, qui est dédié au stockage sécurisé de clés de cryptage, et des dispositifs matériels classiques tels des interfaces réseau NI et d’autres dispositifs non représentés. On notera que les clés de cryptage stockées dans le module HSM sont utilisées pour le cryptage notamment des liaisons de communication de données, compte-tenu des données sensibles liées aux cartes de paiement qui sont gérées par le système SGC.

Le logiciel système SW comprend différents modules logiciels MGT nécessaires au fonctionnement général du système SGC selon l’invention, ces modules logiciels MGT ayant à charge notamment la validation et l’installation de comptes utilisateur (éventuellement à travers les procédures dites « KYC » pour « Know Your Customer » en anglais, selon la réglementation), ainsi que la gestion générale de ces comptes et des données d’utilisation, et la sécurité des communications à travers le réseau IT.

Le logiciel système SW comprend également un module logiciel WP d’implémentation d’une plateforme web WP à travers laquelle un administrateur ADMIN et les utilisateurs UR du système SGC peuvent se connecter à leurs comptes à l’aide de leurs dispositifs informatiques respectifs, typiquement, un smartphone, une tablette informatique ou un ordinateur.

L’utilisateur UR a accès aux données et fonctionnalités de son compte à travers l’application dédiée APPLI, comme indiqué plus haut, mais aussi à travers une connexion à la plateforme web WP au moyen du navigateur internet installé dans un dispositif informatique et d’une adresse web « URL » (pour « Uniform Resource Locator » en anglais). L’utilisateur UR peut ainsi par ces deux moyens interagir avec le système SGC pour accéder, par exemple, à un tableau de bord de gestion de son dispositif porte-cartes DEC et à différents relevés et autres documents numériques concernant l’utilisation de ses cartes, et à d’autres fonctionnalités comme la géolocalisation du dispositif porte-cartes, le blocage d’une carte et d’autres fonctions. L’administrateur ADMIN peut accéder à son compte sur la plateforme web WP au moyen d’un navigateur internet, ou à travers une application de gestion et une liaison de communication de données dédiée.

Dans certaines applications, le système de gestion de cartes SGC selon l’invention pourra être connecté et échanger des données avec des systèmes informatiques SRB de différents organismes ayant émis des cartes gérées par le système SGC, comme des banques, des services de paiement, des organismes d’assurance maladie et autres. Par exemple, dans une forme de réalisation particulière, le système SGC aura accès à des données de ses utilisateurs UR dans les systèmes informatiques SRB, à travers des interfaces API, pour « Application Programing Interface » en anglais, de ces systèmes SRB. Les données obtenues d’un système informatique SRB d’organisme financier seront typiquement des données d’utilisation des cartes de paiement comme des montants de dépenses, des soldes, etc., et seront utilisées par le système SGC pour compléter et/ou consolider ses propres données d’utilisation des cartes.

De manière générale, on notera que l’ensemble des données de chaque utilisateur UR du dispositif porte-cartes DEC et du système de gestion de carte SGC selon l’invention sont stockées dans l’unité de stockage de données DS en conformité avec la réglementation européenne RGPD, pour « Règlement Général pour la Protection des Données », en vigueur depuis le 25 mai 2018. L’utilisateur UR dispose des droits de consultation et rectification des données le concernant en conformité avec la réglementation RGPD, et du droit à l’effacement définitif de ses données dit « droit à l’oubli ». Les données d’utilisateurs seront de préférence stockées de manière sécurisée (si nécessaire, avec cryptage) dans l’unité de stockage de données DS. Typiquement, les données d’utilisateur comprendront l’ensemble des données relatives aux cartes collectées par le système de gestion de cartes SGC, c’est-à-dire, essentiellement des données d’identification, de sécurité et d’utilisation des cartes. Les données d’utilisateur comprendront également des copies numériques de cartes et documents (carte d’identité, passeport, etc.) sauvegardées dans le système SGC, par exemple, des photographies des cartes et documents prises avec le smartphone SPH.

Dans le système de gestion de cartes SGC selon l’invention, des fonctions de sécurité sont prévues notamment pour avertir l’utilisateur UR d’un éloignement entre le dispositif porte-cartes DEC et le smartphone SPH, suite à un oubli, une perte, un vol et toutes autres raisons, de l’absence d’une carte dans le dispositif porte-cartes DEC. Ces fonctions de sécurité aident l’utilisateur UR à récupérer l’appareil manquant, DEC ou SPH, ou bien la carte manquante, grâce à la géolocalisation et la traçabilité de l’utilisation des cartes. Ainsi, par exemple, l’éloignement entre le dispositif porte-cartes DEC et le smartphone SPH peut être détecté par l’interruption de la liaison locale « Bluetooth », BL, d’appairage entre les deux appareils. Un éloignement détecté peut donner lieu à une alerte par le smartphone SPH, à travers l’application APPLI, et à une autre alerte par le dispositif porte-cartes DEC. L’utilisateur UR est ainsi informé de l’absence de son dispositif porte-cartes DEC par le smartphone SPH et de l’absence de son smartphone SPH par le dispositif porte-cartes DEC. L’utilisateur UR pourra verrouiller à distance son dispositif porte-cartes DEC à travers l’application APPLI, ainsi que bloquer (« mise en opposition ») des cartes de paiement contenues dans le dispositif porte-cartes DEC.

Comme représenté à la Fig.1, la géolocalisation extérieure du dispositif porte-cartes DEC pourra être obtenue avec un ou plusieurs systèmes de positionnement par satellites SAT, tels que les constellations de satellites connues « GPS », « GALILEO », « GLONAS » et autres.

La récupération des coordonnées de géolocalisation du dispositif porte-cartes DEC par l’application APPLI est obtenue typiquement à travers un réseau de communication de données basse consommation RLP de type « LPWAN », pour « Low Power Wide Area Network » en anglais, auquel est connecté le dispositif porte-cartes DEC. Typiquement, le réseau RLP pourra par exemple être un réseau d’objets connectés tel que « Sigfox », « LoRa », « NB-IoT » ou « LTE-M ».

Dans des variantes de réalisation, la géolocalisation extérieure du dispositif porte-cartes DEC pourra être assurée par le réseau RLP de type « LPWAN », dans la mesure où le service de géolocalisation extérieure fourni par ce réseau a la précision voulue pour l’application.

Comme représenté aussi à la Fig.1, la géolocalisation intérieure du dispositif porte-cartes DEC pourra être obtenue à l’aide de bornes BBL de type « WiFi » présentes dans les locaux. Des bornes (non représentées) de type « BLE », pour « Bluetooth Low Energy » en anglais, pourront aussi être utilisées dans certaines applications pour davantage de précision. En variante, la géolocalisation intérieure du dispositif porte-cartes DEC pourra aussi être assurée par le réseau RLP de type « LPWAN », lorsque le service de géolocalisation intérieure fourni par ce réseau a la précision voulue pour l’application.

Dans d’autres formes de réalisation de l’invention, le dispositif porte-cartes DEC sera connecté non pas à un réseau d’objets connectés basse consommation, comme le réseau RLP mentionnée ci-dessus, mais directement au réseau Internet IT par une liaison de communication de données LA à travers le réseau téléphonique de communication de données à haut débit, au standard « 4G » ou « 5G » par exemple. Le dispositif porte-cartes DEC sera alors équipé d’une carte « SIM ». Dans ce cas, le dispositif porte-cartes DEC pourra échanger des données directement avec le serveur SRC par la liaison de communication de données LA, sans que celles-ci transitent par la liaison Bluetooth BL avec le smartphone SPH, et recevoir aussi les coordonnées de géolocalisation.

De plus, dans les formes de réalisation ci-dessus, compte-tenu de sa connexion au réseau téléphonique de communication de données à haut débit, le dispositif porte-cartes DEC pourra comprendre un mode de fonctionnement en borne d’accès « WiFi » et offrir à l’utilisateur, par exemple, un accès mondial au réseau Internet, grâce à des accords d’itinérance mondiale, dits « global roaming agreement » en anglais, entre le système SGC et des opérateurs mondiaux et nationaux de téléphonie mobile.

En référence aussi aux Figs.2 à 6, il est maintenant décrit plus particulièrement l’agencement général et l’architecture matérielle d’un exemple de réalisation du dispositif porte-cartes DEC.

Comme visible aux Figs.2 à 4, le dispositif porte-cartes DEC comporte ici deux coques rigides articulées C1 et C2 entre lesquelles sont agencés deux supports planaires intercalaires SC1 et SC2 formant des supports de rangement de cartes. Les coques C1, C2, sont rabattables de façon à contenir, une fois rabattues, les supports de rangement et les cartes dans une enceinte fermée. Avantageusement, les coques C1, C2, sont munies d’un blindage électromagnétique pour la protection des cartes (notamment, les cartes bancaires dites « sans contact ») et la sécurisation des données.

Les supports de rangement de cartes SC1, SC2, sont mobiles, en étant articulés sur le même axe d’articulation que les coques C1, C2. Comme visible à la Fig.3, chaque support de rangement de cartes SC1, SC2, comporte ici quatre compartiments de rangement de carte, à savoir, EP1 à EP4 dans le support SC1 et EP5 à EP8 dans le support SC2.

Une touche PW, à laquelle est associé à un voyant lumineux LD, ainsi qu’un connecteur PR de type « USB » ou « microUSB », visibles à la Fig.2, équipent le dispositif porte-cartes DEC. La touche PW est avantageusement multifonctionnelle, typiquement pour la fonction de commande marche/arrêt du dispositif porte-cartes DEC et/ou la fonction d’appairage par liaison Bluetooth avec le smartphone SPH et autres fonctions. Le connecteur PR est utilisé typiquement pour la recharge électrique de la batterie électrique du dispositif porte-cartes DEC. Le connecteur PR pourra aussi être utilisé pour une liaison filaire de communication de données entre le dispositif porte-cartes DEC et un dispositif informatique comme un ordinateur, une tablette ou un smartphone.

Un verrou électrique VE du dispositif porte-cartes DEC est prévu et agencé dans les coques C1, C2. Un capteur d’ouverture/fermeture COF est également intégré dans le dispositif porte-cartes DEC, pour déclencher certaines fonctions d’usage en fonction de l’état ouvert ou fermé du dispositif. Avantageusement, le verrou électrique VE est prévu pour autoriser un verrouillage à distance du dispositif porte-cartes DEC.

Des cartes électroniques, par exemple de type « PCB », non visibles dans les Figs.2 à 4, supportent les différents composants électroniques nécessaires au fonctionnement du dispositif porte-cartes DEC. Ces cartes électroniques sont logées à l’intérieur des coques C1, C2.

Comme montré aux Figs.3 et 4, un écran tactile DY est agencé dans la coque C1 et facilite les interactions entre l’utilisateur et le dispositif porte-cartes DEC. Ainsi, à travers l’écran tactile DY, l’utilisateur pourra être guidé pour accéder aux informations recherchées à travers différents menus. Il pourra aussi, par exemple, saisir les montants de dépenses effectuées avec ses cartes de paiement.

Conformément à l’invention, le dispositif porte-cartes DEC est équipé également de moyens de détection de cartes qui identifient les cartes et détectent leur présence ou leur absence dans les compartiments de rangement. Des compartiments de rangement sont respectivement affectés aux cartes lors d’une phase d’initialisation et la présence ou l’absence des cartes dans leurs compartiments de rangement respectifs peut ainsi être détectée par le dispositif porte-cartes DEC. Les erreurs de rangement des cartes peuvent aussi être détectées. Le dispositif porte-cartes DEC a donc ainsi la capacité de suivre l’utilisation de chacune des cartes à partir d’évènements d’extraction/rangement des cartes dans les compartiments, évènements qui sont horodatés et géolocalisés, et de détecter des anomalies génératrices d’alarmes, par exemple, l’absence d’une carte dans son compartiment dans le cas d’un oubli, d’une perte ou d’un vol de celle-ci.

Dans l’invention, les cartes sont identifiées par leurs signatures chromatiques respectives. L’entité inventive a constaté que les cartes se distinguent entre elles généralement par des visuels colorés très différents, les émetteurs de carte cherchant à différencier visuellement leurs cartes de celles des concurrents. Il est donc possible d’identifier de manière fiable les différentes cartes contenues dans le dispositif porte-cartes DEC à partir de leurs signatures chromatiques respectives.

Les moyens de détection de cartes comprennent une pluralité de capteurs de couleur, ici huit capteurs de couleur CS1 à CS8, visibles aux Figs.3 et 4. Chacun des capteurs de couleur CS1 à CS8 est de préférence un composant électronique intégré comprenant typiquement plusieurs photodiodes associées à des filtres colorés (non représentés) et une diode blanche électroluminescente (non représentée). La diode blanche électroluminescente a pour fonction d’éclairer le compartiment / carte pour la détection de couleur.

Les capteurs de couleur CS1 à CS4 détectent les cartes dans les compartiments de rangement EP1 à EP4 du support de rangement de cartes SC1. Les capteurs de couleur CS5 à CS8 détectent les cartes dans les compartiments de rangement EP5 à EP8 du support de rangement de cartes SC2.

Pour réaliser les opérations de détection de cartes indiquées ci-dessus, le dispositif porte-cartes DEC doit pouvoir discriminer trois états différents pour chaque compartiment de rangement, à savoir, un premier état qui est celui du compartiment vide, un deuxième état qui est celui du compartiment contenant la carte qui lui a été attribuée initialement par l’utilisateur et un troisième état qui est celui du compartiment contenant une autre carte que celle qui lui a été attribuée par l’utilisateur.

Le premier état est détecté lorsque la signature chromatique lue correspond à une première signature chromatique mémorisée de compartiment vide qui a été lue précédemment, lors d’une initialisation, pour le compartiment considéré. Le deuxième état est détecté lorsque la signature chromatique lue correspond à une deuxième signature chromatique mémorisée de compartiment plein valide qui a été lue précédemment, lors d’une initialisation, pour le compartiment considéré contenant la carte attribuée. Le troisième état est détecté lorsque la signature chromatique lue ne correspond à aucune des première et deuxième signatures chromatiques mémorisées.

A la Fig.6, il est considéré à titre d’exemple illustratif que le dispositif porte-cartes DEC contient quatre cartes C1, C2, C3 et C4 que l’utilisateur a choisi de ranger respectivement dans les compartiments EP3, EP6, EP5 et EP2.

Une phase d’initialisation lancée précédemment par l’utilisateur a permis de lire et mémoriser des signatures chromatiques de compartiment vide SV1 à SV8 fournies par les capteurs de couleur CS1 à CS8 pour les compartiments EP1 à EP8, respectivement. Une ou plusieurs autres phases d’initialisation lancées précédemment par l’utilisateur ont permis de lire et mémoriser des signatures chromatiques de compartiment plein valide S1, S2, S3 et S4 fournies par les capteurs de couleur CS3, CS6, CS5 et CS2 pour les compartiments EP3, EP6, EP5 et EP2 contenant les cartes C1, C2, C3 et C4, respectivement.

Lors d’une opération de détection de cartes lancée par un logiciel embarquée de commande du dispositif porte-cartes DEC, si les cartes C1, C2, C3 et C4 sont présentes dans leurs compartiments EP3, EP6, EP5 et EP2, les capteurs de couleur CS3, CS6, CS5 et CS2 associés à ces compartiments lisent les signatures chromatiques de compartiment plein valide S1, S2, S3 et S4 qui indiquent que les cartes sont bien dans leurs compartiments respectifs. Pendant la même opération de détection de cartes, les capteurs de couleur CS1, CS4, CS7 et CS8 associés aux compartiments vides EP1, EP4, EP7 et EP8 lisent les signatures chromatiques de compartiment vide SV1, SV4, SV7 et SV8 qui indiquent que ces compartiments sont effectivement vides. Dans cette opération de détection de cartes, les signatures chromatiques qui sont lues pour chacun des compartiments EP1 à EP8 sont celles attendues par le logiciel embarqué de commande et aucune anomalie n’est signalée à l’application logicielle APPLI par le dispositif porte-cartes DEC.

Dans un autre cas, à titre d’exemple, si l’utilisateur s’est trompé en rangeant les cartes C1, C2, C3 et C4 dans les compartiments, les signatures chromatiques qui sont lues pour chacun des compartiments EP1 à EP8 ne sont pas celles attendues, mais le nombre de signatures chromatiques de compartiment vide reste identique, égal à quatre dans cet exemple. Le logiciel embarqué de commande peut donc décider qu’il s’agit d’une erreur de rangement et cette anomalie peut alors être signalée à l’application logicielle APPLI par le dispositif porte-cartes DEC.

Dans encore un autre cas, à titre d’exemple, si une des cartes C1 à C4 est absente, l’absence de cette carte est détectée par le nombre de signatures chromatiques de compartiment vide qui s’accroît d’une unité et passe à cinq dans cet exemple. Le logiciel embarqué de commande du dispositif porte-cartes DEC peut alors signaler cette absence à l’application logicielle APPLI. Si les trois cartes présentes sont correctement rangées dans leurs compartiments respectifs, l’identification de la carte manquante est également possible et peut aussi être fournie à l’application logicielle APPLI.

De manière générale, dans l’exemple de réalisation décrit ici, du système de gestion de cartes SGC et du dispositif porte-cartes DEC, il est considéré que l’identification d’une carte ne peut être faite que par le capteur de couleur auquel elle a été associée lors d’une opération d’initialisation et qui a délivré la signature chromatique mémorisée pour cette carte rangée dans son compartiment.

L’approche technique ci-dessus prend en compte, et permet de gérer, une disparité de sensibilité importante entre les capteurs de couleur. En effet, avec une disparité importante, deux capteurs de couleur distincts fourniront des signaux de sortie sensiblement très différents pour une même carte. Il est donc nécessaire d’appairer un capteur à une carte en attribuant à la carte un compartiment de rangement lié à ce capteur. Une approche technique différente pourra être adoptée dans le cas d’une disponibilité de capteurs de couleur avec une très faible disparité de sensibilité. Dans un tel cas, il n’est plus nécessaire d’affecter une carte à un capteur de couleur particulier et une carte peut être identifiée sans qu’il soit nécessaire qu’elle soit rangée dans un compartiment attribué.

En référence maintenant plus particulièrement à la Fig.6, il est décrit ci-dessous en détail une architecture électronique générale du dispositif porte-cartes DEC, correspondant à la forme de réalisation particulière décrite ici du dispositif. Cette architecture électronique comprend un circuit électronique, repéré 2 à la Fig.6, qui est supporté typiquement sur deux cartes électroniques de type « PCB » logées à l’intérieur des coques rigides articulées C1, C2, susmentionnées.

On notera que le circuit électronique 2 est contenu de manière étanche dans les coques C1, C2 du dispositif porte-cartes DEC, ainsi que les autres composants associés, typiquement avec un indice de protection IP5, pour une protection contre les projections d’eau et contre la poussière.

Le circuit électronique 2 comprend une unité de commande 20, un bus de communication interne BB_I2Cde type I²C, un premier module émetteur/récepteur RF de communication locale 21, un deuxième module émetteur/récepteur RF de communication distante 22, un module de géolocalisation par satellites 23, un module de capteurs de couleur 24 et une unité d’alimentation électrique 25.

L’unité de commande 20 se présente typiquement sous la forme d’un microcontrôleur comprenant un microprocesseur µP, un coprocesseur cryptographique CP, un module de sécurité autonome K, une mémoire de donnée non volatile 200 de type E2PROM, une mémoire de données volatile 201 de type RAM, une mémoire programme non volatile 202 de type FLASH contenant un logiciel embarqué PROG, une interface d’entrées/sorties 203a, une interface d’écran tactile 203b, une interface d’entrées/sorties 203c et un port USB.

Le logiciel embarqué PROG supporte le système d’exploitation du dispositif porte-cartes DEC et comprend différents modules logiciels qui gèrent l’ensemble du fonctionnement de celui-ci, de la couche matérielle à la couche applicative, ainsi que les échanges d’interface homme-machine et les liaisons et réseaux de communication de données. En particulier, le logiciel embarqué PROG comprend un module logiciel qui gère la configuration générale du dispositif, avec notamment les phases d’initialisation et les opérations de détection des cartes par le module de capteurs de couleur 24.

Le coprocesseur de cryptographie CP et le module de sécurité autonome K sont dédiés au cryptage des données sensibles notamment lors des échanges avec le smartphone SPH et le serveur informatique SRC. Le module de sécurité autonome K est un module de type HSM dédié au stockage sécurisé de clés de cryptage.

L’interface d’entrées/sorties 203a est un port d’entrées/sorties qui relient à l’unité de commande 20, la touche PW et le voyant lumineux LD associé (diode électroluminescente), les moyens d’ouverture/fermeture VE, le capteur d’ouverture/fermeture COF et un haut-parleur BZ. Des entrées/sorties de l’interface 203a sont utilisées aussi pour la commande de l’unité d’alimentation électrique 25.
Le capteur d’ouverture/fermeture COF est typiquement formé d’un capteur à effet Hall associé à un aimant. Le haut-parleur BZ est un module haut-parleur miniature intégrable sur un circuit imprimé de type PCB et permet au dispositif porte-cartes DEC d’émettre des alertes audios.

L’interface d’écran tactile 203b est typiquement une interface adaptée pour l’écran DY intégré dans le dispositif porte-cartes DEC, typiquement un module écran couleur de type LCD/TFT tactile.

L’interface d’entrées/sortie 203c est un port d’entrées/sorties de données qui est configuré avec une couche logicielle pour un fonctionnement en interface de bus de type I²C. L’interface 203c est reliée au bus de communication interne BB_I2C.

Le premier module émetteur/récepteur RF 21 est ici un module combiné de communication radio WiFi / Bluetooth comportant une interface I²C pour une connexion sur le bus de communication interne BB_I2C. La fonction WiFi comprendra le mode dit « WPS », pour « WiFi Positioning System » en anglais, afin d’autoriser le positionnement à l’intérieur de bâtiments équipés de bornes WiFi. La fonction Bluetooth sera, par exemple, du type « Bluetooth Smart 4.2 » avec les profils dits « PXP » et « GATT », pour la liaison BL avec le smartphone SPH et la détection de l’éloignement entre celui-ci et le dispositif porte-cartes DEC.

Le deuxième module émetteur/récepteur RF 22 est ici un module de communication radio de type LPWAN, comme susmentionné, comportant une interface I²C pour une connexion sur le bus de communication interne BB_I2C. Typiquement, il sera utilisé un module combiné LoRa/Sigfox. La liaison de communication de données établie avec le réseau d’objets connectés LoRa ou Sigfox permettra notamment de recevoir les coordonnées de géolocalisation extérieure par satellites. Eventuellement, la géolocalisation extérieure pourra être assurée, non pas par satellites, mais par le réseau d’objets connectés LoRa ou Sigfox, si la précision fournie par celui-ci est compatible avec l’application.

Dans une autre forme de réalisation évoquée dans la description de la Fig.1, le deuxième module émetteur/récepteur RF 22 sera un module de communication radio WAN, du type 4G, ou 5G, avec une interface de carte SIM, et une interface I²C pour une connexion sur le bus de communication interne BB_I2C. Dans cette forme de réalisation, le dispositif porte-cartes DEC est connecté au réseau internet IT (liaison LA à la Fig.1) à travers le réseau téléphonique de communication de données 4G, ou 5G. Dans ce cas, les coordonnées de géolocalisation extérieure pourront être reçues par la liaison de communication haut débit LA. En variante, les coordonnées de géolocalisation extérieure seront transmises à travers un réseau d’objets connectés NB-IoT ou LTE-M déployé par l’opérateur de téléphonie mobile. Eventuellement, la géolocalisation extérieure pourra être assurée, non pas par satellites, mais par le réseau d’objets connectés NB-IoT ou LTE-M, si la précision fournie par celui-ci est compatible avec l’application.

De plus, dans cette autre forme de réalisation, compte-tenu de la connexion du dispositif porte-cartes DEC au réseau téléphonique de communication de données à haut débit, le dispositif porte-cartes DEC pourra comprendre un mode de fonctionnement en borne d’accès WiFi pour octroyer à l’utilisateur un accès mondial au réseau Internet. Le mode WiFi procuré par le module émetteur/récepteur RF 21 et la liaison haut débit procurée par le module émetteur/récepteur RF 22 en 4G, ou 5G, permettront de fournir cette fonctionnalité de borne d’accès WiFi.

Le module de géolocalisation par satellites 23 est de type GNSS, pour « Global Navigation Satellite System » en anglais, et permet une géolocalisation extérieure par différentes constellations de satellites (GPS, GALILEO, …).

Le module de capteurs de couleur 24 est typiquement supporté sur une carte de circuit imprimé de type PCB et comprend la pluralité des capteurs de couleur, à savoir, CS1 à CS8 dans cette forme de réalisation.

L’unité d’alimentation électrique 25 est interfacée avec l’unité de commande 20 et comprend une batterie rechargeable 250, des convertisseurs de tension (non représentés) et une unité réceptrice de charge à induction 251.

La batterie rechargeable 250 est typiquement une batterie de type « LiPo » (Lithium-Polymère). La charge de la batterie 250 peut être effectuée par induction ou au moyen d’un chargeur électrique AC-DC standard, non représenté, qui est enfichable sur la prise PR du dispositif porte-cartes DEC. La prise PR est typiquement au format USB ou microUSB et est reliée au port USB de l’unité de commande 20.

L’unité réceptrice de charge à induction 251 est un dispositif connu de l’homme du métier et pourra ne pas être présente dans des formes de réalisation plus économiques. L’unité 251 est associée à une unité émettrice de charge à induction 252 qui est typiquement incluse dans un support de charge (non représenté) apte à recevoir le dispositif porte-cartes DEC. L’unité émettrice 252 est par exemple alimentée en énergie à partir du secteur d’alimentation électrique alternatif par un chargeur AC-DC 253, ou est alimentée par un réseau d’alimentation électrique continu à basse tension comme celui d’un véhicule automobile. Lorsque le dispositif porte-cartes DEC est posé sur le support de charge, des moyens inclus dans l’unité 252 détecte sa présence et active un transfert d’énergie de charge par une onde d’induction IND.

L’architecture électronique décrite ci-dessus pour l’unité de commande 20 fait appel à un bus I²C. Bien entendu, il s’agit là d’une forme de réalisation particulière décrite à titre d’exemple. D’autres standards de bus conviendront mieux pour certaines applications et pourront être utilisés dans le cadre de l’invention.

En référence maintenant plus particulièrement à la Fig.7, il est décrit un algorithme de traitement IN/OUT_CARD_EPp pour le suivi d’évènements de détection de carte relativement à des compartiments de rangement EPp auxquels ont été attribuées des cartes Cn. Comme visible à la Fig.7, l’algorithme IN/OUT_CARD_EPp comprend des étapes E1 à E10.

A l’étape E1, une carte considérée Cn est dans un état Cn_in_EPp correspondant à un état de rangement de la carte Cn dans son compartiment respectif EPp.

L’étape E2 est une étape conditionnelle destinée à détecter un état Cn_out_EPp correspondant à un état de non rangement de la carte Cn dans son compartiment respectif EPp. Tant que l’état Cn_out_EPp n’est pas détecté (sortie N à l’état actif « 1 »), le processus de commande boucle sur l’étape E1 en attente d’un évènement d’extraction de carte.

Lorsque l’état Cn_out_EPp est détecté (sortie Y à l’état actif « 1 »), après une extraction effective de la carte Cn hors du compartiment EPp, le processus exécute l’étape E3 qui émet une notification Ntf(Cn_out, D, H, L) indiquant un évènement de détection Cn_out, à savoir, l’absence constatée de la carte Cn dans son compartiment EPp, ainsi que l’horodatage D (date) et H (heure) et la géolocalisation L de l’événement. La notification Ntf(Cn_out, D, H, L) est stockée en mémoire et le processus déclenche un délai d’attente DL1 pendant lequel il attend le retour de la carte Cn dans son compartiment EPp.

Les étapes conditionnelles E4 et E5 correspondent à cette attente du retour de la carte Cn dans son compartiment EPp. A l’étape E4, tant que la carte Cn est absente du compartiment EPp, l’état de compartiment vide EPp=Empty est actif (sortie Y= « 1 »). L’étape E5 vérifie si le temps écoulé t depuis l’évènement de détection Cn_out est supérieur au délai d’attente DL1. Si ce n’est pas le cas (sortie N= « 1 »), le processus boucle sur l’étape E4. Dans ce cas contraire (sortie Y= « 1 »), le délai d’attente DL1 est écoulé et le processus passe à l’étape E6 et émet une notification d’alerte Ntf(Cn_DL1, D, H, L) qui indique un évènement d’absence de carte Cn_DL1 à l’utilisateur, avec l’horodatage H, D, et la géolocalisation L. La notification d’alerte Ntf(Cn_DL1, D, H, L) est stockée en mémoire pour assurer la traçabilité.

Avec la réception de la notification d’alerte Ntf(Cn_DL1, D, H, L), l’utilisateur est prévenu de l’absence de sa carte Cn et peut procéder à des actions pour récupérer celle-ci et la ranger dans le compartiment EPp.

Si l’utilisateur ne retrouve pas sa carte Cn et que celle-ci est une carte de paiement, l’utilisateur peut déclencher un blocage de la carte Cn, dit « mise en opposition », qui est alors géré automatiquement par le processus. Le blocage de la carte Cn est géré à l’étape E7 avec une opération USER_LOCK_Cn lors de laquelle le processus transmet des données de blocage de carte à l’institution financière (cf. Fig.1, serveur SRB) émettrice de la carte Cn.

A l’étape E4, lorsque le processus détecte que l’état de compartiment vide EPp=Empty est inactif (sortie N= « 1 »), cet évènement est consécutif à un rangement de carte dans le compartiment EPp.

L’étape conditionnelle E8 permet au processus de vérifier que la carte rangée dans le compartiment EPp est bien la carte Cn. Si tel est le cas, l’état Cn_in_EPp est activé (sortie Y= « 1 ») et une notification Ntf(Cn_in, D, H, L) est émise à l’étape E9. Cette notification indique un évènement de détection Cn_in, à savoir, la présence constatée de la carte Cn dans son compartiment EPp, ainsi que l’horodatage D, H, et la géolocalisation L de l’événement, est stockée en mémoire par le processus. Le processus revient ensuite à l’étape E1 en attente d’une prochaine extraction de la carte Cn de son compartiment EPp.

A l’étape E8, si la carte rangée dans le compartiment EPp n’est pas la carte Cn (sortie N= « 1 »), le processus exécute l’étape E10 dans laquelle est émise une notification Ntf(Err_EPp, D, H, L) indiquant un évènement de détection d’erreur de compartiment Err_EPp, à savoir, la présence constatée dans le compartiment EPp d’une carte qui n’est pas la carte Cn, ainsi que l’horodatage D, H, et la géolocalisation L de l’événement. La notification d’erreur de compartiment Ntf(Err_EPp, D, H, L) est stockée en mémoire par le processus et donne lieu à une alerte à l’intention de l’utilisateur afin qu’il puisse rectifier son erreur.

La Fig.8 montre le suivi par un algorithme de traitement IN/OUT_CARD_EPq d’évènements de détection de carte relativement à des compartiments de rangement EPq auxquels aucune carte n’a été attribuée. Comme visible à la Fig.8, l’algorithme IN/OUT_CARD_EPq comprend deux étapes E11 à E12.

L’étape conditionnelle E11 vérifie en boucle l’état inoccupé EPq=Empty du compartiment EPq considéré. Tant que le compartiment EPq reste inoccupé (sortie « Y=1 »), le processus de commande boucle et l’étape E11 se répète. Dans le cas où une carte est rangée dans le compartiment EPq (sortie « N=1 »), le processus exécute l’étape E12 dans laquelle est émise une notification Ntf(Err_EPq, D, H, L) indiquant un évènement de détection d’erreur de compartiment Err_EPq, à savoir, la présence constatée dans le compartiment EPq d’une carte qui n’a pas à y être, ainsi que l’horodatage D, H, et la géolocalisation L de l’événement. La notification d’erreur de compartiment Ntf(Err_EPq, D, H, L) est stockée en mémoire par le processus et donne lieu à une alerte à l’intention de l’utilisateur afin qu’il puisse rectifier son erreur.

La Fig.9 montre une gestion différenciée LOC/ALT_REMOTE effectuée par le processus de commande selon que l’utilisateur se trouve ou pas dans une zone ou un périmètre déclaré sûr. L’utilisateur à la possibilité de déclarer certains lieux, par exemple son domicile, comme étant des lieux sûrs, de manière à désactiver certaines alertes dans un tel lieux et un périmètre défini autour de celui-ci. Par exemple, l’alerte d’éloignement entre le dispositif porte-cartes DEC et le smartphone SPH pourra être désactivée dans une zone sûre.

Ainsi, comme montré à la Fig.9, l’état logique d’un indicateur S_ZONE est détecté afin de déterminer une gestion adaptée au lieu. L’état logique de cet indicateur S_ZONE peut être défini par l’utilisateur lors de son arrivée dans un lieu, ou bien, peut être déterminé automatiquement par le processus à partir de déclarations précédentes mémorisées de l’utilisateur et de la géolocalisation.

Lorsque l’indicateur S_ZONE est à un état inactif (sortie « N=1 ») qui indique que le lieu n’est pas dans une zone sûre déclarée par l’utilisateur, le processus exécute différents modules de traitement IN/OUT_CARD, LOCA_DEC et ALT_REMOTE.

Le traitement IN/OUT_CARD est représenté par les algorithmes décrits plus haut en relation avec les Figs.7 et 8 et concerne le suivi des évènements de détection de carte relativement aux compartiments de rangement. Le traitement IN/OUT_CARD fait appel pour chaque nouvel évènement détecté à la géolocalisation extérieure ou intérieure du dispositif porte-cartes DEC qui est gérée par le module de traitement LOCA_DEC. L’exécution du traitement IN/OUT_CARD produit une notification Ntf lors de chaque évènement de détection qui intègre l’horodatage et la géolocalisation liée à l’évènement déterminée par le module LOCA_DEC. Des alertes pour l’utilisateur peuvent être associées aux notifications Ntf, comme déjà décrit.

Le module ALT_REMOTE est chargé de la détection d’éloignement entre le dispositif porte-cartes DEC et le smartphone SPH, notamment à travers la liaison Bluetooth BL (Fig.1) comme décrit précédemment. Le module LOCA_DEC est également sollicité lors d’un évènement de détection d’éloignement pour géolocaliser le lieu de l’évènement. Une notification Ntf correspondante incluant la géolocalisation et l’horodatage est émise lors de l’évènement de détection d’éloignement et est stockée en mémoire.

Bien entendu, le module LOCA_DEC pourra gérer des géolocalisations du dispositif porte-cartes DEC dans d’autres circonstances que celles indiquées ci-dessus. Ainsi, par exemple, l’utilisateur peut activer à tout moment une géolocalisation du dispositif porte-cartes DEC à travers son smartphone SPH. Une géolocalisation du dispositif porte-cartes DEC pourra aussi être lancée par le processus pour tout évènement porteur d’information pour les traitements, comme par exemple une ouverture du dispositif porte-cartes DEC détectée par le capteur d’ouverture/fermeture COF. Des notifications Ntf correspondantes incluant la géolocalisation et l’horodatage sont aussi émises pour ces évènements et sont stockées en mémoire.

Lorsque l’indicateur S_ZONE est à un état actif (sortie « Y=1 ») qui indique que le lieu est dans une zone sûre déclarée par l’utilisateur, le processus exécute les modules de traitement IN/OUT_CARD et LOCA_DEC de la même manière que décrit ci-dessus. Par contre, le module de traitement ALT_REMOTE est désactivé.

On notera qu’un module d’intelligence artificielle pourra être intégré et participer ou gérer totalement l’exécution des différents processus de traitement décrits plus haut. Ainsi, le module d’intelligence artificielle pourra exploiter l’historique des notifications d’évènement mémorisées pour extraire une connaissance qui est utilisée dans les processus de traitement sans avoir à solliciter l’utilisateur, par exemple, pour une détection automatique des zones sûres. D’une autre manière, si l’utilisateur n’a pas validé le pilotage de l’intelligence artificielle, des suggestions contextuelles pourront lui être faites par un assistant d’intelligence artificielle. Bien entendu, le module d’intelligence artificielle pourra apporter une contribution sensible à d’autres tâches non évoquées ici, mais dont l’homme du métier a connaissance, pour accroître les prestations du dispositif porte-cartes DEC et du système de gestion de cartes SGC selon l’invention.

En référence à la Fig.10, un module logiciel d’exploitation de données d’utilisateur MGT_DATA est implémenté dans le système de gestion de cartes SGC. Le module MGT_DATA traite les données disponibles de l’utilisateur, fournies par les différents processus de traitement collaborant dans le système de gestion de cartes SGC, et les restitue sous forme de tableaux, de fiches, notes, etc., directement accessibles et utilisables par l’utilisateur. Le module MGT_DATA gère une mise à jour en temps réel des tableaux, fiches, notes, etc.

Ainsi, le module MGT_DATA reçoit des données DATA_DEC fournies par le dispositif porte-cartes DEC, qui comprennent les notifications d’évènement Ntf décrites plus haut et liées à l’utilisation des cartes. Ces données DATA_DEC comprennent les données produites par les modules IN/OUT_CARD, LOC_DEC et ALT_REMOTE et des données DEC_EXP_DATA. Les données DEC_EXP_DATA sont des données saisies par l’utilisateur sur l’écran tactile DY et relatives notamment à des dépenses effectuées avec les cartes.

Le module MGT_DATA traite aussi des données DATA_ORG et des codes de sécurité CODE, ou clés numériques, par exemple, pour des validations de paiements effectués avec des cartes. Les données DATA_ORG sont typiquement des données d’organismes auxquels sont rattachées les cartes, comme par exemple des banques, des services de paiement, des organismes d’assurance maladie et autres. Les données DATA_ORG sont disponibles sur les serveurs informatiques SRB (Fig.1) à travers des interfaces API et récupérées typiquement par le logiciel système SW du système de gestion de cartes SGC.

De plus, le module MGT_DATA traitent des données DATA_WP, DATA_SPH et DATA_AGENDA. Les données DATA_WP et DATA_SPH sont des données saisies par l’utilisateur sur la plateforme web WP et sur son dispositif informatique connecté, tel que son smartphone SPH, et qui sont associées à son compte utilisateur. Les données DATA_AGENDA proviennent par exemple d’une application logicielle d’agenda installée dans le smartphone SPH de l’utilisateur et à laquelle l’application APPLI a accès ou d’une autre application logicielle d’agenda de l’utilisateur à laquelle le système de gestion de cartes a accès à travers le réseau Internet ou un autre réseau.

La Fig.10 montre à titre d’exemple différents tableaux TB_Cn, NT_Cn et TB_G, représentant des relevés, notes, etc., établis par le module MGT_DATA et qui sont accessibles à l’utilisateur à travers des menus et tableaux de bord de l’application APPLI et de son compte utilisateur sur la plateforme web WP.

Ainsi, les tableaux TB_Cn sont associés respectivement aux cartes Cn et montrent leur utilisation et des données de différents évènements. Par exemple, dans un tableau TB_Cn associé à une carte Cn sont disponibles des données OUT et IN correspondant aux mouvements de sortie/retour de la carte Cn dans son compartiment, des données D, H et L d’horodatage et de géolocalisation des évènements associés à la carte Cn, des données de dépenses EXP avec la carte Cn et une affectation ITEM de ces dépenses, et d’autres données comme des données ALT d’émission d’alerte, des données LOCK_Cn de blocage de carte et des données de code de sécurité CODE transmis, etc. Un lien hypertexte LINK est également intégré dans le tableau TB_Cn pour permettre à l’utilisateur de se rendre directement sur le site internet de l’organisme émetteur de la carte Cn s’il le souhaite.

Les tableaux NT_Cn sont par exemple ici des notes de frais associées à des évènements professionnels tels que des rendez-vous, des déplacements, des voyages, des séminaires et autres, ou des évènements personnels, lors desquels des cartes Cn ont été utilisées. Les données D/H/L relatives à ces évènements, comme des dates et des lieux associés à des géolocalisations, sont récupérées par le module MGT_DATA dans les données d’agenda DATA_AGENDA de l’utilisateur. Des croisements effectués par le module MDT_DATA, assisté si nécessaire par un module d’intelligence artificielle, entre les données d’agenda DATA_AGENDA et les données d’utilisation des cartes, disponibles sous forme ordonnées dans les tableaux TB_Cn, permettent au système de gestion de cartes SGC de fournir une note de frais NT_Cn associée à un évènement qui récapitule l’ensemble des dépenses effectuées avec une ou plusieurs cartes Cn, …, Cm (par exemple, carte personnelle, carte de carburant, carte prépayée d’entreprise, etc.). Comme autres exemples, les tableaux NT_Cn pourront être des relevés de points pour des cartes de fidélité, des décomptes de remboursements effectués par un organisme d’assurance maladie, des relevés de dépenses en devises étrangères et autres.

Le tableau TB_G est par exemple un tableau de bord de gestion générale du dispositif porte-cartes DEC. Par exemple, dans le tableau TB_Cn sont disponibles des données S_ZONE, ACTIVE/INACTIVE, D, H, L, et DIS_ALT_REMOTE/ EN_ ALT_REMOTE relatives à l’activation/désactivation du mode de zone sûre, l’horodatage, la géolocalisation et l’activation/désactivation de l’alerte d’éloignement. D’autres données DATA_ALT_REMOTE, DATA_LOC_DEC et DATA_LOCK_DEC sont également montrées à titre d’exemple dans le tableau TB_G est correspondent à des évènements d’alerte d’éloignement, de géolocalisation et de verrouillage à distance du dispositif porte-cartes DEC.

L’invention ne se limite pas aux formes de réalisation particulières qui ont été décrites ici à titre d’exemple. L’homme du métier, selon les applications de l’invention, pourra apporter différentes modifications et variantes entrant dans le champ de protection de l’invention.

Claims (10)

1. Dispositif électronique porte-cartes connecté comprenant une pluralité de compartiments de rangement destinés au rangement d’une pluralité de cartes, caractérisé en ce qu’il comprend une pluralité de capteurs de couleur associés respectivement auxdits compartiments de rangement, lesdits capteurs de couleur étant agencés de façon à fournir des signatures chromatiques détectées pour chacun desdits compartiments de rangement, et lesdites signatures chromatiques détectées étant utilisées pour déterminer la présence ou l’absence d’une carte dans un compartiment de rangement par une comparaison avec des signatures chromatiques de référence.
2. Dispositif électronique porte-cartes selon la revendication 1, caractérisé en ce qu’il comprend des moyens de connexion à au moins un réseau de communication des données et des moyens de géolocalisation coopérant avec au moins un système de géolocalisation du type constellation de satellites, du type positionnement par réseau d’objets connectés et/ou du type positionnement par bornes « WiFi » et/ou « Bluetooth ».
3. Dispositif électronique porte-cartes selon la revendication 1 ou 2, caractérisé en ce qu’il comprend des moyens de communication locale de données de type « Bluetooth » pour un appairage avec un dispositif informatique.
4. Dispositif électronique porte-cartes selon l’une quelconque des revendications 1 à 3, caractérisé en ce qu’il comprend des moyens de connexion à un réseau téléphonique de communication de données à haut débit et des moyens de communication « WiFi » configurables en borne d’accès « WiFi » au réseau Internet.
5. Dispositif électronique porte-cartes selon l’une quelconque des revendications 1 à 4, caractérisé en ce qu’il comprend un boîtier rigide ayant un verrou électrique commandable à distance ou un boîtier formé de deux coques rigides articulées rabattables, et en ce qu’il comprend une carte électronique de commande, et/ou un verrou électrique commandable à distance, et/ou un écran tactile, et/ou un connecteur de type « USB » ou « microUSB, et/ou des moyens d’alimentation électrique ayant une batterie électrique rechargeable par induction électrique et/ou par connexion filaire à un réseau d’alimentation électrique.
6. Dispositif électronique porte-cartes selon la revendication 5, caractérisé en ce que ladite carte électronique de commande comprend un coprocesseur cryptographique et des moyens sécurisé de stockage en mémoire d’au moins une clé de cryptage.
7. Ensemble appairé comprenant un dispositif informatique et au moins un dispositif électronique porte-cartes selon l’une quelconque des revendications 1 à 6, ledit dispositif informatique et ledit dispositif électronique porte-cartes étant appairés à travers une liaison de communication locale, et ledit dispositif informatique hébergeant une application logicielle dédiée à la gestion et à l’exploitation dudit dispositif électronique porte-cartes.
8. Ensemble appairé selon la revendication 7, caractérisé en ce que ledit dispositif informatique est un téléphone intelligent dit « smartphone », une tablette informatique ou un ordinateur, et/ou ledit dispositif informatique et/ou ledit dispositif électronique porte-cartes comportent des moyens de détection d’éloignement agencés de façon à émettre une alerte en cas d’un éloignement détecté entre lesdits dispositifs.
9. Système de gestion de cartes comprenant au moins un serveur informatique relié à travers un réseau de communication de données de type Internet à une pluralité de dispositifs porte-cartes selon l’une quelconque des revendications 1 à 6 et/ou une pluralité d’ensembles appairés selon la revendication 7 ou 8, ledit serveur informatique hébergeant un module logiciel système qui gère une pluralité de comptes d’utilisateur auxquels sont associés lesdits dispositifs porte-cartes et/ou lesdits ensembles appairés, et/ou comprenant une unité de stockage de données dans laquelle des données d’utilisateur sont stockées de manière sécurisée.
10. Système de gestion de cartes selon la revendication 9, caractérisé en ce qu’il comprend un module logiciel d’exploitation de données d’utilisateur, ledit module logiciel étant chargé de traiter des données d’utilisateur disponibles et de restituer lesdites données d’utilisateur sous la forme de documents numériques directement utilisables par l’utilisateur, lesdits documents numériques comprenant des tableaux, des relevés, des fiches, des notes et/ou d’autres documents, et lesdites données d’utilisateur comprenant des données fournies par au moins un dit dispositif porte-cartes dudit utilisateur et relatives à l’utilisation desdites cartes, et/ou des données d’organismes auxquels sont rattachées lesdites cartes et récupérées par le système de gestion de cartes à travers des interfaces de type API, et/ou des données saisies par ledit utilisateur et associées à son dit compte d’utilisateur et/ou des données d’application logicielle d’agenda d’utilisateur installée dans ledit dispositif informatique dudit utilisateur et/ou auxquelles le système de gestion de cartes a accès.