WO2014019026A1 - Système et procédé de transaction électronique - Google Patents

Système et procédé de transaction électronique Download PDF

Info

Publication number
WO2014019026A1
WO2014019026A1 PCT/AU2013/000852 AU2013000852W WO2014019026A1 WO 2014019026 A1 WO2014019026 A1 WO 2014019026A1 AU 2013000852 W AU2013000852 W AU 2013000852W WO 2014019026 A1 WO2014019026 A1 WO 2014019026A1
Authority
WO
WIPO (PCT)
Prior art keywords
merchant
client
message
account
payment
Prior art date
Application number
PCT/AU2013/000852
Other languages
English (en)
Inventor
Steven WILLOUGHBY
Original Assignee
Misolutions Pty Ltd
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
Priority claimed from AU2012903269A external-priority patent/AU2012903269A0/en
Application filed by Misolutions Pty Ltd filed Critical Misolutions Pty Ltd
Publication of WO2014019026A1 publication Critical patent/WO2014019026A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, 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/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices

Definitions

  • the present invention relates to electronic transaction systems and in particular to a transaction system and method utilising contactless technology such as for example Near-Field-Communications (NFC) or Blue-tooth-low-energy (BTLE) standards to process customer to merchant interactions.
  • contactless technology such as for example Near-Field-Communications (NFC) or Blue-tooth-low-energy (BTLE) standards to process customer to merchant interactions.
  • NFC Near-Field-Communications
  • BTLE Blue-tooth-low-energy
  • EFTPOS electronic funds transfer point of sale
  • a known payment system that can be used in a contactless environment is exemplified in Figure 1 .
  • the customer bank 1 issues a card 6 to a customer 3.
  • the card 6 may be any debit or credit card issued by financial institutions, such as for example a MASTERCARD or VISA card.
  • the bank 1 provides details of the card 6 and customer 3 to the relevant payment network 4.
  • the customer 3 decides to purchase a product or service from a merchant 5
  • the customer 3 swipes or taps their card 6 in a suitable terminal 7 located with the merchant 5.
  • the card 6 includes a contactless secure chip which can be read by the terminal 7 or other suitable point of sale device.
  • the terminal 7 transmits card and purchase details to the payment network 4. These details are then sent by the payment network 4 to the bank 1 of the customer 3.
  • the customer's bank 1 will firstly verify the request, and once satisfied the request is genuine the customer's bank 1 will then initiate payment to the merchant's bank 2 via the payment network 4.
  • the payment network 4 will then confirm payment to the merchant 5.
  • smart phone devices interchangeably known as mobile phones, mobile devices, mobiles or cell phones
  • Such technologies will allow users to pay merchants and conduct transactions by swiping their smart phone device on a current contactless enabled terminal. This eliminates the need for customers to carry chip-enabled cards as described above.
  • Such technologies and implementations can also be used for securely transferring data directly or indirectly associated with a payment, like coupons, discounts, loyalty, special offers, merchant info, merchant updates etc.
  • NFC smart phone devices can provide secure communications to process sensitive content through use of the 'secure element' of a smart phone device.
  • This 'secure element' provides strong hardware based cryptography functions for applications to store data, including credit card cryptographic keys.
  • the NFC 'secure element' chip details or access in the smart phone are not easily provided to third- parties such as banks, as these are often controlled by either the manufacturer and/or OS provider.
  • the present invention utilises contactless tags to initiate a pairing of messages received from both a client and a merchant in a secure manner, which can be subsequently be used to process transactions in existing channels.
  • Such a system does not rely on a 'secure element', but seeks to ensure security of the system through the utilization of cryptographically programmed contactless tags, verified by an external service.
  • the present invention provides an electronic transaction system including: a merchant module including a terminal to forward a first message to said system, said first message including transaction details and merchant security data; and a client module including a contactless enabled device to receive merchant identification data from said terminal and forward a second message to said system; wherein to effect a said system matches said first and second messages and forwards a confirmation message to said client module, said confirmation message seeking confirmation from a client that payment is to be transferred from said client's account to a merchant's account.
  • the client could have prenominated a payment source account to make payments from, and likewise the merchant could have a prenominated payment receiving account to receive funds; thereby enabling both parties through the verification of the system of the contactless tag, trust and assurance to execute the transaction in question.
  • the merchant identification data and the merchant security data may be identical.
  • the client module may send a third message to the client's financial institution to make payment from the client's account to the merchant's account.
  • the system may be used in a financial environment, where the payment comprises a funds transfer between a client's financial institution holding the client's account and a merchant's financial institution holding the merchant's account.
  • said client upon receipt of said confirmation message said client forwards said confirmation message to a third party to enable said third party to authorise payment be transferred from a third party account to said merchant's account.
  • a third party to enable said third party to authorise payment be transferred from a third party account to said merchant's account.
  • Forms of the present invention provide a secure transaction system that allows use of a contactless (NFC or BTLE etc) enabled device without requiring access to the 'secure element' of the device. Rather, merchant and client identification details are sent to an external system and matched to confirm transaction data. Authorisation of the transaction is also required from the client to enhance the security of the system.
  • NFC contactless
  • BTLE BTLE
  • Figure 2 is a system diagram illustrating one embodiment of the system of the present invention.
  • Figure 3 is a flow chart illustrating a method of one embodiment of the present invention.
  • Figure 4A is a flow chart depicting client operations relevant to the message matching system depicted in Figure 2.
  • Figure 4B is a flow chart depicting merchant operations relevant to the message matching system depicted in Figure 2.
  • Figure 4C is a flow chart depicting server operations relevant to the message matching system depicted in Figure 2.
  • Figure 5 shows a practical implementation of the method of Figure 3.
  • the present invention generally relates to methods and systems for matching payment transaction messages and requests between two parties, ideally where the matching process could be initiated by either party.
  • Embodiments of the invention are of particular use in environments where one client system requires another client system to receive and confirm unique message content.
  • FIG. 2 is a high level network diagram depicting various components that form part of an electronic transaction system according to one embodiment.
  • the system includes a client module 100, a merchant module 103 and a broker module 105.
  • the client module 100 includes a contactless enabled device 101 (which can receive messages for contactless terminals) which, in the context of the financial application referred to above, may be a NFC enabled smart phone and the (or part of) the financial institution's smart phone software application installed on the device 101 in which users can pay third parties via mobile phone or email address.
  • a contactless enabled device 101 which can receive messages for contactless terminals
  • the financial institution's smart phone software application installed on the device 101 in which users can pay third parties via mobile phone or email address.
  • the merchant module 103 includes a terminal 104 which, in the context of the financial application, may be the (or part of) a specific bank provided terminal or pin-pad application or point of sale (POS) application that sends a message to the broker module 105.
  • the terminal 104 includes a contactless tag 1 10 that when swiped by the contactless enabled device 101 , will activate the client application and matching request described below with a onetime contactless message.
  • Communications network 102 may include a variety of different networks (of the same or different types) having wired and/or wireless communications links or channels, with communications governed by a variety of communication protocols.
  • networks may include the Internet, local area networks, wide area networks, cellular voice/data networks.
  • the Broker module 105 will include an interface 106 that will send and receive messages to the Client 101 and Merchant 104 modules. Once a message is received by the interface 106, the message is sent to the Broker Application 107 which in turn uses the Broker Server Database (used to store non-sensitive data) 108 and Secure Database (used to store sensitive and authorisation data) 109 components to match messages.
  • Broker Server Database used to store non-sensitive data
  • Secure Database used to store sensitive and authorisation data
  • the system may also include a third party module 1 1 1 that will complete an action that takes place outside of the Client module 100 itself but is only executed upon the approval of the Client module 100.
  • the third party client may be a Bank system that processes payment transaction requests from the Client's Banking Application.
  • the system may include multiple co-existing Client modules 100, Merchant modules 103, and many Bank/Third-party modules 1 1 1 .
  • Each Client module 100 will be able to pass messages between each other, and seek approval from other Client's modules 100 to process a message or transaction.
  • This Client hierarchy could be a one to many or many to many relationship depending on the Client module settings.
  • Each Merchant module 103 will remain independent of other Merchant modules 103 with each Merchant module 103 being assigned one or many unique contactless tag 1 10.
  • a Merchant may have more than one Merchant module 103, for example payments like pay-at- table
  • the Client Module 100 or Merchant Module 103 may be implemented locally (e.g. native application, where the logic of the software is executed on local hardware), or remotely (web application, where the logic of the software is executed on remote hardware and conveyed to the device via a remote connection), or a combination of the two methods.
  • FIG 4A is a diagram depicting the workflow process that would occur on the proposed Client module 100.
  • the Client module 100 includes a smart phone and a banking application 101 .
  • the workflow begins by Client module 100 receiving an initiation contactless message request 300.
  • This message would contain a unique terminal identifier which ideally will be encrypted, and would activate 301 the client application 101 .
  • This message would ideally be a one-time message only, meaning the string received although always containing the contactless tag identifier, would be randomised each time it is sent by being combined with the AuthData (e.g. an OTP (one-time password that can only be verified successfully once before the password is marked as invalid)).
  • OTP one-time password that can only be verified successfully once before the password is marked as invalid
  • the application 101 would then send message 302 to the Broker module interface 106.
  • the application 101 would then receive a message from the Broker module in step 303.
  • the application 101 would then ask the user to either accept or reject or request another Client module's approval for the message received in 303 (304).
  • the application If accepted, in the context of a banking application, the application itself would approve a transfer for the amount to the account specified in 303 with a Third Party (e.g. Bank, 1 1 1 ). If rejected, in the context of a banking application, the application would deny the payment transfer for the amount to the account specified in 303; the sale is cancelled and another payment method sought. If the application requests a second Client module 1 12 approval, then the first Client Application 101 would send Msg3 (see Figure 3) to the second Client module 1 12 for approval via any channel (e.g. SMS, email, broker service). The approving Client application (either 101 or 1 13 or another Client application) would then send a message to the Broker module interface 106 (305) confirming the payment, as well as a confirmation message to the requesting Client module(s).
  • a Third Party e.g. Bank, 1 1 1 1
  • FIG. 4B is a diagram depicting the workflow process that would occur on the proposed Merchant module 103.
  • the Merchant module would include an application running on a pin-pad, smart phone, POS or any other device or system capable of executing the functionality of the merchant process.
  • the Merchant When the Merchant wishes the Client (although this approval could be another Client associated with the direct Client) to approve a payment, the Merchant would enter onto the terminal 104 the amount to be tendered. On approval, the Merchant terminal 104 would send message 31 0 to the Broker module interface 106. After the (Direct) Client application 101 has received the contactless message 300 (after phone swipe over component 1 10), the application 104 would then receive a confirmation message from the Broker module Interface 1 06 confirming a successful match 31 1 . The terminal 104 would then wait until message 312 was received and message (payment or transaction) content is confirmed.
  • FIG. 4C is a diagram depicting the workflow process that would occur on the proposed broker module 105.
  • the Broker module 105 would include a webserver that would receive, hold and match requests and messages from Clients and Merchants.
  • the workflow begins by broker module interface 106 receiving 320 and 321 messages, consequently either 320 then 321 , or 321 then 320. While these messages are waiting to be matched in step 322, the Broker module will hold these messages in queue until they are ready to be matched.
  • application 107 Once the Broker application 107 has identified, and matched the messages received in 320 and 321 , application 107 will generate and send a new message for client authorisation 323.
  • the Broker module interface 106 has received a confirmation message from either the first Client module 100 or a second Client module 1 12, then Broker module 105 will pass a confirmation receipt to the Merchant module 103.
  • Msgl Contains Message Content (e.g. Transaction
  • Msg2 Contains Mobile (U ser) ID and encrypted
  • Msg3 Message Content (e.g. Transaction Amount
  • AuthData Authorisation Data (e.g. Hash,
  • This data could vary depending on the specific implementation of the system.
  • the data and messages could be encrypted.
  • the merchant When the customer 200 decides to make a purchase from the merchant 204, the merchant would enter the amount of the purchase into a terminal or other point of sale device (see 103).
  • the terminal (or other point of sale device) would send a message 214 to the broker module.
  • the broker module 202 (also see 105) would hold this message data until it receives a request from the customer 212.
  • the customer 200 would swipe their NFC phone (see 1 00) on the merchants contactless tag terminal pre-registered with the broker module 202.
  • a message containing the Contactless Tag ID and AuthVector(OTP etc) activates the Banking application on the customers phone (see 101 ).
  • the contactless Tag which has been swiped 'wakes up' the phone and provides data to identify the merchant module (see 103).
  • the contactless phone then sends the message to the broker module 212.
  • the broker module may receive either the terminal/merchant data first, or the customer data first.
  • the broker module will hold both client request 212 and merchant package 214 messages until they can be matched by comparing the Contactless Tag ID (which should be a unique string).
  • the purchase amount may actually be entered by the customer.
  • the contactless phone would also send the transaction amount.
  • the system may be configured such that the merchant approves the transaction amount before the message is sent by the contactless phone, or in the alternative the system provider can seek confirmation from the merchant as to the transaction amount.
  • the identifying data provided by the merchant to the customer may differ from the data transmitted by the merchant to, and held by, the broker module. In this way further security is provided as only the broker module and merchant know the unique merchant data.
  • the merchant may have a public identifier that is provided to customers and a private identifier that is known only to the broker module and merchant
  • the broker module 202 Once the broker module 202 has received data from both the merchant 214 and customer 212, the broker module will match the two messages. This is to ensure that the correct customer details are linked to the purchase being made from the merchant.
  • the broker module 202 will send a message to both the customer 200 and merchant 204.
  • the message to the customer 219 will seek confirmation that the customer wishes to make the payment.
  • the message could also provide further information identifying the merchant 218.
  • the message to the merchant can confirm that a match has been made and customer approval is required 206.
  • the customer can then receive the Msg Content (Amount of Transaction) 220, displayed in the Banking application 101 .
  • the customer will then be asked to accept or reject the transaction.
  • the Banking application 101 will confirm with the Bank to transfer the money to the pre-registered merchant's bank account 226. The customer will then send a confirmation message 228 back to the broker module, which will in turn pass confirmation 230 back to the Merchant.
  • the Banking application will send a confirmation message (of rejection) 228 back to the broker module , which will in turn pass confirmation (rejection) 230 back to the Merchant .
  • the customer and merchant will then organize for another payment method.
  • the customer would be able to forward the purchase request to a third person 222. This third person would then be able to approve the purchase in the same was as the original customer. In this way a third person can effectively make payment for a customer wishing to purchase a product. As an example a parent could authorise payment for a purchase being made by a child.
  • the original client would send a message to the broker module requesting the original message be sent to the new client 222.
  • This new client would likewise accept or reject the transaction amount 224, and proceed similar to a normal client.
  • the Broker module would send a confirmation message to both the merchant and the original client.
  • Figure 5 demonstrates a possible implementation of the present invention, whereby a customer interacts with the system using a contactless enabled mobile device and self-checkout point-of-sale terminal to initiate both a loyalty and payment transaction.
  • the Customer (504) is present in the Store Environment (500), and is making a purchase on a self-checkout POS system (501 ), that has attached contactless tag (502).
  • POS System (501 ) and contactless tag (502) could or may not be connected directly to each other, but both have encryption keys preloaded and stored in the broker module service (51 1 ) in the system's infrastructure (510).
  • the Customer (504) has a mobile device with a payment application (503), that has a source of funds in which the Customer (504) can pay for the goods displayed and purchased through the self-checkout POS system (501 ).
  • the mobile device (503) has internet (520) connectivity so that the payment application can communicate with the Broker Module Service (51 1 ) and the payment infrastructure (530) (the payment source provider, approver and transference mechanism).
  • Figure 5 also assumes that the POS System (501 ) and the Broker Module Service (51 1 ) can communicate and share information via a corporate or appropriate network.
  • the Customer (504) would begin a purchase on the POS System (501 ). At, before or during the process of scanning items on the POS System (501 ), Customer (504) would also tap their mobile device (503) on the contactless tag (502). This action would initiate the payment application on the customers mobile device (503). At this point the payment application would send a message via the Internet or similar global or other computer network (520) to the Broker Module Service (51 1 ), confirming the swipe of the contactless tag (502), and requesting verification of the tag. This message could also contain the Customer's (504) preloaded loyalty card details if applicable and preferred payment source.
  • the broker module service (51 1 ) would then verify the request from the mobile device (503), and if successful, match the contactless tag (502) with the POS System (501 ) through a database lookup; and upon pairing, send messages to the payment application (503) confirming its request, and the POS System (501 ) presenting the Customer's (504) loyalty card.
  • the POS System (501 ) could process the Customer's (504) loyalty card and apply discounts, coupons offers etc. if applicable.
  • the Broker Module Service (51 1 ) would inform the POS System (501 ) of a successful transfer of money and payment of the goods purchased by Customer (504). The POS System (501 ) would then print the receipt or email the receipt for the Customer's (504) records.
  • the current invention changes the paradigm for processing contactless (particularly NFC & BTLE) messages, particularly in the context of processing secure financial or data transactions.
  • the invention uses accepted contactless protocols currently found in smart phones only as an initiation mechanism for matching messaging on a third-party message brokage server rather than a full transaction gateway, thereby alleviating the requirements for using the smart phone 'secure element' (which could involve modification of customers smart phone devices).
  • This paradigm shift also allows for Consumers to request others to remotely approve messages or transactions through the same message brokage service.

Landscapes

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

Abstract

L'invention concerne un système de transaction électronique comprenant un module de commerçant pourvu d'un terminal pour transférer un premier message au système, le premier message contenant des détails de transaction et des données de sécurité de commerçant; et un module de client pourvu d'un dispositif activé sans contact pour recevoir des données d'identification de commerçant à partir du terminal et transférer un second message au système; pour effectuer une transaction, le système met en correspondance les premier et second messages et transfère un message de confirmation au module de client, le message de confirmation cherchant une autorisation auprès d'un client pour que le paiement soit transféré du compte du client sur le compte d'un commerçant.
PCT/AU2013/000852 2012-07-31 2013-08-02 Système et procédé de transaction électronique WO2014019026A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AU2012903269A AU2012903269A0 (en) 2012-07-31 Electronic transaction system and method
AU2012903269 2012-07-31

Publications (1)

Publication Number Publication Date
WO2014019026A1 true WO2014019026A1 (fr) 2014-02-06

Family

ID=50026989

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2013/000852 WO2014019026A1 (fr) 2012-07-31 2013-08-02 Système et procédé de transaction électronique

Country Status (1)

Country Link
WO (1) WO2014019026A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019171288A1 (fr) * 2018-03-06 2019-09-12 Entersekt International Limited Transactions financières basées sur une communication sans contact

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090192912A1 (en) * 2008-01-30 2009-07-30 Kent Griffin Charge-for-service near field communication transactions
US20110131104A1 (en) * 2009-06-02 2011-06-02 Qualcomm Incorporated Mobile Commerce Authentication And Authorization Systems

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090192912A1 (en) * 2008-01-30 2009-07-30 Kent Griffin Charge-for-service near field communication transactions
US20110131104A1 (en) * 2009-06-02 2011-06-02 Qualcomm Incorporated Mobile Commerce Authentication And Authorization Systems

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019171288A1 (fr) * 2018-03-06 2019-09-12 Entersekt International Limited Transactions financières basées sur une communication sans contact

Similar Documents

Publication Publication Date Title
US10762406B2 (en) Secure QR code service
US10922675B2 (en) Remote transaction system, method and point of sale terminal
US10592899B2 (en) Master applet for secure remote payment processing
US20180285875A1 (en) Static token systems and methods for representing dynamic real credentials
US20190356489A1 (en) Method and system for access token processing
US20170200155A1 (en) Generating and sending encrypted payment data messages between computing devices to effect a transfer of funds
RU2718972C1 (ru) Расширенное взаимодействие устройств
US20140358796A1 (en) Methods and Apparatus for Performing Local Transactions
JP2022502888A (ja) 非接触カードの暗号化認証のためのシステムおよび方法
JP2022501875A (ja) 非接触カードの暗号化認証のためのシステムおよび方法
US11580531B2 (en) Systems and methods for minimizing user interactions for cardholder authentication
GB2511505A (en) Dual/multiple pin payment account
AU2023200221A1 (en) Remote transaction system, method and point of sale terminal
US20210004806A1 (en) Transaction Device Management
JP2022501873A (ja) 非接触カードの暗号化認証のためのシステムおよび方法
WO2019070421A1 (fr) Numérisation de certificat de paiement externe
JP2022551435A (ja) 複数の閉ループの安全性が保証された取引のシステム及び方法
EP3712828A1 (fr) Mécanisme de jeton de paiement
WO2014019026A1 (fr) Système et procédé de transaction électronique
US11722900B2 (en) Mobile device data security using shared security values
US20210390529A1 (en) Systems and methods for performing payment transactions using indicia-based associations between user interfaces
US20230289792A1 (en) System and Method for Authorizing Temporary Use of Accounts
US20230120485A1 (en) Token-For-Token Provisioning
CA3146619A1 (fr) Systeme et methode d'autorisation de l'utilisation temporaire de comptes
WO2021252796A1 (fr) Dispositif utilisateur multifonctionnel

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: 13825439

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13825439

Country of ref document: EP

Kind code of ref document: A1