FR3095111A1 - CONNECTED ELECTRONIC CARD HOLDER AND CARD MANAGEMENT SYSTEM - Google Patents

Abstract

CONNECTED ELECTRONIC CARD HOLDER AND CARD MANAGEMENT SYSTEM The card holder device (DEC) comprises a plurality of storage compartments (EP1 to EP8) for storing a plurality of cards. According to the invention, the card holder device comprises a plurality of color sensors (CS1 to CS8) associated respectively with the storage compartments, the color sensors being arranged so as to provide chromatic signatures detected for each of the storage compartments. , and the detected color signatures being used to determine the presence or absence of a card in a storage compartment by comparison with reference color signatures. Fig. 3

Description

CONNECTED ELECTRONIC CARD HOLDER AND CARD MANAGEMENT SYSTEM

The invention generally relates to the field of the management of sensitive objects and documents in the form of a card. More particularly, the invention relates to a connected electronic card holder device designed to contain and manage the use of a plurality of cards such as payment cards. The invention also relates to a card management system in which the card holder device is integrated.

Nowadays, the number of cards that a person carries with him in his daily life is high and this number tends to grow. These cards are for example payment cards, loyalty or club cards, access cards and others and important personal documents such as an identity card, a driving licence, a social security card, etc. .

The most widely used card format is the "ID-1" format, known as "bank card format", which is defined by the international standard ISO/IEC 7810. The "ID-1" format has become essential for cards payment, magnetic stripe and/or electronic chip, such as bank cards (credit cards, debit cards, ATM cards, etc.), gift cards, fuel cards and others.

The credit card format tends to become widespread and various sensitive documents, such as an identity card, a social security card and others, are also provided in this format and incorporates an electronic data authentication chip.

The proliferation of cards poses a certain number of difficulties for their holder, in particular relating to their storage and management, to the monitoring of their use and to security. In the event of loss or theft of a card, in particular a payment card, the damage suffered by the holder may be significant.

Different electronic devices are known in the state of the art and provide partial answers to the difficulties encountered by cardholders.

Thus, document WO2019021050A1 discloses a smart wallet equipped with a “GPS” type geolocation module, “Bluetooth” and “WiFi” type communication modules, as well as a subscriber identification telephone card called "SIM" card, a camera and a light sensor. This device is designed for bank and other cards. The SIM card authorizes a connection to the telephone data communication network for the transmission of geolocation coordinates. The camera and its associated light sensor make it possible to take images of the bank cards, these images being intended to be saved in a paired smart telephone, called a “smartphone”, or a remote computer server.

The document CN106174948A also describes a smart wallet paired with a smartphone and which is designed to contain bank cards. The device comprises a “GPS” geolocation module. The opening of the device is authorized through fingerprint recognition.

The document US10185955B1 discloses an electronic box designed to contain several bank cards. The box comprises contactless communication means of the “NFC” type and thus allows a contactless transaction between a selected bank card and a payment terminal.

There is also known in the state of the art a universal card system, such as that disclosed by the document US9129270B2, intended to emulate a plurality of bank cards. In this system, data from different cards is stored in the universal card which can be configured to emulate a selected card. The universal card is paired with a smartphone and features geolocation and tracking and management of emulated cards are provided.

Furthermore, document GB2387930A describes a wallet equipped with an electronic assistant. The electronic assistant comprises a keyboard, a screen and an electronic processing unit with data storage means. The electronic assistant allows financial monitoring through the entry of different payment transactions carried out with bank cards. No means of data communication and network connectivity is provided in this device.

It is desirable to provide a connected card holder device of a new type and an associated card management system allowing easy and comfortable use of a plurality of cards, while providing complete management of the use of these cards. ci and security features including alerts and geolocation.

According to a first aspect, the invention relates to a connected electronic card holder device comprising a plurality of storage compartments intended for storing a plurality of cards. According to the invention, the electronic card holder device comprises a plurality of color sensors associated respectively with the storage compartments, the color sensors being arranged so as to provide chromatic signatures detected for each of the storage compartments, and the signatures detected colors being used to determine the presence or absence of a card in a storage compartment by comparison with reference color signatures.

The electronic card holder device of the invention is suitable for the management of all types of cards, of different natures and having a standardized format or not. Thus, a card may be a bank card, payment card, club card, loyalty card, national identity card and/or another sensitive document in the form of a card. Compartments of different sizes may be provided in the electronic card holder device to accommodate cards of different formats. The device may take different forms depending on the application, for example, a case, a briefcase, a handbag, a briefcase, a suitcase and other fixed or mobile container, of any format, material and size. Furthermore, in certain embodiments, the electronic device may be provided for the storage and management of cards in the form of substantially planar colored objects and not necessarily having a rectangular shape.

According to a particular characteristic, the electronic card holder device comprises means for connection to at least one data communication network and geolocation means cooperating with at least one geolocation system of the constellation of satellites type, of the positioning network type. connected objects and/or of the positioning type via “WiFi” and/or “Bluetooth” terminals.

According to another particular characteristic, the electronic card holder device comprises local data communication means of the “Bluetooth” type for pairing with a computer device.

According to yet another particular characteristic, the electronic card holder device comprises means of connection to a telephone network for high-speed data communication and "WiFi" communication means configurable as a "WiFi" access point to the Internet network.

