WO2023247737A1 - Methode et systeme d'assistance d'echanges controles de donnees - Google Patents

Methode et systeme d'assistance d'echanges controles de donnees Download PDF

Info

Publication number
WO2023247737A1
WO2023247737A1 PCT/EP2023/067058 EP2023067058W WO2023247737A1 WO 2023247737 A1 WO2023247737 A1 WO 2023247737A1 EP 2023067058 W EP2023067058 W EP 2023067058W WO 2023247737 A1 WO2023247737 A1 WO 2023247737A1
Authority
WO
WIPO (PCT)
Prior art keywords
card
manager
community
exchange
data
Prior art date
Application number
PCT/EP2023/067058
Other languages
English (en)
Inventor
Salvatore Caramazza
Original Assignee
Ersa
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ersa filed Critical Ersa
Publication of WO2023247737A1 publication Critical patent/WO2023247737A1/fr

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355Personalisation of cards for use
    • G06Q20/3555Personalisation of two or more cards
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405Establishing or using transaction specific rules

Definitions

  • the invention relates to an assistance method for allowing controlled exchanges of data between different people (or members of a community) and one or more different entities or other people.
  • the invention relates to a system making it possible to implement this method.
  • a third party entity There are systems that allow people to pay or exchange information with a third party entity.
  • An example in the banking field is the use of prior art credit cards such as VISA ® or MASTERCARD ®.
  • the holder of such a card can pay a third party entity, for example a store, to purchase a product or service using their card.
  • a store terminal queries a card provider database and checks the authorization of the transaction. The card holder may be asked to confirm the transaction by entering their own secret code, determined on an individual basis.
  • a health card may want to transfer personal information about him to a healthcare organization or to a store such as a pharmacy.
  • a reading terminal of the organization can connect to a database bringing together the desired medical information.
  • authorization to access the desired information takes place via the use of the card, possibly also by the additional entry of a secret code by the user.
  • Other examples of such individual cards are possible, for example to exchange non-medical information between a person and a store or organization.
  • Each user's card can be a physical or virtual card which is accessed via an application hosted on their mobile phone for example.
  • one of the aims of the present invention is to provide a method for controlling data exchanges that different members of a community or a group are required to carry out.
  • a computer-implemented method is proposed to control data exchanges that different members of a community are required to carry out and comprising the following steps: i. define a manager for said community; ii. create a profile of the manager, said manager profile comprising information linked to a main account and access rights to said main account; iii. create user profiles for each community member; iv. assign to each member of the community a card allowing them to carry out data exchanges, each of said cards being associated with said main account; v. offer the manager the possibility of defining a rule for using each member's card; as well as the step of informing the manager when a member uses their card.
  • the different users or, equivalently, members are part of a community and a manager is defined for it.
  • the manager must define a profile and a main account is associated with the community.
  • the manager has rights to access the main account, called access rights.
  • Different user profiles are created for different community members. Such profiles can be generated by the manager for example.
  • Each user is also given a card which can be physical or virtual.
  • the method of the invention proposes to offer the possibility to the manager to define one or more card use rules for each member of the community. This makes it possible to control the exchanges that the different members of the community are required to carry out, based on their card. In particular, thanks to these rules of use by the manager, it is possible to have control of the exchanges desired by the members of the community which is not only carried out by the card holder or by the organization issuing the cards. cards. Ultimately, the method of the invention therefore allows for finer and more flexible control. Indeed, it is possible for the manager to define various rules, for example different rules for different users.
  • This control is reinforced by the information provided to the manager when a member uses their card.
  • the manager is thus kept informed of the data exchanges associated with his main account and can therefore intervene if necessary to regulate these exchanges, for example, by modifying the usage rule or, as described below, by defining a new one.
  • manager control facilitates the management of the main account, and improves the security of data exchange.
  • the method according to the invention allows members to exchange data via cards from a main account to which they preferably do not have access. For example, only the result of the data exchange can be visible to the member, so he does not have access to the main account data as such.
  • This is advantageous in the case of a financial transfer so that the member cannot view the account principal (banking) of the manager (his balance or even his transactions for example), as well as in the case of a transfer of sensitive data, for example medical, from one organization to another.
  • the manager is then the only one to have access to the main account and the data associated with it and can exercise adequate control over them.
  • the manager can be a family man, a person with business responsibilities. Other examples are possible.
  • the usage rule of each member's card is a usage limit.
  • a usage limit may be a limit in terms of the number of exchanges allowed for a given period of time. For example, the manager can impose a maximum number of exchanges per day, three exchanges per week, etc.
  • Another example of a usage limit is a maximum number of exchanges of information for a given member: for example, no more than two pieces of information exchanged among the different possible pieces of information for a given user or member.
  • the usage rule may be a limit of money that can be used by a given member, possibly over a given period. For example, maximum 1000 EUR for such member.
  • the manager can personalize and control the different exchanges that the different members can carry out.
  • assigning a card to each member in step iv. is automatic once user profiles are created in step iii. This makes it possible to further automate the method of the invention and therefore to have a method that is even easier to use.
  • the method preferably also includes the step of informing the manager of the usage status of each member's card when such a member uses his or her card.
  • This information can be understood as a preferred form of the generic step of informing the manager when the member uses their card. This embodiment allows the manager to be kept regularly informed of the activity of the different members.
  • the method preferably includes the step of offering the manager the possibility of defining a new rule for using the card of one or more members. Thanks to this preferred embodiment, the method of the invention is even more flexible because it is possible to modify the rule of use of each membership card and/or to define a new one, in particular with regard to of data exchanges of which he is kept informed. The manager thus exercises better control over data exchanges.
  • the method further comprises the step of offering the manager the possibility of authorizing or refusing each exchange of data carried out by means of one of the cards by one of the members on the basis of the information of using the card.
  • the manager in addition to being the only one who actually has access to the main account, can exercise total control over each data exchange.
  • Each member must receive approval from the manager to use their card (i.e. implement the data exchange). Control of these exchanges is further strengthened.
  • authorization of an exchange of data includes reading the QR code associated with this exchange of data (according to the embodiment introduced above) by means of an electronic device.
  • reading (for example, scanning) the QR code is enough, it contains all the information relating to the exchange of data.
  • it is expected that reading the QR code also generates a signature authorizing the exchange of data.
  • the aforementioned electronic device is, for example, a mobile phone (for example a smartphone) of the manager on which it receives the QR code via a dedicated application. It can be planned that beyond a predefined time to read the QR code, for example 60 or 120 seconds, the exchange of data is considered passively refused by the manager.
  • an authorization response (which can preferably be an authorization or refusal to carry out the exchange of data) for use of the card (or equivalently, of the exchange of data) for the member, according to the rule defined in step v.
  • This process describes the use of a card by a member of the community, with control exercised by the manager.
  • the method of the invention manages and controls data flow or exchanges from members.
  • the management program is able to implement the method according to the implementation allowing the manager to authorize or refuse each exchange of data.
  • the authorization response depends on preference also of the authorization or refusal of data exchange by the manager based on the card usage information.
  • the terms “depending on” above are not to be interpreted in a restrictive manner because other parameters can be taken into account in the definition of the authorization response.
  • this refusal takes precedence over the rule defined in step v.
  • the manager therefore exercises reinforced control in two stages over the use of cards: on the one hand, via the basic rules of use, and on the other hand, via his power to authorize or refuse each exchange of data .
  • a distributed computer system is also proposed to control data exchanges that different members of a community are required to carry out and comprising:
  • - initialization interfacing means for defining a manager for said community and creating a manager profile, said manager profile comprising information linked to a main account and access rights to said main account;
  • this computer system includes all the means intended to implement the aforementioned method and process according to the invention.
  • FIG. 1 illustrates a community of members according to the invention
  • FIG. 2 illustrates an example of a visual interface allowing the manager to view in real time the degree of use of each member's card
  • FIG. 3 illustrates an example of data flow and instructions when a member uses a card.
  • the method according to the invention allows everyone to best manage data exchanges that different members 100 of their family, their company, or a group to which they belong, are required to carry out.
  • a manager 10 can carry out such control for different members 100 of a community 1, said community 1 therefore being able to represent a family, a company or any other group of people or members 100.
  • the method the invention allows a manager 10 of a community 1 to specify who can use and/or withdraw what amount of money and according to what criteria or rules.
  • Figure 1 illustrating in particular the notions of members 100 and manager 10 of a community 1.
  • a first step of the method of the invention consists of defining a manager 10 for the community 1.
  • the manager 10 can be a father, a business manager, or any other person with responsibilities vis-à-vis 'a group or community 1.
  • the manager 10 must create a profile.
  • This profile may include different information such as: name, first name, place of residence, date of birth, sex, etc. But this profile must also include information linked to a main account 20 and access rights for this main account 20.
  • the main account 20 can be of different types. It may be an account comprising information for the different members 10 of the community 1, for example medical, personal information, subscription information, etc. It may also be an account of banking type, characterized for example by a global sum to which members 10 of community 1 may possibly have access. Examples of information linked to the main account 20 are: references to said main account 20 allowing it to be found. Examples of access rights are login, password, TOKEN.
  • the manager profile 10 has been created, it is then necessary to define user profiles for each member 100 of the community 1.
  • the profile of each member 100 can include different information such as: name, first name, place of residence , date of birth. Other fields can be used for the profiles of each 100 member.
  • the manager can include different information such as: name, first name, place of residence , date of birth. Other fields can be used for the profiles of each 100 member.
  • the manager can include different information such as: name, first name, place of residence , date of birth. Other fields can be used for the profiles of each 100 member.
  • the manager Preferably, the manager
  • the method of the invention comprises a step of offering the manager 10 the possibility of defining one or more rules for using the card 1 10 of each member 100. This or these rules make it possible to control the exchanges that different members 100 of community 1 are required to perform.
  • a manager 10 of a community 1 can control the use of the card 110 of each member 100.
  • the method is particularly flexible and allows for example to define different rules for the members 100 .
  • An example of a usage rule is to set a card usage limit. For example, manager 10 can decide that such member 100 cannot use his card 110 more than once per day. Another example of a usage limit in banking is setting a maximum amount that a 100 member can spend.
  • the manager 10 is informed when a member 100 uses his card 110 to make an exchange.
  • the method of the invention is implemented in an application that can be downloaded to a mobile phone.
  • the manager 10 can then be informed of the use of the card 110 of a member 100 via a visual interface 11 which he accesses by opening the application.
  • a visual interface 11 is schematically illustrated in Figure 2, said visual interface 11 comprising different information for the different members 100. This information preferably includes the state of use of the card 110 of each member 100 and a summary of the various exchanges carried out.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Storage Device Security (AREA)