According to yet another particular characteristic, the electronic card-holder device comprises a rigid casing having a remote-controllable electric lock or a casing formed of two folding hinged rigid shells, and comprises an electronic control card, a remote-controllable electric lock, a touch screen, a connector of the “USB” or “microUSB” type, and/or electric power supply means having an electric battery rechargeable by electric induction and/or by wired connection to an electric power supply network.

According to yet another particular characteristic, the electronic control card of the electronic card holder device comprises a cryptographic coprocessor and secure means for storing in memory at least one encryption key.

According to another aspect, the invention also relates to a paired assembly comprising a computer device and at least one electronic card holder device as described briefly above, the computer device and the electronic card holder device being paired through a link local communication, and the computer device hosting a software application dedicated to the management and operation of the electronic card holder device.

According to one particular characteristic, the computing device in the paired assembly is a smart telephone called a "smartphone", a computer tablet or a computer, and/or the computing device and/or the electronic card-carrying device comprise means for detecting distance arranged so as to emit an alert in the event of a distance detected between these devices.

According to another aspect, the invention also relates to a card management system comprising at least one computer server connected via an Internet type data communication network to a plurality of card holder devices briefly described above and/or a plurality of paired sets described briefly above, the computer server hosting a system software module which manages a plurality of user accounts with which the card holder devices and/or the paired sets are associated, and/or comprising a unit data storage in which user data is securely stored.

According to a particular characteristic, the card management system comprises a software module for operating user data, the software module being responsible for processing available user data and returning them in the form of digital documents directly usable by the user, the digital documents comprising tables, statements, sheets, notes and/or other documents, and the user data comprising data provided by at least one card holder device of the user and relating to the use of the cards, data from organizations to which the cards are attached and retrieved by the card management system through API-type interfaces, data entered by the user and associated with his account user and/or user calendar software application data installed in the user's computing device and/or to which the card management system has access.

Other advantages and characteristics of the present invention will appear more clearly on reading the detailed description below of several particular embodiments of the invention, with reference to the appended drawings, in which:

Fig.1 is a simplified overview of a particular embodiment of the card management system according to the invention.

Fig.2 is a first perspective view of a particular embodiment of a card holder device according to the invention.

Fig.3 is a second perspective view of the card holder device of Fig.2.

Fig.4 is a third perspective view of the card holder device of Fig.2.

Fig.5 is an explanatory diagram relating to the identification of the cards in the storage compartments from chromatic signatures provided by color sensors.

Fig.6 is a simplified block diagram of an electronic control card included in the card holder device.

Fig.7 is a first simplified algorithm of a control process implemented in the card holder device for the identification of the cards in the storage compartments.

Fig.8 is a second simplified algorithm of the control process implemented in the card holder device for the identification of the cards in the storage compartments.

Fig.9 is a simplified block diagram relating to the management of secure areas by the control process implemented in the card holder device.

FIG. 10 is a simplified block diagram showing an illustrative example of user data processing carried out by a user data exploitation software module included in the card management system of the invention.

With reference to FIG. 1, the card management system SGC is deployed through at least one communication network IT, such as the Internet, and notably comprises a plurality of connected card holder devices DEC, which belong to users System UR, and at least one SRC computer server.

The connected card holder devices DEC of UR users are paired respectively with computing devices of UR users, typically their smartphones SPH, but also their computing tablets or computers.

In the following, for the convenience of the description, it is considered that the DEC card holder device of a user is paired to the latter's smartphone SPH, unless otherwise indicated.

Each SPH smartphone hosts a dedicated software application APPLI which is intended for the management of the paired DEC cardholder device and which supports the functionalities of the device, including its initial configuration or parameterization. The pairing connectivity between the card holder device DEC and the smartphone SPH is typically ensured by a local data communication link BL of the "Bluetooth" type. The dedicated APPLI application exchanges data with SW system software hosted in the SRC computer server. A data communication link is established for this purpose between the smartphone SPH and the computer server SRC, through a telephone data communication network and the IT network. The SW system software notably controls the general operation of the SGC card management system through the execution of code instructions and storage of user data.

The SGC card management system uses hardware and software resources that are accessible through the IT network. In this particular embodiment, it is considered that the DCS card management system uses hardware and software resources located in a cloud computing service SCP, called “cloud” in English. The system software SW is here installed in at least one computer server SRC of the computer service SCP. More precisely, the system software SW is hosted in a data storage unit DS formed by one or more hard disks dedicated to the SGC system.

The computer server SRC comprises a processing unit UC (including one or more processors as well as read only memories called "ROM" and random access working memories called "RAM") coupled to the data storage unit DS, a autonomous security HSM, for “Hardware Security Module” in English, which is dedicated to the secure storage of encryption keys, and conventional hardware devices such as NI network interfaces and other devices not shown. It will be noted that the encryption keys stored in the HSM module are used for the encryption in particular of the data communication links, taking into account the sensitive data linked to the payment cards which are managed by the SGC system.

The system software SW comprises various MGT software modules necessary for the general operation of the SGC system according to the invention, these MGT software modules being responsible in particular for the validation and installation of user accounts (possibly through the so-called "KYC" procedures for " Know Your Customer" in English, according to the regulations), as well as the general management of these accounts and usage data, and the security of communications through the IT network.

The system software SW also includes a software module WP for implementing a web platform WP through which an administrator ADMIN and users UR of the SGC system can log in to their accounts using their respective computing devices, typically, smartphone, tablet or computer.

The UR user has access to the data and functionalities of his account through the dedicated APPLI application, as indicated above, but also through a connection to the WP web platform using the internet browser installed in a computer device and a web address “URL” (for “Uniform Resource Locator” in English). The user UR can thus by these two means interact with the SGC system to access, for example, a dashboard for managing his card holder device DEC and various statements and other digital documents concerning the use of his cards. , and other functionalities such as the geolocation of the card holder device, the blocking of a card and other functions. The ADMIN administrator can access his account on the WP web platform by means of an internet browser, or through a management application and a dedicated data communication link.

In some applications, the SGC card management system according to the invention may be connected and exchange data with SRB computer systems of different organizations that have issued cards managed by the SGC system, such as banks, payment services, health insurance organizations and others. For example, in a particular embodiment, the SGC system will have access to data of its users UR in the SRB computer systems, through API interfaces, for “Application Programing Interface” in English, of these SRB systems. Data obtained from a financial institution's SRB computer system will typically be payment card usage data such as expense amounts, balances, etc., and will be used by the CMS system to supplement and/or consolidate its own card usage data.

In general, it will be noted that all of the data of each user UR of the card holder device DEC and of the card management system SGC according to the invention are stored in the data storage unit DS in accordance with the regulations European GDPR, for "General Regulations for Data Protection", in force since May 25, 2018. The UR user has the right to consult and rectify the data concerning him in accordance with the GDPR regulations, and the right to permanent deletion of his data called "right to be forgotten". User data will preferably be stored securely (if necessary, with encryption) in the DS data storage unit. Typically, user data will include all card-related data collected by the CMS card management system, i.e. essentially card identification, security and usage data. User data will also include digital copies of cards and documents (ID card, passport, etc.) stored in the CMS system, for example, photographs of cards and documents taken with the SPH smartphone.

In the card management system SGC according to the invention, security functions are provided in particular to warn the user UR of a distance between the card holder device DEC and the smartphone SPH, following an oversight, a loss, theft and any other reason, the absence of a card in the DEC card holder device. These security functions help the UR user to recover the missing device, DEC or SPH, or the missing card, thanks to the geolocation and traceability of the use of the cards. Thus, for example, the distance between the card holder device DEC and the smartphone SPH can be detected by the interruption of the local “Bluetooth” link, BL, for pairing between the two devices. A distance detected can give rise to an alert by the SPH smartphone, through the APPLI application, and to another alert by the DEC card holder device. The user UR is thus informed of the absence of his card holder device DEC by the smartphone SPH and of the absence of his smartphone SPH by the card holder device DEC. The UR user will be able to remotely lock his DEC card holder device through the APPLI application, as well as block (“block”) payment cards contained in the DEC card holder device.

As shown in Fig. 1, the external geolocation of the DEC card holder device can be obtained with one or more SAT satellite positioning systems, such as the constellations of known satellites "GPS", "GALILEO", "GLONAS" and others.

The recovery of the geolocation coordinates of the card holder device DEC by the APPLI application is typically obtained through a low-power RLP data communication network of the "LPWAN" type, for "Low Power Wide Area Network" in English, to which is connected the DEC card holder device. Typically, the RLP network could for example be a network of connected objects such as "Sigfox", "LoRa", "NB-IoT" or "LTE-M".

In alternative embodiments, the exterior geolocation of the DEC card holder device may be ensured by the RLP network of the “LPWAN” type, insofar as the exterior geolocation service provided by this network has the precision required for the application.

As also shown in Fig.1, the interior geolocation of the DEC card holder device can be obtained using "WiFi" type BBL terminals present in the premises. Terminals (not shown) of the “BLE” type, for “Bluetooth Low Energy” in English, may also be used in certain applications for greater precision. As a variant, the indoor geolocation of the card holder device DEC can also be ensured by the RLP network of the “LPWAN” type, when the indoor geolocation service provided by this network has the precision required for the application.

In other embodiments of the invention, the card holder device DEC will be connected not to a network of low-power connected objects, such as the RLP network mentioned above, but directly to the Internet network IT by a link of data communication LA through the high-speed data communication telephone network, at the “4G” or “5G” standard for example. The DEC card holder device will then be fitted with a “SIM” card. In this case, the card holder device DEC will be able to exchange data directly with the server SRC via the data communication link LA, without these passing through the Bluetooth link BL with the smartphone SPH, and also receive the coordinates of geolocation.

In addition, in the embodiments above, given its connection to the high-speed data communication telephone network, the card holder device DEC may comprise a mode of operation as a “WiFi” access terminal and offer the user, for example, global access to the Internet network, thanks to global roaming agreements, known as “global roaming agreements” in English, between the SGC system and global and national mobile telephone operators.

With reference also to Figs. 2 to 6, the general layout and the hardware architecture of an embodiment of the card holder device DEC are now more particularly described.

As visible in Figs.2 to 4, the card holder device DEC here comprises two articulated rigid shells C1 and C2 between which are arranged two intermediate planar supports SC1 and SC2 forming card storage supports. The shells C1, C2 are foldable so as to contain, once folded down, the storage media and the cards in a closed enclosure. Advantageously, the shells C1, C2 are provided with electromagnetic shielding for the protection of the cards (in particular, so-called “contactless” bank cards) and the securing of the data.

The card storage supports SC1, SC2 are mobile, being articulated on the same axis of articulation as the shells C1, C2. As shown in Fig.3, each card storage support SC1, SC2, here comprises four card storage compartments, namely, EP1 to EP4 in the support SC1 and EP5 to EP8 in the support SC2.