Abstract

17 ABRÉGÉ Méthode et système d'assistance d'échanges contrôlés de données Méthode et système pour contrôler des échanges de données que différents membres (100) d'une communauté (1) sont amenés à effectuer et comprenant les étapes suivantes : i. définir un gestionnaire (10) pour ladite communauté (1); ii. créer un profil du gestionnaire (10) comprenant des informations liées à un compte principal (20) et des droits d'accès audit compte principal (20); iii. créer des profils d'utilisateur pour chaque membre (100); iv. attribuer à chaque membre (100) une carte (110) lui permettant d'effectuer des échanges, chacune des cartes (110) étant associée au compte principal (20); v. offrir au gestionnaire (10) la possibilité de définir une règle d'utilisation de la carte (110) de chaque membre (100); ainsi que l'étape d'informer le gestionnaire (10) lorsqu'un membre (100) utilise sa carte (110).

Description

Méthode et système d’assistance d’échanges contrôlés de données
Domaine technique
Selon un premier aspect, l’invention se rapporte à une méthode d’assistance pour permettre des échanges contrôlés de données entre différentes personnes (ou membres d’une communauté) et une ou plusieurs différentes entités ou autres personnes. Selon un deuxième aspect, l’invention se rapporte à un système permettant d’implémenter cette méthode.
Etat de la technique
Il existe des systèmes permettant à des personnes de payer ou d’échanger des informations avec une entité tierce. Un exemple dans le domaine bancaire est l’utilisation de cartes de crédit de l’art antérieur telles que VISA ® ou MASTERCARD ®. Le titulaire d’une telle carte peut payer une entité tierce, par exemple un magasin, pour acheter un produit ou service en utilisant sa carte. Par la simple utilisation de la carte, un terminal du magasin interroge une base de données du fournisseur de carte, et contrôle l’autorisation de la transaction. Eventuellement, il est demandé au titulaire de la carte de confirmer la transaction par l’introduction d’un code secret qui lui est propre, déterminé sur base individuelle.
Dans d’autres domaines où il s’agit plutôt d’échanger ou de transférer des informations, on peut se retrouver dans un cas de figure analogue. Par exemple, le titulaire d’une carte de santé peut vouloir transférer des informations personnelles le concernant à un organisme de soin ou à un magasin tel une pharmacie. Lors de l’utilisation de la carte, un terminal de lecture de l’organisme peut se connecter à une base de données regroupant les informations médicales voulues. Dans ce cas également, l’autorisation d’accéder aux informations voulues se fait via l’utilisation de la carte, éventuellement également par l’introduction supplémentaire d’un code secret par l’utilisateur. D’autres exemples de telles cartes individuelles sont possibles, par exemple pour échanger des informations non médicales entre une personne et un magasin ou organisme. La carte de chaque utilisateur peut être une carte physique ou virtuelle à laquelle on accède via une application hébergée sur son téléphone portable par exemple.
L’utilisation de telles cartes facilite le transfert d’informations. Néanmoins, le contrôle d’un tel transfert d’informations ou d’un paiement dans le cas de cartes de crédit n’est réalisé que par l’utilisateur seul une fois qu’on lui a attribué une carte. Pour cela, il présente sa carte à la partie avec laquelle il veut réaliser la transaction et éventuellement il lui est demandé d’introduire un code secret pour l’autoriser. Ainsi, il s’agit d’une démarche individuelle en ce qui concerne le contrôle d’échanges d’information ou d’argent, une fois qu’une carte a été attribuée à l’utilisateur. Il pourrait néanmoins être utile d’avoir un contrôle additionnel et ne reposant pas uniquement sur des règles générales à tous les détenteurs de carte. Il est également utile de pouvoir avoir un contrôle d’utilisation qui ne soit pas uniquement réalisé par le détenteur de la carte ou par l’organisme émetteur des cartes, afin d’avoir un contrôle plus fin et plus flexible.
Exposé de l’invention
Selon un premier aspect, un des buts de la présente invention est de fournir une méthode pour contrôler des échanges de données que différents membres d’une communauté ou un groupe sont amené à effectuer.
À cet effet, il est proposé une méthode implémentée par ordinateur pour contrôler des échanges de données que différents membres d’une communauté sont amenés à effectuer et comprenant les étapes suivantes : i. définir un gestionnaire pour ladite communauté ; ii. créer un profil du gestionnaire, ledit profil de gestionnaire comprenant des informations liées à un compte principal et des droits d’accès audit compte principal ; iii. créer des profils d’utilisateur pour chaque membre de la communauté ; iv. attribuer à chaque membre de la communauté une carte lui permettant d’effectuer des échanges données, chacune des desdites cartes étant associée audit compte principal ; v. offrir au gestionnaire la possibilité de définir une règle d’utilisation de la carte de chaque membre ; ainsi que l’étape d’informer le gestionnaire lorsqu’un membre utilise sa carte. Les différents utilisateurs ou, de façon équivalente, membres font partie d’une communauté et un gestionnaire est défini pour elle. Le gestionnaire doit définir un profil et un compte principal est associé à la communauté. Le gestionnaire possède des droits pour accéder au compte principal, appelés droits d’accès. Différents profils d’utilisateur sont créés pour les différents membres de la communauté. De tels profils peut être générés par le gestionnaire par exemple. On attribue également à chaque utilisateur une carte qui peut être physique ou virtuelle.
Chaque carte d’utilisateur est liée au compte principal de la communauté. La méthode de l'invention propose alors d’offrir la possibilité au gestionnaire de définir une ou plusieurs règles d’utilisation de carte pour chaque membre de la communauté. Cela permet de contrôler des échanges que les différents membres de la communauté sont amené à effectuer, sur base de leur carte. En particulier, grâce à ces règles d’utilisation par le gestionnaire, il est possible d’avoir un contrôle des échanges voulus par les membres de la communauté qui ne soit pas uniquement réalisé par le détenteur de la carte ou par l’organisme émetteur des cartes. In fine, la méthode de l’invention permet donc d’avoir un contrôle plus fin et plus flexible. En effet, il est possible pour le gestionnaire de définir diverses règles, par exemple des règles différentes pour différents utilisateur.
Ce contrôle est renforcé par l’information qui est faite au gestionnaire lorsqu’un membre utilise sa carte. Le gestionnaire est ainsi tenu informé des échanges données associés à son compte principal et il peut ainsi intervenir au besoin pour réguler ces échanges, par exemple, en modifiant la règle d’utilisation ou, comme décrit ci-après, en définissant une nouvelle.
De manière générale, le contrôle du gestionnaire facilite la gestion du compte principal, et améliore la sécurité des échanges de données. En outre, et de manière générale, la méthode selon l’invention aux membres d’effectuer des échanges de données via les cartes à partir d’un compte principal auquel ils n’ont de préférence pas d’accès. Par exemple, seul le résultat de l’échange de données peut être visible pour le membre, de sorte qu’il ne dispose pas accès au données du compte principal en tant que telles. Ceci est avantageux dans le cas d’un transfert financier pour que le membre ne puisse pas consulter le compte (bancaire) principal du gestionnaire (son solde ou même ses transactions par exemple), ainsi que dans le cas d’un transfert de données sensibles, par exemple médicales, d’un organisme vers un autre. Le gestionnaire est alors le seul à disposer des accès au compte principal et aux données qui y sont associés et peut exercer un contrôle adéquat sur celles-ci.
Les membres peuvent appartenir à une même famille, à un même groupe d’amis, ou faire partir d’une même société. Le gestionnaire peut être un père de famille, une personne avec des responsabilités d’une entreprise. D’autres exemples sont possibles.
Différents domaines d’application de la méthode de l’invention, tels que décrit dans la section ‘Etat de la technique’ sont possibles. Dans le cas du domaine bancaire ou financier, les cartes sont par exemple des cartes de crédit. La méthode de l’invention permet alors à un gestionnaire de définir des règles d’utilisation de telles cartes pour les différents détenteurs.
Différents modes de réalisation préférés vont maintenant être décrits, certains pouvant être combinés.
Selon un exemple possible, la règle d’utilisation de la carte de chaque membre est une limite d’utilisation. Une limite d’utilisation peut être une limite en termes de nombres d’échanges autorisés pour une période de temps donnée. Par exemple, le gestionnaire peut imposer un nombre maximum d’échanges par jour, trois échanges par semaine, ... Un autre exemple de limite d’utilisation est un nombre maximum d’échanges d’information pour tel membre : par exemple, pas plus de deux informations échangées parmi les différentes informations possibles pour tel utilisateur ou membre. Dans le cas de cartes de crédit, la règle d’utilisation peut être une limite d’argent qui peut être utilisée par tel membre, éventuellement sur une période donnée. Par exemple, maximum 1000 EUR pour tel membre.
Selon d’autres exemples possibles, la règle d’utilisation de la carte de chaque membre comprend :
- une autorisation pour un membre d’effectuer un échange donné ; et/ou
- une interdiction pour un membre d’effectuer un échange donné.
Ainsi, le gestionnaire peut personnaliser et contrôle les différents échanges que les différents membres peuvent effectuer. De préférence, l’attribution d’une carte à chaque membre à l’étape iv. est automatique une fois les profils d’utilisateur créés à l’étape iii. Cela permet d’automatiser d’autant plus la méthode de l’invention et donc d’avoir une méthode encore plus facile d’utilisation.
La méthode comprend de préférence également l’étape d’informer le gestionnaire de l’état d’utilisation de la carte de chaque membre lorsqu’un tel membre utilise sa carte. Cette information peut être comprise comme une forme préférée de l’étape générique d’informer le gestionnaire lorsque le membre utilise sa carte. Ce mode de réalisation permet au gestionnaire d’être tenu informé de manière régulière de l’activité des différents membres.
La méthode comprend de préférence l’étape d’offrir au gestionnaire la possibilité de définir une nouvelle règle d’utilisation de la carte d’un ou plusieurs membres. Grâce à ce mode de réalisation préféré, la méthode de l’invention est encore plus flexible car il est possible de modifier la règle d’utilisation de chaque carte de membre et/ou d’en définir une nouvelle, et ce en particulier au regard des échanges de données desquels il est tenu informé. Le gestionnaire exerce de la sorte un meilleur contrôle sur les échanges de données.
Les caractéristiques préférées relatives à une « règle d’utilisation >> mentionnées ci-avant s’appliquent de façon semblable à ladite nouvelle règle d’utilisation, celle-ci n’étant rien d’autre qu’une règle d’utilisation. En particulier, le gestionnaire peut entreprendre d’établir une limite d’utilisation, ou d’interdire un membre d’effectuer certains échanges de données sur base de l’information d’utilisation de carte qu’il reçoit, via une nouvelle règle d’utilisation de la carte du membre en question.
En particulier, et de préférence, la nouvelle règle d’utilisation peut être définie en fonction d’un état d’utilisation de la carte dont est préalablement informé le gestionnaire à chaque utilisation de la carte. Le gestionnaire peut ainsi accroître son contrôle sur l’utilisation des cartes par ses membres en réponse à l’état d’utilisation des cartes.
Selon un mode de réalisation préféré, la méthode comprend en outre l’étape de générer un QR code associé à un échange de données lorsqu’un membre utilise sa carte. Dans ce cas, en outre, l’étape d’informer le gestionnaire comprend une transmission au gestionnaire du QR code associé à l’échange de données. Avantageusement, le QR code est un format de code d’information sûr et commun. Il permet au gestionnaire de recevoir toute l’information nécessaire relative à l’échange de données en instance ou effectués de façon compacte et pratique, mais aussi discrète, sans qu’un tiers puisse la décrypter à première vue. Dans le cas d’échanges d’argent, le QR code peut en outre être exploité par les technologies existantes de paiement.
Selon un autre mode de réalisation préféré, la méthode comprend en outre l’étape d’offrir au gestionnaire la possibilité d’autoriser ou refuser chaque échange de données effectué au moyen d’une des cartes par un des membres sur base de l’information d’utilisation de la carte. En particulier, dans ce cas, le gestionnaire, en plus d’être le seul à disposer réellement des accès au compte principal, peut exercer un contrôle total sur chaque échange de données. Chacun des membres doit recevoir l’aval du gestionnaire pour utiliser sa carte (c’est-à- dire mettre en oeuvre l’échange de données). Le contrôle de ces échanges est encore renforcé.
De préférence, l’autorisation d’un échange de données comprend une lecture du QR code associé à cet échange de données (selon le mode de réalisation introduit ci-avant) au moyen d’un dispositif électronique. Ceci permet de faciliter la vie du gestionnaire dans l’autorisation des échanges de données. En effet, la lecture (par exemple, scan) du QR code suffit, celui-ci contenant toute l’information relative à l’échange de données. De préférence, il est prévu que la lecture du QR code génère également une signature d’autorisation de l’échange de données. Le dispositif électronique susdit est quant à lui, par exemple, un téléphone portable (par exemple un smartphone) du gestionnaire sur lequel il reçoit le QR code via une application dédiée. Il peut être prévu qu’au-delà d’un temps prédéfini pour lire le QR code, par exemple 60 ou 120 secondes, l’échange de données est considéré comme refusé passivement par le gestionnaire.
Selon un mode de réalisation de l’invention, la méthode comprend l’étape de géolocaliser la carte d’un des membres lorsqu’elle est utilisée. Dans ce cas, l’information du gestionnaire comprend de préférence une transmission au gestionnaire de la géolocalisation de la carte. Ceci permet avantageusement d’accroître le contrôle du gestionnaire sur les cartes et son compte principal, de même que de s’assurer de la localisation du membre qui effectue un échange de données. Avantageusement, il est également rendu possible de tracer la carte en cas de perte ou de vol.
De préférence, la méthode comprend en outre l’étape de donner accès au gestionnaire à une interface visuelle lui permettant de visualiser en temps réel le degré d’utilisation de la carte de chaque membre. Cela permet d’assurer un bon suivi de d’utilisation de la carte de chaque membre, et en fonction, d’éventuellement modifier et/ou définir une nouvelle règle d’utilisation de la carte d’un membre donné.
Selon un exemple possible, la méthode comprend en outre l’étape de regrouper les différents membres de la communauté en sous-groupes. Cela permet de scinder les différents membres en sous-groupes distincts. Il est alors possible de définir des règles d’utilisation propres pour les membre d’un même sous-groupe. De préférence, la méthode comprend alors l’étape d’attribuer des mêmes règles d’utilisation de carte pour les membres d’un même sous-groupe.
Les inventeurs proposent un procédé d’utilisation d’une carte d’un membre d’une communauté comprenant toutes les étapes de l’une quelconque des revendications précédentes et comprenant en outre les étapes suivantes :
- demande par ledit membre d’utiliser sa carte (ou de façon équivalente d’effectuer un échange de données au moyen de sa carte) ;
- envoi à une entité tierce de la demande de l’étape précédente ;
- transfert de cette demande par ladite entité tierce à un programme de gestion apte à implémenter la méthode pour contrôler des échanges de données selon l’un des modes de réalisation susmentionné ;
- fournir une réponse d’autorisation (laquelle peut de préférence être une autorisation ou un refus d’effectuer l’échange de données) d’utilisation de la carte (ou de façon équivalente, de l’échange de données) pour le membre, en fonction de la règle définie à l’étape v.
Ce procédé décrit une utilisation d’une carte par un membre de la communauté, avec le contrôle exercé par le gestionnaire. Ainsi, la méthode de l’invention gère et contrôle flux de données ou échanges issus des membres.
De préférence, le programme de gestion est apte à implémenter la méthode selon la réalisation permettant au gestionnaire d’autoriser ou de refuser chaque échange de données. Dans ce cas, la réponse d’autorisation dépend de préférence également de l’autorisation ou du refus d’échange de données par le gestionnaire sur base de l’information d’utilisation de la carte. En particulier, les termes « en fonction de >> ci-dessus ne sont pas à interpréter de façon limitative car d’autres paramètres peuvent être pris en compte dans la définition de la réponse d’autorisation. Dans le cas d’un refus du gestionnaire, ce refus prime sur la règle définie à l’étape v. Le gestionnaire exerce donc un contrôle renforcé en deux étapes sur l’utilisation des cartes : d’une part, via les règles d’utilisation de base, et d’autre part, via son pouvoir d’autoriser ou de refuser chaque échange de données.
Il est également proposé un système informatique distribué pour contrôler des échanges de données que différents membres d’une communauté sont amenés à effectuer et comprenant :
- des moyens d’interfaçage d’initialisation pour définir un gestionnaire pour ladite communauté et créer un profil de gestionnaire, ledit profil de gestionnaire comprenant des informations liées à un compte principal et des droits d’accès audit compte principal ;
- des moyens d’interfaçage pour créer des profils d’utilisateur pour chaque membre de la communauté ;
- des cartes, dont chacune d’entre elles est attribuée à un membre de la communauté pour lui permettre d’effectuer des échanges, et dont chacune d’entre elles est associée au compte principal ;
- des moyens de contrôle pour offrir la possibilité au gestionnaire de définir une règle d’utilisation de la carte de chaque membre.
De manière plus générale, ce système informatique comprend tous les moyens destinés à mettre en oeuvre la méthode et le procédé susdits selon l’invention.
Les modes de réalisation et avantages de la méthode s’appliquent au système, mutatis mutandis. Les cartes peuvent être réelles ou virtuelles. Dans ce dernier cas, un membre peut par exemple y avoir accès par l’intermédiaire d’une application installée sur son téléphone portable. Brève description des figures
Ces aspects ainsi que d’autres aspects de l’invention seront présentés dans la description détaillée de modes de réalisation particuliers de l’invention, référence étant faite aux dessins des figures, dans lesquelles:
- la figure 1 illustre une communauté de membres selon l’invention;
- la figure 2 illustre un exemple d’interface visuelle permettant au gestionnaire de visualiser en temps réel le degré d’utilisation de la carte de chaque membre;
- la figure 3 illustre un exemple de flux de données et d’instructions lors de l’utilisation d’une carte par un membre.
Les dessins des figures ne sont pas à l’échelle. Généralement, des éléments semblables sont dénotés par des références identiques dans les figures. La présence de numéros de référence aux dessins ne peut être considérée comme limitative, y compris lorsque ces numéros sont indiqués dans les revendications.
Description détaillée de modes de réalisation de l’invention
La méthode selon l’invention permet à chacun de gérer au mieux des échanges de données que différents membres 100 de sa famille, de son entreprise, d’un groupe auquel on appartient, sont amenés à effectuer. En particulier, un gestionnaire 10 peut réaliser un tel contrôle pour différents membres 100 d’une communauté 1 , ladite communauté 1 pouvant donc représenter une famille, une entreprise ou tout autre groupe de personnes ou membres 100. Dans le cas de l’application bancaire ou financière, la méthode l’invention permet à un gestionnaire 10 d’une communauté 1 de spécifier qui peut utiliser et/ou retirer quelle somme d’argent et selon quels critères ou règles. La méthode va maintenant être décrite, la figure 1 illustrant notamment les notions de membres 100 et de gestionnaire 10 d’une communauté 1 .
Une première étape de la méthode de l’invention consiste à définir un gestionnaire 10 pour la communauté 1. Le gestionnaire 10 peut être un père de famille, un dirigeant d’entreprise, ou toute autre personne ayant des responsabilités vis-à-vis d’un groupe ou d’une communauté 1. Ensuite, le gestionnaire 10 doit créer un profil. Ce profil peut comprendre différentes informations telles que par exemple : nom, prénom, lieu de résidence, date de naissance, sexe, ... Mais ce profil doit également comprendre des informations liées à un compte principal 20 et des droits d’accès pour ce compte principal 20. Le compte principal 20 peut être de différentes sortes. Il peut s’agir d’un compte comprenant des informations pour les différents membres 10 de la communauté 1 , par exemple des informations médicales, personnelles, des informations d’abonnement, ... Il peut également s’agir d’un compte de type bancaire, caractérisé par exemple par une somme globale à laquelle les membres 10 de la communauté 1 pourront éventuellement avoir accès. Des exemples d’informations liées au compte principal 20 sont : références dudit compte principal 20 permettant de le retrouver. Des exemples de droit d’accès sont login, mot de passe, TOKEN.
Une fois le profil de gestionnaire 10 créé, il s’agit ensuite de définir des profils d’utilisateur pour chaque membre 100 de la communauté 1. Le profil de chaque membre 100 peut comprendre différentes informations telles que : nom, prénom, lieu de résidence, date de naissance. D’autres champs peuvent être utilisés pour les profils de chaque membre 100. De préférence, le gestionnaire
10 peut créer ces différents profils d’utilisateur en utilisant une interface visuelle
1 1 qui peut être hébergée par exemple dans une application de son téléphone portable (voir figure 2).
Une fois les profils d’utilisateur créés, il s’agit ensuite d’attribuer une carte 1 10 à chaque membre 100 de la communauté 1. Il peut s’agir d’une carte physique ou d’une carte virtuelle. Dans ce dernier cas, il est préféré de prévoir l’accès à une telle carte virtuelle en utilisant une application hébergée sur le téléphone portable de chaque membre 100. La carte 1 10 permettra plus tard à chaque membre 100 de réaliser des échanges avec une entité ou personne tierce. Dans le cas d’une application bancaire de la méthode de l’invention, les cartes 1 10 sont de préférence des cartes de crédit. Et le compte principal 20 est alors un compte en banque dans le système de l’organisme émettant les cartes 1 10.
De préférence, la commande et l’attribution de cartes 1 10 sont automatiques une fois les profils d’utilisateur créés. Les différentes cartes 1 10 sont associées au compte principal 20. Cela veut dire que les cartes 110 permettent de réaliser des échanges de données, d’argent, ... hébergés d’une manière ou d’une autre dans le compte principal 20.
Finalement, la méthode de l’invention comprend une étape d’offrir au gestionnaire 10 la possibilité de définir une ou plusieurs règles d’utilisation de la carte 1 10 de chaque membre 100. Ce ou ces règles permettent de contrôler les échanges que différents membres 100 de la communauté 1 sont amenés à effectuer. Ainsi, grâce à la méthode de l’invention, un gestionnaire 10 d’une communauté 1 peut contrôler l’utilisation de la carte 110 de chaque membre 100. La méthode est particulièrement flexible et permet par exemple de définir différentes règles pour les membres 100.
Un exemple de règle d’utilisation est de définir une limite d’utilisation de la carte. Par exemple, le gestionnaire 10 peut décider que tel membre 100 ne peut pas utiliser sa carte 110 plus d’une fois par jour. Un autre exemple de limite d’utilisation dans le domaine bancaire est définir une somme maximale qu’un membre 100 peut dépenser.
Un autre exemple de règle d’utilisation est une autorisation ou interdiction pour un membre 100 d’effectuer un échange donné. Par exemple, un gestionnaire 10 peut décider qu’un membre 100 ne puisse pas échanger des informations ou de l’argent avec une entité tierce donnée.
De préférence, le gestionnaire 10 est informé lorsqu’un membre 100 utilise sa carte 110 pour réaliser un échange. Cela peut se faire de différentes manières. Dans une version préférée, la méthode de l’invention est implémentée dans une application pouvant être téléchargée sur un téléphone portable. Dans un tel cas, le gestionnaire 10 peut alors être informé de l’utilisation de la carte 1 10 d’un membre 100 par l’intermédiaire d’une interface visuelle 1 1 à laquelle il accède par l’ouverture de l’application. Une telle interface visuelle 1 1 est schématiquement illustrée à la figure 2, ladite interface visuelle 1 1 comprenant différentes informations pour les différents membres 100. Ces informations comprennent de préférence l’état d’utilisation de la carte 1 10 de chaque membre 100 et un résumé des différents échanges effectués. Lorsque la méthode est implémentée dans une application hébergée sur le téléphone portable du gestionnaire 20, il peut être envisagé de créer une notification visuelle et/ou sonore à chaque fois qu’un membre 100 utilise sa carte 110. De préférence, le gestionnaire 10 peut modifier la ou les règles d’utilisation de la carte 1 10 de chaque membre 100 et/ou en définir de nouvelles. Cela permet d’avoir une méthode de contrôle encore plus flexible. Par exemple, dans le cas d’une application bancaire de l’invention, le gestionnaire 10 peut décider d’une nouvelle limite d’utilisation de la carte 110 d’un membre 100, à la hausse ou à la baisse.
Selon une variante possible, les inventeurs proposent en outre la possibilité de définir différents sous-groupes 2 pour les membres 100 d’une même communauté. Cela est illustré à la figure 1 . Une fois ces différents sous- groupes 2 créés, il est alors possible de définir une ou plusieurs règles communes pour les membres 100 d’un même sous-groupe 2. Cela permet d’avoir une gestion plus efficace des échanges car il n’est alors nécessaire de définir des règles d’utilisation pour chaque membre 100 individuellement. On peut le faire en imposant une ou plusieurs règles d’utilisation pour chaque sous- groupe 2.
La figure 3 illustre un exemple possible de flux de données, lorsqu’un membre 100 utilise sa carte 1 10. Selon un exemple possible, le membre 100 présente une carte 1 10 physique au niveau d’un terminal présent chez une personne avec laquelle il veut effectuer l’échange. Selon un autre exemple possible, le membre 100 présente sa carte 1 10 virtuelle à l’aide de son téléphone portable à la personne avec laquelle il veut effectuer un échange, par exemple un commerçant. Par cette présentation, le membre 100 manifeste en fait son souhait d’effectuer un échange, d’informations ou commercial par exemple (paiement dans le dernier cas). Cette requête est envoyée vers une entité tierce 200 qui est par exemple le propriétaires des cartes 1 10. De préférence, cette requête est en fait envoyée vers une base de données du propriétaire des cartes 1 10. Cette requête n’est pas directement traitée par le propriétaire des cartes mais est plutôt envoyée à un programme de gestion 300 apte à implémenter la méthode pour contrôler les échanges de données de l’invention. Par exemple, cette requête est envoyée vers une base de donnée hébergeant le programme de gestion 300 implémentant l’invention et reprenant les différents profils d’utilisateur des différents membres 100, ainsi que les informations du compte principal 20. Et c’est ce programme 300 qui autorise ou pas la transaction ou l’échange, sur base de la ou des règles d’utilisation définies par le gestionnaire 10. Selon un exemple possible, le programme de gestion 300 informe par ailleurs le gestionnaire 10 lorsqu’il autorise la transaction ou l’échange.
L’usage dans ce document des verbes « comprendre », « inclure >>, « comporter >>, ou toute autre variante, ainsi que leurs conjugaisons, ne peut en aucune façon exclure la présence d’éléments autres que ceux mentionnés. L’usage de l’article indéfini « un >>, « une >>, ou de l’article défini « le >>, « la >> ou « I’ >>, pour introduire un élément n’exclut pas la présence d’une pluralité de ces éléments. La présente invention a été décrite ci-dessus en relation avec des modes de réalisations spécifiques, qui ont une valeur purement illustrative et ne doivent pas être considérés comme limitatifs. Il apparaîtra de façon directe pour l’homme du métier que l’invention n’est pas limitée aux exemples illustrés ou décrits ci- dessus, mais que sa portée est plus largement définie par les revendications ci- après introduites.