A key PW, which is associated with an indicator light LD, as well as a “USB” or “microUSB” type PR connector, visible in Fig.2, are fitted to the DEC card holder device. The PW key is advantageously multifunctional, typically for the on/off control function of the card holder device DEC and/or the pairing function by Bluetooth link with the smartphone SPH and other functions. The connector PR is typically used for the electric recharging of the electric battery of the card holder device DEC. The connector PR can also be used for a wired data communication link between the card holder device DEC and a computing device such as a computer, a tablet or a smartphone.

An electric lock VE of the card holder device DEC is provided and arranged in the shells C1, C2. A COF opening/closing sensor is also integrated in the DEC card holder device, to trigger certain usage functions depending on the open or closed state of the device. Advantageously, the electric lock VE is provided to allow remote locking of the card holder device DEC.

Electronic cards, for example of the "PCB" type, not visible in Figs.2 to 4, support the various electronic components necessary for the operation of the card holder device DEC. These electronic cards are housed inside shells C1, C2.

As shown in Figs.3 and 4, a touch screen DY is arranged in the shell C1 and facilitates the interactions between the user and the card holder device DEC. Thus, through the DY touch screen, the user can be guided to access the information sought through different menus. He can also, for example, enter the amounts of expenses made with his payment cards.

In accordance with the invention, the card holder device DEC is also equipped with card detection means which identify the cards and detect their presence or absence in the storage compartments. Storage compartments are respectively assigned to the cards during an initialization phase and the presence or absence of the cards in their respective storage compartments can thus be detected by the card holder device DEC. Card storage errors can also be detected. The card holder device DEC therefore has the ability to monitor the use of each of the cards from events of extraction/storage of the cards in the compartments, events which are timestamped and geolocated, and to detect anomalies generating alarms, for example, the absence of a card in its compartment in the event of forgetfulness, loss or theft thereof.

In the invention, the cards are identified by their respective color signatures. The inventive entity has found that cards are usually distinguished from each other by very different colored visuals, with card issuers seeking to visually differentiate their cards from those of competitors. It is therefore possible to reliably identify the different cards contained in the card holder device DEC from their respective chromatic signatures.

The card detection means comprise a plurality of color sensors, here eight color sensors CS1 to CS8, visible in Figs.3 and 4. Each of the color sensors CS1 to CS8 is preferably an integrated electronic component typically comprising several photodiodes associated with colored filters (not shown) and a white light-emitting diode (not shown). The white light-emitting diode has the function of illuminating the compartment / card for color detection.

The color sensors CS1 to CS4 detect the cards in the storage compartments EP1 to EP4 of the card storage support SC1. The color sensors CS5 to CS8 detect the cards in the storage compartments EP5 to EP8 of the card storage rack SC2.

To carry out the card detection operations indicated above, the card holder device DEC must be able to discriminate between three different states for each storage compartment, namely, a first state which is that of the empty compartment, a second state which is that of the compartment containing the card which was initially allocated to it by the user and a third state which is that of the compartment containing a card other than that which was allocated to it by the user.

The first state is detected when the chromatic signature read corresponds to a first memorized chromatic signature of empty compartment which was read previously, during an initialization, for the considered compartment. The second state is detected when the chromatic signature read corresponds to a second valid full compartment memorized chromatic signature which was read previously, during an initialization, for the considered compartment containing the allocated card. The third state is detected when the read color signature does not match any of the stored first and second color signatures.

In Fig.6, it is considered by way of illustrative example that the card holder device DEC contains four cards C1, C2, C3 and C4 that the user has chosen to store respectively in the compartments EP3, EP6, EP5 and EP2.

An initialization phase launched previously by the user made it possible to read and memorize chromatic signatures of empty compartment SV1 to SV8 provided by the color sensors CS1 to CS8 for the compartments EP1 to EP8, respectively. One or more other initialization phases launched previously by the user made it possible to read and store valid full compartment color signatures S1, S2, S3 and S4 provided by the color sensors CS3, CS6, CS5 and CS2 for the compartments EP3, EP6, EP5 and EP2 containing maps C1, C2, C3 and C4, respectively.

During a card detection operation launched by onboard software for controlling the card holder device DEC, if the cards C1, C2, C3 and C4 are present in their compartments EP3, EP6, EP5 and EP2, the color sensors CS3, CS6, CS5, and CS2 associated with these buckets read valid bucket full color signatures S1, S2, S3, and S4 that indicate cards are in their respective buckets. During the same card detection operation, the color sensors CS1, CS4, CS7 and CS8 associated with the empty compartments EP1, EP4, EP7 and EP8 read the empty compartment color signatures SV1, SV4, SV7 and SV8 which indicate that these compartments are actually empty. In this card detection operation, the chromatic signatures which are read for each of the compartments EP1 to EP8 are those expected by the on-board control software and no anomaly is signaled to the software application APPLI by the card holder device DEC .

In another case, by way of example, if the user has made a mistake when storing the cards C1, C2, C3 and C4 in the compartments, the chromatic signatures which are read for each of the compartments EP1 to EP8 are not expected, but the number of empty bucket color signatures remains the same, equal to four in this example. The on-board control software can therefore decide that it is a storage error and this anomaly can then be signaled to the APPLI software application by the card holder device DEC.

In yet another case, by way of example, if one of the cards C1 to C4 is absent, the absence of this card is detected by the number of chromatic signatures of empty compartment which increases by one unit and passes to five in this example. The on-board control software for the DEC card-holder device can then signal this absence to the APPLI software application. If the three cards present are correctly stored in their respective compartments, the identification of the missing card is also possible and can also be provided to the APPLI software application.

In general, in the embodiment described here, of the card management system SGC and of the card holder device DEC, it is considered that the identification of a card can only be made by the color sensor to which it was associated during an initialization operation and which delivered the chromatic signature stored for this card stored in its compartment.

The technical approach above takes into account, and manages, a significant disparity in sensitivity between color sensors. Indeed, with a significant disparity, two distinct color sensors will provide significantly very different output signals for the same card. It is therefore necessary to pair a sensor to a card by assigning the card a storage compartment linked to this sensor. A different technical approach may be adopted in the case of the availability of color sensors with a very low sensitivity disparity. In such a case, it is no longer necessary to assign a card to a particular color sensor and a card can be identified without having to be stored in an assigned compartment.

Referring now more particularly to FIG. 6, a general electronic architecture of the card holder device DEC is described below in detail, corresponding to the particular embodiment of the device described here. This electronic architecture comprises an electronic circuit, marked 2 in Fig.6, which is typically supported on two "PCB" type electronic cards housed inside the rigid articulated shells C1, C2, mentioned above.

It will be noted that the electronic circuit 2 is contained in a sealed manner in the shells C1, C2 of the card holder device DEC, as well as the other associated components, typically with an IP5 protection index, for protection against splashing water and against dust.

The electronic circuit 2 comprises a control unit 20, an I ² _{C type internal communication bus BB I2C} , a first local communication RF transmitter/receiver module 21, a second remote communication RF transmitter/receiver module 22, a satellite geolocation 23, a color sensor module 24 and a power supply unit 25.

The control unit 20 is typically in the form of a microcontroller comprising a microprocessor µP, a cryptographic coprocessor CP, an autonomous security module K, a non-volatile data memory 200 of the E2PROM type, a volatile data memory 201 of RAM type, a non-volatile program memory 202 of FLASH type containing embedded software PROG, an input/output interface 203a, a touch screen interface 203b, an input/output interface 203c and a USB port.

The embedded software PROG supports the operating system of the DEC card holder device and includes various software modules that manage all of its operation, from the hardware layer to the application layer, as well as human interface exchanges -machine and data communication links and networks. In particular, the embedded software PROG includes a software module which manages the general configuration of the device, with in particular the initialization phases and the card detection operations by the color sensor module 24.

The cryptography coprocessor CP and the standalone security module K are dedicated to the encryption of sensitive data, particularly during exchanges with the smartphone SPH and the computer server SRC. The autonomous security module K is an HSM-type module dedicated to the secure storage of encryption keys.

The input/output interface 203a is an input/output port which connects to the control unit 20, the key PW and the associated indicator light LD (light-emitting diode), the opening/closing means VE, the COF opening/closing sensor and a BZ loudspeaker. Inputs/outputs of the interface 203a are also used for controlling the power supply unit 25.
The opening/closing sensor COF is typically formed of a Hall effect sensor associated with a magnet. The BZ loudspeaker is a miniature loudspeaker module that can be integrated on a PCB-type printed circuit and allows the DEC card holder device to emit audio alerts.

The touch screen interface 203b is typically an interface suitable for the screen DY integrated in the card holder device DEC, typically a color screen module of the LCD/TFT touch type.

The 203c input/output interface is a data input/output port which is configured with a software layer for operation as an I ² C type bus interface. The 203c interface is linked to the internal communication bus BB _I2C .

The first RF transmitter/receiver module 21 is here a combined WiFi/Bluetooth radio communication module comprising an I ² C interface for connection to the internal communication bus BB _I2C . The WiFi function will include the so-called “WPS” mode, for “WiFi Positioning System” in English, in order to authorize positioning inside buildings equipped with WiFi terminals. The Bluetooth function will be, for example, of the "Bluetooth Smart 4.2" type with the so-called "PXP" and "GATT" profiles, for the BL link with the SPH smartphone and the detection of the distance between it and the device -DEC cards.

The second RF transmitter/receiver module 22 is here a radio communication module of the LPWAN type, as mentioned above, comprising an I ² C interface for connection to the internal communication bus BB _I2C . Typically, a combined LoRa/Sigfox module will be used. The data communication link established with the network of LoRa or Sigfox connected objects will notably make it possible to receive external geolocation coordinates by satellite. Eventually, external geolocation may be ensured, not by satellites, but by the network of LoRa or Sigfox connected objects, if the accuracy provided by the latter is compatible with the application.

In another embodiment mentioned in the description of Fig.1, the second RF transmitter/receiver module 22 will be a WAN radio communication module, of the 4G or 5G type, with a SIM card interface, and an interface I ² C for connection to the BB _I2C internal communication bus. In this embodiment, the card holder device DEC is connected to the internet network IT (link LA in FIG. 1) through the 4G, or 5G, data communication telephone network. In this case, the external geolocation coordinates may be received by the high-speed communication link LA. As a variant, the exterior geolocation coordinates will be transmitted through a network of NB-IoT or LTE-M connected objects deployed by the mobile telephone operator. Eventually, outdoor geolocation may be ensured, not by satellites, but by the network of connected objects NB-IoT or LTE-M, if the accuracy provided by the latter is compatible with the application.