Claims

Revendications
1. Méthode implémentée par ordinateur pour contrôler des échanges de données que différents membres (100) d’une communauté (1 ) sont amenés à effectuer et comprenant les étapes suivantes : i. définir un gestionnaire (10) pour ladite communauté (1 ) ; ii. créer un profil du gestionnaire (10), ledit profil de gestionnaire (10) comprenant des informations liées à un compte principal (20) et des droits d’accès audit compte principal (20) ; iii. créer des profils d’utilisateur pour chaque membre (100) de la communauté (1 ) ; iv. attribuer à chaque membre (100) de la communauté (1 ) une carte (1 10) lui permettant d’effectuer des échanges de données, chacune des desdites cartes (1 10) étant associée audit compte principal (20) ; v. offrir au gestionnaire (10) la possibilité de définir une règle d’utilisation de la carte (110) de chaque membre (100) ; dans laquelle la méthode comprend en outre l’étape d’informer le gestionnaire (10) lorsqu’un membre (100) utilise sa carte (1 10).
2. Méthode selon la revendication 1 , comprenant en outre l’étape d’informer le gestionnaire (10) de l’état d’utilisation de la carte (1 10) de chaque membre (100) lorsqu’un tel membre (100) utilise sa carte (1 10).
3. Méthode selon la revendication 1 ou 2, comprenant en outre l’étape d’offrir au gestionnaire (10) la possibilité de définir une nouvelle règle d’utilisation de la carte (10) d’un ou plusieurs membres.
4. Méthode selon la revendication 3 lorsqu’elle dépend de la revendication 2, dans laquelle ladite nouvelle règle d’utilisation est définie en fonction dudit état d’utilisation de la carte (1 10).
5. Méthode selon l’une quelconque des revendications 1 à 4, comprenant en outre l’étape de générer un QR code associé à un échange de données lorsqu’un membre (100) utilise sa carte (1 10), et dans laquelle l’étape d’informer le gestionnaire (10) comprend une transmission au gestionnaire (10) du QR code associé à l’échange de données. Méthode selon l’une quelconque des revendications 1 à 5, comprenant en outre l’étape d’offrir au gestionnaire (10) la possibilité d’autoriser ou de refuser chaque échange de données effectué au moyen d’une des cartes (110) par un des membres (100) sur base de l’information d’utilisation de la carte (1 10). Méthode selon la revendication 6, lorsqu’elle dépend de la revendication 5, dans laquelle l’autorisation d’un échange de données comprend une lecture du QR code associé à cet échange de données au moyen d’un dispositif électronique. Méthode selon l’une quelconque des revendications 1 à 7, comprenant en outre l’étape de géolocaliser la carte (1 10) d’un des membres (100) lorsqu’elle est utilisée, dans laquelle l’étape d’informer le gestionnaire (10) comprend une transmission au gestionnaire (10) de la géolocalisation de la carte (1 10). Méthode selon l’une quelconque des revendications 1 à 8 où la règle d’utilisation de la carte (10) de chaque membre (100) est une limite d’utilisation. Méthode selon l’une quelconque des revendications 1 à 9 où la règle d’utilisation de la carte (10) de chaque membre (100) comprend une autorisation et/ou une interdiction pour un membre (100) d’effectuer un échange donné. Méthode selon l’une quelconque des revendications 1 à 10, comprenant en outre l’étape de donner accès au gestionnaire (10) à une interface visuelle (1 1 ) lui permettant de visualiser en temps réel un degré d’utilisation de la carte (1 10) de chaque membre (100). Méthode selon l’une quelconque des revendications 1 à 11 , comprenant en outre l’étape de regrouper les différents membres (100) de la communauté (1 ) en sous-groupes (2), et d’attribuer des mêmes règles d’utilisation de carte (110) pour les membres (100) d’un même sous-groupe (2). Méthode selon l’une quelconque des revendications 1 à 12, dans laquelle chaque carte (110) est virtuelle et accessible depuis une application préalablement installée sur un téléphone portable d’un des membres (100). Procédé d’utilisation d’une carte (110) d’un membre (100) d’une communauté (1 ), comprenant toutes les étapes de l’une quelconque des revendications 1 à 13, et comprenant en outre les étapes suivantes :
- demande par ledit membre (100) d’effectuer un échange de données au moyen de sa carte (110) ;
- envoi à une entité tierce (200) de la demande de l’étape précédente ;
- transfert de cette demande par ladite entité tierce (200) à un programme de gestion (300) apte à implémenter la méthode selon l’une quelconque des revendications 1 à 13 ;
- fournir une réponse d’autorisation de l’échange de données pour le membre (100), en fonction de la règle définie à l’étape v. Procédé selon la revendication 14, dans lequel le programme de gestion (300) est apte à implémenter la méthode selon la revendication 6, et dans lequel la réponse d’autorisation dépend également de l’autorisation ou du refus d’échange de données par le gestionnaire (10) sur base de l’information d’utilisation de la carte (110).
PCT/EP2023/067058 2022-06-22 2023-06-22 Methode et systeme d'assistance d'echanges controles de donnees WO2023247737A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
BEBE2022/5494 2022-06-22
BE20225494A BE1030658B1 (fr) 2022-06-22 2022-06-22 Méthode et système d’assistance d’échanges contrôlés de données