Moreover, in this other embodiment, taking into account the connection of the card holder device DEC to the high-speed data communication telephone network, the card holder device DEC may comprise an operating mode as an access terminal WiFi to grant the user worldwide access to the Internet network. The WiFi mode provided by the RF 21 transmitter/receiver module and the high-speed link provided by the RF 22 transmitter/receiver module in 4G, or 5G, will make it possible to provide this WiFi access point functionality.

The satellite geolocation module 23 is of the GNSS type, for “Global Navigation Satellite System” in English, and allows external geolocation by different constellations of satellites (GPS, GALILEO, etc.).

The color sensor module 24 is typically supported on a PCB type printed circuit board and includes the plurality of color sensors, namely, CS1 through CS8 in this embodiment.

The power supply unit 25 is interfaced with the control unit 20 and includes a rechargeable battery 250, voltage converters (not shown) and an inductive load receiver unit 251.

The rechargeable battery 250 is typically a “LiPo” (Lithium-Polymer) type battery. The battery 250 can be charged by induction or by means of a standard AC-DC electric charger, not shown, which is plugged into the socket PR of the card holder device DEC. The PR socket is typically in USB or microUSB format and is connected to the USB port of the control unit 20.

The inductive load receiver unit 251 is a device known to those skilled in the art and may not be present in more economical embodiments. The unit 251 is associated with an induction charging transmitter unit 252 which is typically included in a charging support (not shown) capable of receiving the card holder device DEC. The transmitter unit 252 is for example supplied with energy from the AC power supply mains by an AC-DC charger 253, or is powered by a low voltage DC power supply network such as that of a motor vehicle. When the card holder device DEC is placed on the charging support, means included in the unit 252 detect its presence and activate a transfer of charging energy by an induction wave IND.

The electronic architecture described above for the control unit 20 makes use of an I ² C bus. Of course, this is a particular embodiment described by way of example. Other bus standards will be more suitable for certain applications and may be used in the context of the invention.

With reference now more particularly to FIG. 7, an IN/OUT_CARD_EPp processing algorithm is described for monitoring card detection events relative to storage compartments EPp to which cards Cn have been allocated. Fig.7, the IN/OUT_CARD_EPp algorithm comprises steps E1 to E10.

At step E1, a considered card Cn is in a state Cn_in_EPp corresponding to a storage state of the card Cn in its respective compartment EPp.

Step E2 is a conditional step intended to detect a state Cn_out_EPp corresponding to a state of non-storage of the card Cn in its respective compartment EPp. As long as the Cn_out_EPp state is not detected (output N in the active state "1"), the control process loops to step E1 awaiting a card extraction event.

When the Cn_out_EPp state is detected (output Y in the active state "1"), after effective extraction of the card Cn from the EPp compartment, the process executes the step E3 which emits a notification Ntf(Cn_out, D, H, L) indicating a detection event Cn_out, namely the observed absence of the card Cn in its compartment EPp, as well as the timestamp D (date) and H (time) and the geolocation L of the event. The Ntf(Cn_out, D, H, L) notification is stored in memory and the process triggers a timeout DL1 during which it waits for the return of the Cn card to its EPp compartment.

The conditional steps E4 and E5 correspond to this expectation of the return of the card Cn to its compartment EPp. At step E4, as long as the card Cn is absent from the compartment EPp, the empty compartment state EPp=Empty is active (output Y= “1”). Step E5 checks whether the time elapsed t since the detection event Cn_out is greater than the timeout DL1. If this is not the case (output N= “1”), the process loops to step E4. In this opposite case (output Y= "1"), the DL1 timeout has elapsed and the process goes to step E6 and sends an alert notification Ntf(Cn_DL1, D, H, L) which indicates a card absence event Cn_DL1 to the user, with timestamp H, D, and geolocation L. The alert notification Ntf(Cn_DL1, D, H, L) is stored in memory to ensure traceability.

With the receipt of the Ntf(Cn_DL1, D, H, L) alert notification, the user is warned of the absence of his Cn card and can take action to recover it and store it in the compartment EPp.

If the user cannot find his Cn card and it is a payment card, the user can trigger a blocking of the Cn card, called "blocking", which is then managed automatically by the process. The blocking of the card Cn is managed in step E7 with an operation USER_LOCK_Cn during which the process transmits card blocking data to the financial institution (cf. Fig. 1, server SRB) issuing the card Cn.

At step E4, when the process detects that the empty compartment state EPp=Empty is inactive (output N=“1”), this event is the result of a card being stored in the compartment EPp.

The conditional step E8 enables the process to verify that the card stored in the compartment EPp is indeed the card Cn. If this is the case, the state Cn_in_EPp is activated (output Y= “1”) and a notification Ntf(Cn_in , D, H, L) is sent in step E9. This notification indicates a detection event Cn_in, namely the observed presence of the card Cn in its compartment EPp, as well as the timestamp D, H, and the geolocation L of the event, is stored in memory by the process. The process then returns to step E1 awaiting the next extraction of the card Cn from its compartment EPp.

At step E8, if the card stored in compartment EPp is not card Cn (output N=“1”), the process executes step E10 in which a notification Ntf(Err_EPp, D, H , L) indicating a compartment error detection event Err_EPp, namely the presence observed in the compartment EPp of a card which is not the card Cn, as well as the timestamp D, H, and the geolocation L of the event. The Ntf bucket error notification(Err_EPp, D, H, L) is stored in memory by the process and results in an alert for the user to rectify their error.

Fig.8 shows the tracking by an IN/OUT_CARD_EPq processing algorithm of card detection events relative to storage compartments EPq to which no card has been allocated. As visible in Fig.8, the IN/OUT_CARD_EPq algorithm comprises two steps E11 to E12.

The conditional step E11 verifies in a loop the unoccupied state EPq=Empty of the compartment EPq considered. As long as the compartment EPq remains unoccupied (output "Y=1"), the control process loops and step E11 is repeated. In the case where a card is stored in the compartment EPq (output "N=1"), the process executes step E12 in which a notification Ntf(Err_EPq, D, H, L) is emitted indicating a detection event of compartment error Err_EPq, i.e. the presence observed in the compartment EPq of a card which does not have to be there, as well as the timestamp D, H, and the geolocation L of the event. The Ntf(Err_EPq, D, H, L) bucket error notification is stored in memory by the process and results in an alert for the user to rectify their error.

Fig.9 shows a differentiated LOC/ALT_REMOTE management performed by the command process depending on whether or not the user is in a zone or perimeter declared safe. The user has the possibility of declaring certain places, for example his home, as being safe places, so as to deactivate certain alerts in such a place and a perimeter defined around it. For example, the distance alert between the DEC card holder device and the SPH smartphone can be deactivated in a safe area.

Thus, as shown in Fig.9, the logic state of an S_ZONE indicator is detected in order to determine a management adapted to the place. The logical state of this S_ZONE indicator can be defined by the user when he arrives at a place, or can be determined automatically by the process from previous memorized declarations of the user and the geolocation.

When the S_ZONE indicator is in an inactive state (output "N=1") which indicates that the place is not in a safe zone declared by the user, the process executes various processing modules IN/OUT_CARD, LOCA_DEC and ALT_REMOTE.

The IN/OUT_CARD processing is represented by the algorithms described above in relation to FIGS. 7 and 8 and relates to the monitoring of card detection events relative to the storage compartments. The IN/OUT_CARD processing calls for each new event detected on the external or internal geolocation of the card holder device DEC which is managed by the processing module LOCA_DEC. The execution of the IN/OUT_CARD processing produces an Ntf notification during each detection event which integrates the timestamp and the geolocation linked to the event determined by the LOCA_DEC module. User alerts can be associated with Ntf notifications, as already described.

The ALT_REMOTE module is responsible for detecting distance between the card holder device DEC and the smartphone SPH, in particular through the Bluetooth link BL (Fig.1) as described above. The LOCA_DEC module is also requested during a remoteness detection event to geolocate the place of the event. A corresponding Ntf notification including geolocation and timestamp is emitted during the remoteness detection event and is stored in memory.

Of course, the LOCA_DEC module will be able to manage geolocations of the DEC card holder device in circumstances other than those indicated above. Thus, for example, the user can activate a geolocation of the DEC card holder device at any time through his SPH smartphone. A geolocation of the card holder device DEC can also be launched by the process for any event carrying information for the processing, such as for example an opening of the card holder device DEC detected by the opening/closing sensor COF. Corresponding Ntf notifications including geolocation and timestamp are also emitted for these events and are stored in memory.

When the S_ZONE indicator is in an active state (output "Y=1") which indicates that the place is in a safe zone declared by the user, the process executes the processing modules IN/OUT_CARD and LOCA_DEC in the same way as described above. However, the ALT_REMOTE processing module is disabled.

It should be noted that an artificial intelligence module may be integrated and participate in or fully manage the execution of the various processing processes described above. Thus, the artificial intelligence module will be able to exploit the history of stored event notifications to extract knowledge that is used in the processing processes without having to solicit the user, for example, for automatic detection of safe areas. Alternatively, if the user has not validated the control of the artificial intelligence, contextual suggestions may be made to him by an artificial intelligence assistant. Of course, the artificial intelligence module can make a significant contribution to other tasks not mentioned here, but of which the person skilled in the art is aware, to increase the performance of the card holder device DEC and of the card management system SGC according to the invention.

Referring to Fig.10, a user data processing software module MGT_DATA is implemented in the SGC card management system. The MGT_DATA module processes the data available to the user, provided by the various processing processes collaborating in the SGC card management system, and returns them in the form of tables, sheets, notes, etc., directly accessible and usable by the user. The MGT_DATA module manages real-time updating of tables, sheets, notes, etc.

Thus, the MGT_DATA module receives DATA_DEC data provided by the card holder device DEC, which includes the Ntf event notifications described above and related to the use of the cards. These DATA_DEC data include the data produced by the IN/OUT_CARD, LOC_DEC and ALT_REMOTE modules and DEC_EXP_DATA data. The DEC_EXP_DATA data is data entered by the user on the DY touch screen and relating in particular to expenses made with the cards.

The MGT_DATA module also processes DATA_ORG data and CODE security codes, or digital keys, for example, for validation of payments made with cards. DATA_ORG data is typically data from organizations to which the cards are attached, such as banks, payment services, health insurance organizations and others. The DATA_ORG data is available on the SRB computer servers (Fig.1) through API interfaces and typically retrieved by the SW system software of the SGC card management system.

In addition, the MGT_DATA module processes DATA_WP, DATA_SPH and DATA_AGENDA data. DATA_WP and DATA_SPH data are data entered by the user on the WP web platform and on their connected computing device, such as their SPH smartphone, and which are associated with their user account. The DATA_AGENDA data comes for example from an agenda software application installed in the user's SPH smartphone and to which the APPLI application has access or from another user's agenda software application to which the system card management has access through the Internet or another network.