Publications (1)

Publication Number Publication Date
WO2023247737A1 true WO2023247737A1 (fr) 2023-12-28

Family

ID=82399241

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/067058 WO2023247737A1 (fr) 2022-06-22 2023-06-22 Methode et systeme d'assistance d'echanges controles de donnees

Country Status (2)

Country Link
BE (1) BE1030658B1 (fr)
WO (1) WO2023247737A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090099965A1 (en) * 2007-08-21 2009-04-16 Grant Iv Francis C Prepaid expense card management platform
US20100063903A1 (en) * 2008-03-10 2010-03-11 Thayne Whipple Hierarchically applied rules engine ("hare")

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090099965A1 (en) * 2007-08-21 2009-04-16 Grant Iv Francis C Prepaid expense card management platform
US20100063903A1 (en) * 2008-03-10 2010-03-11 Thayne Whipple Hierarchically applied rules engine ("hare")

Also Published As

Publication number Publication date
BE1030658A1 (fr) 2024-01-24
BE1030658B1 (fr) 2024-01-29

Similar Documents

Publication Publication Date Title
EP3113099B1 (fr) Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants
FR2882880A1 (fr) Procede de securisation d'une transaction avec une carte de paiement, et centre d'autorisation pour la mise en oeuvre de ce procede
FR3010215A1 (fr) Procede de traitement de donnees transactionnelles, dispositifs et programmes d'ordinateur correspondants.
WO2013121127A1 (fr) Securisation d'une transmission de donnees
EP2353269A1 (fr) Procédé d'accès d'un utilisateur d'un terminal mobile à une pluralité de services et dispositif sécurisé associé
FR3110984A1 (fr) Partage sécurisé d'informations de justificatif d'identité
CA3151794A1 (fr) Infrastructure d'informations numeriques securisee
WO2023247737A1 (fr) Methode et systeme d'assistance d'echanges controles de donnees
EP2813962B1 (fr) Méthode de contrôle d'accès à un type de services spécifique et dispositif d'authentification pour le contrôle de l'accès à un tel type de services.
WO2019162589A2 (fr) Procédé et dispositif de répartition du montant d'une opération bancaire entre une pluralité d'utilisateurs
EP4038533A1 (fr) Procédé de gestion des droits et actifs d'un utilisateur sur une chaîne de blocs
EP1299837A1 (fr) Procede de distribution commerciale en ligne de biens numeriques par l'intermediaire d'un reseau de communication et dispositif electronique d'achat de biens numeriques distribues par ce procede
CA3161325A1 (fr) Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication
FR2889784A1 (fr) Dispositif nomade de distribution et d'utilisation de carte recharge electronique
FR3095066A1 (fr) Contrôle parental mis en œuvre dans un système de traitement d’une transaction associée à une carte de paiement détenue par un utilisateur assujetti à un décideur
WO2021123527A1 (fr) Procede et dispositif de gestion d'une autorisation d'acces a un service de paiement fourni a un utilisateur
WO2016189489A1 (fr) Procede et dispositif de distribution de produits prescrits
FR3115625A1 (fr) Transactions sans présence de la carte avec une valeur de vérification de carte choisie par le titulaire de la carte
FR2824208A1 (fr) Procede et dispositif d'attribution d'un code d'authentification
FR3011111A1 (fr) Securisation d'une transmission de donnees d'identification
FR3114714A1 (fr) Procédé d’accès à un ensemble de données d’un utilisateur.
CA2874705A1 (fr) Procede et systeme de reglage spatio-temporel des permissions de geolocalisation
Bartoo Financial services innovation: opportunities for transformation through facial recognition and digital wallet patents
WO2019180327A1 (fr) Procede de securisation de transfert et gestion de donnees, sur reseau internet ou analogue, a travers un portail ou plateforme d'echange de donnees.
FR2969880A1 (fr) Procede de traitement de donnees pour la gestion de transactions.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23748216

Country of ref document: EP

Kind code of ref document: A1