Fig.10 shows by way of example different tables TB_Cn, NT_Cn and TB_G, representing readings, notes, etc., established by the MGT_DATA module and which are accessible to the user through menus and dashboards of the APPLI application and its user account on the WP web platform.

Thus, the TB_Cn tables are associated respectively with the Cn cards and show their use and data from different events. For example, in a TB_Cn table associated with a Cn card, there are OUT and IN data corresponding to the exit/return movements of the Cn card in its compartment, D, H and L data for timestamps and geolocation of associated events to the Cn card, EXP expenditure data with the Cn card and an ITEM assignment of these expenditures, and other data such as alert emission ALT data, card blocking LOCK_Cn data and code data security CODE transmitted, etc. A LINK hypertext link is also integrated into the TB_Cn table to allow the user to go directly to the website of the organization issuing the Cn card if he so wishes.

The NT_Cn tables here are, for example, expense reports associated with professional events such as appointments, trips, journeys, seminars and the like, or personal events, during which Cn cards were used. The D/H/L data relating to these events, such as dates and places associated with geolocations, are retrieved by the MGT_DATA module from the user's DATA_AGENDA calendar data. Cross-checks carried out by the MDT_DATA module, assisted if necessary by an artificial intelligence module, between the DATA_AGENDA diary data and the card usage data, available in ordered form in the TB_Cn tables, allow the management system to SGC cards to provide an NT_Cn expense report associated with an event which summarizes all the expenses made with one or more Cn, …, Cm cards (for example, personal card, fuel card, company prepaid card, etc. ). As other examples, the NT_Cn arrays could be statements of points for loyalty cards, statements of reimbursements made by a health insurance organization, statements of expenses in foreign currencies and others.

The table TB_G is for example a general management dashboard of the card holder device DEC. For example, in the TB_Cn table are available data S_ZONE, ACTIVE/INACTIVE, D, H, L, and DIS_ALT_REMOTE/ EN_ ALT_REMOTE relating to the activation/deactivation of the safe zone mode, the timestamp, the geolocation and the activation/deactivation of the distance alert. Other data DATA_ALT_REMOTE, DATA_LOC_DEC and DATA_LOCK_DEC are also shown by way of example in the TB_G table and correspond to remote, geolocation and remote locking alert events of the DEC card holder device.

The invention is not limited to the particular embodiments which have been described here by way of example. The person skilled in the art, depending on the applications of the invention, may make various modifications and variants falling within the scope of protection of the invention.

Claims (10)

Connected card holder electronic device comprising a plurality of storage compartments intended for storing a plurality of cards, characterized in that it comprises a plurality of color sensors respectively associated with said storage compartments, said color sensors being arranged so as to provide detected color signatures for each of said storage compartments, and said detected color signatures being used to determine the presence or absence of a card in a storage compartment by comparison with reference color signatures. Electronic card holder device according to Claim 1, characterized in that it comprises means for connection to at least one data communication network and geolocation means cooperating with at least one geolocation system of the constellation of satellites type, of the positioning type by network of connected objects and/or of the positioning type by “WiFi” and/or “Bluetooth” terminals. Electronic card holder device according to claim 1 or 2, characterized in that it comprises local data communication means of the "Bluetooth" type for pairing with a computer device. Electronic card holder device according to any one of Claims 1 to 3, characterized in that it comprises means of connection to a high-speed data communication telephone network and “WiFi” communication means configurable as a terminal. "WiFi" access to the Internet network. Electronic card-carrying device according to any one of Claims 1 to 4, characterized in that it comprises a rigid casing having a remote-controllable electric lock or a casing formed of two folding hinged rigid shells, and in that it comprises an electronic control card, and/or a remotely controllable electric lock, and/or a touch screen, and/or a “USB” or “microUSB” type connector, and/or electric power supply means having a battery electrical device rechargeable by electrical induction and/or by wired connection to a power supply network. Electronic card holder device according to Claim 5, characterized in that the said electronic control card comprises a cryptographic coprocessor and secure means for storing in memory at least one encryption key. Paired assembly comprising a computer device and at least one electronic card holder device according to any one of claims 1 to 6, said computer device and said electronic card holder device being paired through a local communication link, and said computer device hosting a software application dedicated to the management and operation of said electronic card holder device. Paired assembly according to Claim 7, characterized in that the said computing device is a smart telephone called a “smartphone”, a computing tablet or a computer, and/or the said computing device and/or the said electronic card holder device comprise detection means distancing arranged so as to emit an alert in the event of a detected distancing between said devices. Card management system comprising at least one computer server connected via an Internet-type data communication network to a plurality of card holder devices according to any one of claims 1 to 6 and/or a plurality of paired sets according to claim 7 or 8, said computer server hosting a system software module which manages a plurality of user accounts with which said card holder devices and/or said paired sets are associated, and/or comprising a data storage unit in which user data is securely stored. Card management system according to claim 9, characterized in that it comprises a user data exploitation software module, said software module being responsible for processing available user data and restoring said user data in the form of digital documents directly usable by the user, said digital documents comprising tables, statements, files, notes and/or other documents, and said user data comprising data provided by at least one said card holder device of said user and relating to the use of said cards, and/or data of organizations to which said cards are attached and recovered by the card management system through API-type interfaces, and/or data entered by said user and associated with said user account and/or user calendar software application data installed in said device i computer of said user and/or to which the card management system has access.