EP3014539A1 - Procédé de transaction électronique et système informatique - Google Patents

Procédé de transaction électronique et système informatique

Info

Publication number
EP3014539A1
EP3014539A1 EP14725701.8A EP14725701A EP3014539A1 EP 3014539 A1 EP3014539 A1 EP 3014539A1 EP 14725701 A EP14725701 A EP 14725701A EP 3014539 A1 EP3014539 A1 EP 3014539A1
Authority
EP
European Patent Office
Prior art keywords
computer system
session
request
user
token
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP14725701.8A
Other languages
German (de)
English (en)
Inventor
Frank Dietrich
Manfred Paeschke
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bundesdruckerei GmbH
Original Assignee
Bundesdruckerei GmbH
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 Bundesdruckerei GmbH filed Critical Bundesdruckerei GmbH
Publication of EP3014539A1 publication Critical patent/EP3014539A1/fr
Pending legal-status Critical Current

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/12—Payment architectures specially adapted for electronic shopping 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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/18—Payment architectures involving self-service terminals [SST], vending machines, kiosks or multimedia terminals
    • 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
    • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • 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
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • 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/34—Payment 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/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • 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
    • G06Q20/4014—Identity check for transactions
    • 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
    • G06Q20/4014—Identity check for transactions
    • G06Q20/40145—Biometric identity checks

Definitions

  • the invention relates to an electronic transaction method and a computer system.
  • the invention is based on the object to provide an improved electronic transaction process and a corresponding computer system.
  • a “transaction” here means a financial transaction, such as the payment of a payment by making a transfer, a direct debit or credit card debit, an ordering process for ordering and delivering a physical good or data, and other logistical, commercial and / or financial transactions.
  • a “session” here means a temporary communication connection, that is to say a so-called communication session, which according to the OSI layer model can refer to the transport layer ("transport layer”) or the application layer ("application layer”) a session is an http session or an https session, in which case the transport layer is protected by symmetrical encryption, an "ID token” being understood here to mean, in particular, a portable electronic device which has at least one data memory for storing the at least one attribute and a communication interface for reading out the attribute.
  • the ID token preferably has a secure memory area for storing the at least one attribute in order to prevent the attribute stored in the memory area from being altered in an unauthorized manner or read out without the authorization required for this purpose.
  • the ID token can be a USB stick or a document, in particular a value or security document.
  • a document in particular a value or security document.
  • menf are understood as meaning paper-based and / or plastic-based documents, such as electronic identity documents, in particular passports, ID cards, visas and driver's licenses, vehicle registration documents, vehicle registration documents, company ID cards, health cards or other ID documents as well as chip cards, means of payment, in particular banknotes, bank cards and Credit cards, bills of lading or other credentials in which a data store for storing the at least one attribute is integrated.
  • the ID token can be a hardware token or a soft token if it is cryptographically bound to a hardware token, that is, for example, to a so-called secure element.
  • a cryptographically bound to a secure element soft token according to DE 10 2011 082 101, the disclosure of which is fully made to the full extent of the disclosure of the present patent application, generated.
  • I D provider computer system is understood here to mean a computer system which is designed to read out at least one attribute from the ID token of a user, Preferably, the ID provider computer system is operated in a so-called trust center in order to maximize one to create a high level of security.
  • a “service computer system” is understood here to mean a computer system which has a network interface for connection to the network, so that an internet browser or another application program can be used to access web pages stored or generated by the service computer system the service computer system is an Internet server providing an e-commerce or e-government application, in particular an online shop or a government server.
  • a "user computer system” is understood here as a computer system to which the user has access.
  • a personal computer (PC) a tablet PC or a mobile device, in particular a smartphone, with a conventional Internet browser such as Microsoft Internet Explorer, Safari, Google Chrome, Firefox or any other application program to access the service computer system act.
  • the user computer system has an interface for connection to the network, wherein the network may be a private or public network, in particular the Internet.
  • the request of the service computer system is a SAML request and the response of the ID provider computer system to this is a SAML response (see Security Assurance Markup Language (SAML) V2. 0 Technicai Overview, OASIS, Committee Draft 02, March 25, 2008).
  • SAML Security Assurance Markup Language
  • the request is transmitted from the service computer system via the user computer system to the I D provider computer system. Due to the receipt of the request by the user computer system, the further process for generating the response, including the authentication of the user and the I D provider computer system, is triggered.
  • the 1D provider computer system has a certificate in which the read rights for the execution of the read access are specified.
  • a “certificate” is understood here as a digital certificate, which is also referred to as a public-key certificate, which is a structured data that serves to identify a public key of an asymmetric cryptosystem of an identity, such as Example of a person or device to assign, for example, the certificate may conform to standard X.509 or another standard, preferably the card verification certificate (CVC).
  • the certificate may specify for which attribute or attributes of the user stored in the protected memory area of the ID token the I D provider computer system is authorized to perform the read access. These attributes may be personal attributes of the user, such as his name, place of residence and age. These attributes may be used in their combination as user recognition to access the payment information of the registered user. Alternatively or additionally, a pseudonym of the user, which is stored at least temporarily by the ID token, can also be used as the user identifier.
  • Embodiments of the invention are particularly advantageous in providing a universally applicable computer-implemented payment method suitable for e-commerce and e-government applications, which is flexible, convenient, and secure at the same time. This is made possible, in particular, by the fact that the payment method is based on an ID token, whereby the prerequisite for carrying out a payment transaction is both the authentication of the user to the ID token and the authentication of the I D provider computer system to the ID token ,
  • a first session is first established between the Internet browser of the user computer system and the service computer system via the Internet, wherein the first session may be an http session or an https session.
  • the user can enter a transaction request in the Internet browser, for example, to initiate a payment process.
  • the user has previously ordered a product via the service computer system and would like to pay for this ordered product, for which purpose the user enters the corresponding transaction request in the internet browser, which is transmitted to the service computer system via the first session.
  • the service computer system then generates a request, ie a request-response protocol request.
  • the request can have a predefined or standardized structure.
  • the request can be text-based, have an XML, ASN.1 or binary structure, or can be configured as a SAML request. to be.
  • the request for example the SAML request, contains an attribute specification which specifies the attributes to be read from the ID token for the execution of the transaction. These may be attributes identifying the user associated with the ID token and / or indicating payment information, such as account details or credit card information, and / or attributes pertaining to the ID token itself, such as its validity period, issue date and / or the issuing organization or authority.
  • the attribute specification may include the date of birth of the user if, for example, the age of majority of the user is to be verified by the service computer system as a prerequisite for the transaction to be performed.
  • the request also contains transaction data for specifying the transaction, that is to say, for example, a payment amount and account information, in particular the account connection of the service computer system to which the payment is to be made.
  • the request includes a Uniform Resource Locator (URL) of the I D provider computer system, which is to read the attributes from the ID token, and a URL of the service computer system for specifying a recipient for the response, which is based on the request from to generate the ID provider computer system.
  • URL Uniform Resource Locator
  • the service computer system generates an identifier for the request which uniquely identifies the request, e.g. a globally unique identifier (GUID).
  • GUID globally unique identifier
  • the request is signed by the service computer system using a private key of a cryptographic key pair associated with the service computer system. Due to the transaction request, a web page is transmitted from the service computer system to the user computer system via the first session and displayed by the internet browser or the application program, in particular a so-called app. Together with the website, the request is transmitted, but it is not displayed.
  • the website has at least one input field for inputting additional information which is required for carrying out the transaction.
  • This additional information can be, for example, an account or credit card information of the user and / or authentication information in order to authenticate the user to the service computer system.
  • the authentication information may be a one-time password (OTP).
  • OTP one-time password
  • the additional information is encrypted using the public key of the service computer system by the user computer system, so that only the encrypted additional information is subsequently forwarded via a second session from the Internet browser or the application program to the ID provider computer system via the network.
  • the second session is set up by calling the URL of the iD provider computer system, which contains the request.
  • the second session is set up as a protected communication connection, namely with an encrypted transport layer, ie with Transport Layer Security (TLS), which is also referred to as Secure Sockets Layer (SSL), in particular as an https session.
  • TLS Transport Layer Security
  • SSL Secure Sockets Layer
  • the ID provider computer system generates an identifier for a still-to-be-established third session due to the receipt of the request over the second session, i. a so-called session ID.
  • the ID provider computer system stores the request and the additional information received along with the request for the second session with the session ID for the third session.
  • the ID provider computer system then sends a message about the second session, which contains a logical address of the ID provider computer system and, for example, also the session ID of the third session. From this logical address, the Internet browser or the application program can later retrieve the response to the previously forwarded request.
  • the logical address may be a uniform resource locator (URL) through which the response is retrievable.
  • the third session is established on the application layer between a program of the user computer system and the I D provider computer system, via the secured transport layer of the second session.
  • the program may be a browser plug-in of the Internet browser or an application program other than the Internet browser.
  • the ID provider computer system then transmits to the program the third-session information needed to read the attribute (s) from the ID token.
  • This information includes at least one certificate of the 1D provider computer system, which includes an indication of read rights of the ID provider computer system for reading one or more attributes.
  • the program of the user computer system then checks whether the read rights specified in the certificate are sufficient to allow read access by the ID provider computer system to the attribute (s) to be read according to the attribute specification of the request. If the reading rights of the ID provider computer system are sufficient, the following further steps are taken: a) A local connection is established between the reader of the user computer system and the ID token.
  • a contact-type interface for example a chip card
  • ID token can be inserting the ID token into the reader.
  • ID token with a contactless interface, such as an RFID or FC interface
  • this can be done by placing the! D token on the reader.
  • Tokens with USB, BlueTooth or microSD cards as well as virtual SmartCards are also possible here.
  • PIN Personal Identification Number
  • a session key is agreed. In particular, the agreement of a session key can be made using a Diffie-Hellman protocol.
  • a fourth session is set up on the application layer between a program of the ID token and the ID provider computer system, this fourth session running over the local connection and the third session, and an additional one on the application layer End-to-end encryption is carried out using the session key agreed in step b.
  • the fourth session is then used to mutually authenticate the ID token and the ID provider computer system, for example using a challenge-response protocol.
  • the attribute (s) according to the attribute specification that the ID provider computer system has received with the request are now read from the ID token by the I D provider computer system through the fourth session. This requires the successful authentication of the user in step b and the successful mutual authentication of the ID token and the ID provider computer system in step d) and is encrypted over the fourth session, so that a maximum of security and trustworthiness in terms of given attributes is given.
  • the I D provider computer system then generates a response that contains the read-out attributes and the identifier of the request and / or the additional information according to the request-response protocol to which the request is subject.
  • a SAML response is generated accordingly.
  • the identifier of the request which is also contained in the response, is used to establish the logical assignment of request and response, ie the so-called binding.
  • the response is signed by the ID provider computer system and stored for retrieval by the logical address previously communicated to the user computer system via the message.
  • the user computer system then reads this response from the ID provider computer system using the logical address, for example the URL, and forwards the response to the service computer system via the first session thus the transaction is assigned by the Dtenst computer system, that is, for example, triggered a payment process and / or delivered an ordered product, if allowed by the content of the response.
  • the program of the user computer system is a browser plug-in of the Internet browser, wherein the Internet browser is a common browser program such as Microsoft Internet Explorer, Safari, Google Chrome or Firefox can.
  • the program of the user computer system may be an application program separate from the Internet browser.
  • the additional information entered by the user is payment information, such as, for example, an account connection of the user from which the payment amount specified in the request should be debited or withdrawn.
  • the so-called clearing that is to say the examination of the creditworthiness of the customer, as well as the initiation of the payment process can then be initiated by the ID provider computer system, which confirms the execution of the payment with the response to the service computer system.
  • This has the advantage that the service computer system has no knowledge of the payment information of the user, that is, in particular his account connection, must obtain.
  • the user may encrypt his payment information with the public key of the service computer system so that only the encrypted payment information of the user is transmitted to the ID provider computer system.
  • the I D provider computer system then forwards the encrypted payment information with the response to the service computer system, which decrypts the payment information and then performs the clearing and collects the payment amount from the user's account according to the payment information.
  • the computer system includes a terminal, such as an ATM or a vending machine.
  • a terminal such as an ATM or a vending machine.
  • the user may enter a request into the machine, such as for withdrawing cash or purchasing a particular product, such as a drink.
  • the machine displays an optically detectable pattern, such as a QR code, on its screen, which contains information in order to initiate the execution of the transaction.
  • the terminal is used as a mobile telecommunication device, in particular as a so-called smart meter, for billing e.g. of electricity or gas consumption, taximeter or smartphone with a billing function.
  • the URL of the service computer system For example, on the smartphone of a seller, the URL of the service computer system, the payment amount and the payee in the form of a visually recorded pattern and recorded with the camera of the user computer system, which may also be configured as a smartphone, are detected. In this way, everyday payment transactions can be processed safely and conveniently.
  • FIG. 1 is a block diagram of an embodiment of an ID token according to the invention
  • Fig. 2 shows an arrangement of an embodiment of an inventive
  • FIG. 1 shows an ID token 106, which may be, for example, an electronic identity card.
  • the protected memory area 120 of the ID token 106 serves to store a reference value that is required for authenticating a user 102 to the ID token 106.
  • This reference value is, for example, an identifier, in particular a so-called personal identification number (PIN), or reference data for a biometric feature of the user 102, which can be used for the authentication of the user against the ID token 106.
  • PIN personal identification number
  • the protected area 122 is for storing a private key and the protected memory area 124 is for storing attributes, such as the user 102, such as name, place of residence, date of birth, gender, and / or attributes including the ID token itself, such as the institution that created or issued the ID token, the validity period of the ID token, an identifier of the ID token, such as a passport number or a credit card number.
  • attributes such as the user 102, such as name, place of residence, date of birth, gender, and / or attributes including the ID token itself, such as the institution that created or issued the ID token, the validity period of the ID token, an identifier of the ID token, such as a passport number or a credit card number.
  • the electronic memory 118 may further include a memory area 126 for storing a certificate.
  • the certificate includes a public key associated with the private key stored in the protected storage area 122.
  • the certificate may have been initialed according to a Public Key Infrastructure (PKI) standard, for example according to the X.509 standard.
  • PKI Public Key Infrastructure
  • the certificate does not necessarily have to be stored in the electronic memory 118 of the ID token 106.
  • the certificate may also be stored in a public directory server.
  • the ID token 106 has a processor 128.
  • the processor 128 is used to execute program instructions 130, 132 and 134.
  • the program instructions 130 are used for user authentication, ie authentication of the user 102 against the ID token.
  • the user 102 inputs his PIN to his authentication in the ID token 106, for example via the user computer system 100.
  • Execution of the program instructions 130 then accesses the protected memory area 120 to store the entered PIN with the PIN to compare there stored reference value of the PIN. In the event that the entered PIN matches the reference value of the PIN, the user 102 is considered authenticated.
  • a biometric feature of the user 102 is captured.
  • the ID token 106 has a fingerprint sensor or a fingerprint sensor is connected to the user's computer system 100.
  • the biometric data acquired by the user 102 is compared to the biometric reference data stored in the protected memory area 120 by executing the program instructions 130 in this embodiment. If the biometric data captured by the user 102 sufficiently matches the biometric reference data, the user 02 is considered authenticated.
  • the program instructions 134 are used to execute the steps of a cryptographic protocol relating to the ID token 106 for authenticating an ID provider computer system 136 to the ID token 106.
  • the cryptographic protocol may be based on a challenge-response protocol act on a symmetric key or an asymmetric key pair.
  • the cryptographic protocol implements an Extended Access Control method as specified for machine-readable travet documents (RTD) by the International Aviation Authority (ICAO).
  • RTD machine-readable travet documents
  • ICAO International Aviation Authority
  • the ID provider computer system 136 Upon successful completion of the cryptographic protocol, the ID provider computer system 136 authenticates against the ID token, thereby verifying its readability to read the attributes stored in the protected storage area 124.
  • the authentication can also be mutually exclusive, ie the ID token 106 must then also authenticate itself to the ID provider computer system 136 according to the same or another cryptographic protocol.
  • the program instructions 132 are for end-to-end encryption of data transferred between the ID token 106 and an ID provider computer system 136 (see FIG. 2), or at least the ID provider computer system 136 the protected memory area 124 issued attributes.
  • a symmetric key may be used, which is agreed upon, for example, during the execution of the cryptographic protocol between the ID token 106 and the I D provider computer system 136.
  • the ID token 106 has an interface 108 for communication with a corresponding interface 104 of a user computer system 100 (see FIG. 2).
  • the interface may be contactless or contact-based. In particular, it may be an RFID or an NFC communication interface.
  • Access to the protected memory area 124 for reading one or more of the attributes can only take place via the processor 28 of the ID token 106, since the protected memory area 124 as well as the other protected memory areas 120, 122 are not directly, for example via a bus system are connected to the interface 108, but only with the processor 128, that is, an access via the interface 108 directly to the protected memory area 124 is already excluded circuit technology. Only the processor 128 can that is read access to the protected memory area 124, then optionally output the read attributes via the interface 108.
  • FIG. 2 shows a user computer system 100 of the user 102.
  • the user computer system 100 may be a personal computer (PC), a portable computer, such as a laptop, notebook or tablet computer, a mobile telecommunications device , especially a smartphone.
  • PC personal computer
  • portable computer such as a laptop, notebook or tablet computer
  • mobile telecommunications device especially a smartphone.
  • the user computer system has at least one processor 10 for executing an application program 112.
  • the application program 112 is configured to communicate via a network interface 114 of the user computer system 100 via a network 16.
  • the application program is an Internet browser or other specialized application program that can communicate over the network 116, in particular an HTML-capable application program.
  • the processor 110 is used to execute another program 1 3, which may be, for example, a plug-in for the application program 112, for example a browser plug-in, if the application program 112 is designed as an Internet browser, or a program separate from the application program.
  • another program 1 which may be, for example, a plug-in for the application program 112, for example a browser plug-in, if the application program 112 is designed as an Internet browser, or a program separate from the application program.
  • the network can be a computer network, such as the Internet.
  • the network 116 may also include a mobile radio network.
  • the I D provider computer system 136 has a network interface 138 for communicating over the network 116.
  • the I D provider computer system 136 also has a memory 140 with a protected memory area 141 in which private inferences! 142 of the I-provider computer system 136 is stored, as well as the corresponding certificate 144.
  • this certificate may be, for example, a certificate according to a PKI standard, such as X.509.
  • the I D provider computer system 136 further has at least one processor 145 for executing program instructions 146 and 148. By executing the program instructions 146, the steps of the cryptographic protocol concerning the I D provider computer system 136 are executed.
  • the cryptographic protocol is implemented by executing the program instructions 134 by the processor 128 of the ID token 06 and by executing the program instructions 146 by the processor 145 of the ID provider computer system 36.
  • the program instructions 148 are used to implement the end-to-end encryption on the I D provider computer system 136 side, for example, based on the symmetric key that is present during the execution of the cryptographic protocol between the ID token 106 and the ID provider - Computer system 136 has been agreed.
  • any method known per se for agreeing the symmetric key for end-to-end encryption such as a Diffie-Hellman key exchange, may be used.
  • the I D provider computer system 136 is preferably located in a specially protected environment, in particular in a so-called trust center, so that the I D provider computer system 136 in combination with the necessity of authentication of the user 02 to the ID Token 06 forms the trust anchor for the authenticity of the attributes read from ID token 106.
  • a service computer system 150 may be configured to receive an order or order for a service or product, particularly an online service.
  • the user 102 may open an account online with a bank via the network 116, or may use other financial or banking services.
  • the service computer system 150 may also be embodied as an online store, such that the user 102 may, for example, purchase a mobile phone or the like online.
  • the service computer system 150 may also be configured to provide digital content, such as for downloading music and / or video data.
  • the service computer system 150 has for this purpose a network interface 152 for connection to the network 1 16.
  • the service computer system 150 has at least one processor 154 for executing program instructions 156. By executing the program instructions 156, for example, dynamic HTML pages are generated through which the user 102 can enter his order or his order, as well as transactions.
  • the service computer system 150 must review one or more attributes of the user 102 and / or its ID token 106 based on one or more predetermined criteria. Only if this check is passed will the order or order of the user 102 be accepted and / or executed.
  • the user 102 starts the application program 112 of the user computer system, it being further assumed that this is an Internet browser without restriction of generality.
  • the user 102 enters a URL of the service computer system 150 in the Internet browser, so that then a first session 201 between the Internet browser 1 12 and the service computer system 150 is established via the network 1 16.
  • the user can then request via the first session 201 a service offered by the service computer system 150, such as, for example, ordering a product, requesting data for download or requesting the execution of a financial transaction.
  • the Internet browser 1 2 sends a corresponding transaction request 158 to the service computer system 150, which signals this request.
  • the service computer system thus receives from the Internet browser via the first session a transaction request 58 of the user 02. Due to the receipt of the transaction request 158 via the first session 201, the service computer system 150 generates a request 166.
  • the request 166 includes (i) an attribute specification, the attribute to be read from the ID token for carrying out the transaction. These attributes may be personal information about the user 102 and / or data regarding the ID token 106 itself or a pseudonym of the user 102 available from the ID token 106.
  • the request also includes (ii) the transaction data specifying the transaction, such as a payment amount to be paid for the purchase of the ordered product or the performance of the subscribed service to the service computer system 150 or a third party, and / or others Transaction data specifying the transaction to be performed.
  • the request further includes (iii) an identifier 180 of the request, for example, a GUID required for the so-called binding of the request and a response 174 received thereafter.
  • the service computer system 150 may include a GUID generator.
  • the request also includes (iv) a URL of the I D provider computer system 136 and (v) a URL of the service computer system 150 itself.
  • the request is signed by the service computer system 150, namely by means of a private key of the service provider.
  • the request 166 may be an SA L request or another request of a request-response protocol.
  • the service computer system 150 sends a web page 160 to the user computer system 100 via the first session 201, the web page 160 having an input field 162 for inputting additional information by the user 102 for the transaction, and further Input element 164, which the user 102 can select by clicking, for example, when the web page 160 is rendered by the Internet browser 112, to allow the Wetterieitung the request 166.
  • the request 66 is also transmitted to the internet browser 112 via the first session 201. Due to the reception of the web page 160 and the request 166, the web page 160 is rendered by the internet browser 1 2, so that the user 102 can input the additional information into the input field 162.
  • the additional information is an account connection of the user 102, a credit card number of the user 102 or other supplementary transaction data and / or an authentication information for proving the authorization of the user 102 for carrying out the transaction, for example the user 102 One-time password (OTP) in the input slot 162 enters.
  • OTP One-time password
  • the additional information 168 entered by the user 102 is encrypted with the public key of the service computer system 150 by the user computer system 100 to obtain a corresponding ciphertext.
  • a second session 202 is established between the Internet browser 112 and the I D provider computer system 136 via the network 1 6, using the URL of the ID provider computer system 136, the user computer system 100 with the Request 166 has received.
  • the second session 202 is established with a secure transport layer, for example as an https session.
  • the request 166 and the additional information 168 or only the ciphertext of the additional information 168 obtained with the aid of the public key of the service computer system 150 are forwarded from the user computer system 100 to the ID provider computer system 136.
  • the ID provider computer system 136 Due to the receipt of the request 166 by the ID provider computer system 136, the latter generates a session iD for a still to be established third session 203 by executing its program instructions 170.
  • the request 166 and the additional information 168 are stored in the memory 140 of the (D provider Computer system 136 stored.
  • the iD provider computer system 136 then generates a message 172 that includes the Session ID for the construction of the third session 203 and a logical address. With the aid of the logical address, the response 174 to be generated by the IT provider computer system 136 on the basis of the request 166 can be called up. In particular, the logical address may be formed as a URL.
  • the message 172 is sent via the second session 202 from the iD provider computer system 136 to the internet browser 112.
  • the third session 203 is established between the program 113 of the user computer system 100 and the ID provider computer system 136 via the secure transport layer of the second session 202.
  • program 113 is a browser plug-in of Internet browser 112.
  • program 113 may be another application program. It is also possible to implement the functionalities of the Internet browser 1 2 and those of the program 113 in a program.
  • At least the certificate 144 is then transmitted to the program 113 via the third session 203.
  • the program 113 then checks whether the read rights specified in the certificate 144 are sufficient to allow read access by the ID provider computer system 136 to the attribute (s) to be read according to the attribute specification included in the request 166. Only if these read rights are sufficient, the following steps are performed: a) A local connection 176 is established between the interfaces 104 and 108. For example, on the screen of the user computer system 100, a request for the user 102 to insert the ID token 106 into a reader of the user computer system 100, which has the interface 104, or appears for placing the ID token 106 on a contactless interface 104.
  • the user 102 then authenticates himself to the ID token, for example by entering his PIN in the user computer system 100 or its reader.
  • the authentication of the user can take place with the aid of a cryptographic protocol, for example by means of a challenge-response protocol or based on a Diffie-Helman key exchange, wherein a session key is agreed as part of the authentication of the user.
  • a fourth session 204 is established between the ID token 106 and the ID provider computer system 136 via the local connection 176 and the third session 203.
  • the fourth session 204 ends with one End-to-end encryption using the session key, which has been agreed in the authentication of the user in step b) protected.
  • the fourth session is then used to mutually authenticate the ID token 106 and the I D provider computer system 136 with the aid of the respective private key, that is to say the private key of the ID token 106 stored in the protected memory area 122 and the private key 142 of the ID provider computer system 136.
  • the certificates of the ID token 106 can be exchanged from the memory area 126 (see FIG. 1) as well as the certificate 144 of the ID provider computer system 136 over the fourth session.
  • the ID provider computer system 36 Given the successful authentication of the user to the ID token and successful mutual authentication of the ID token 106 and the ID provider computer system 136, the ID provider computer system 36 then reads the attribute (s) from the ID according to the attribute specification - Token 106, wherein the attributes are protected by the end-to-end encryption in the transmission of the ID token 106 to the I D provider computer system 136. For this purpose, the ID provider computer system sends a read command via the fourth session 204 to the ID token 106 via the fourth session.
  • the read command 182 contains the attribute specification, that is to say the selection of those attributes which are from the protected memory area 124 of the ID token 06 should be read.
  • the ID provider computer system 136 By executing the program instructions 178, the ID provider computer system 136 then generates the response 174, for example a SAML response, on the request 166.
  • the response 178 includes the attributes previously read out of the ID token 06 via the fourth session 240, the additional information 168 or, depending on the embodiment, not the additional information 168, but only the ciphertext of the additional information 168, and the identifier 180 indicating the service Computer system 50 has initially assigned to the request 66.
  • the response 174 is signed by the ID provider computer system 136 using the private key 142 and then stored in the memory 140 so that the request 166 is retrievable from the logical address.
  • the user computer system 100 such as, for example, its Internet browser 112, then reads the response 174 from the memory 140, for example via the second session 202, with the aid of the logical address.
  • the response 174 is then forwarded from the user computer system 100, for example from the Internet browser 112, via the first session 201 to the service computer system 150.
  • the content of the response 174 is displayed in whole or in part by the Internet browser, in particular the information read from the ID token. tribute and / or additional information 168 to allow the user 102 to verify the accuracy of this data before passing it on to the service computer system 150 to complete the transaction.
  • the service computer system 50 associates the received response 174 with the request 66 based on the matching identifiers 180 of the request 166 and the response 174.
  • the service computer system 150 then checks the signature of the response 166 and reads out the required attribute (s) from the response 174.
  • the attributes are then used to check whether the requested transaction can be performed by comparing the attribute (s) to one or more predetermined criteria. These criteria may be, for example, the age or credit of user 102.
  • the attribute may also be a pseudonym of the user 102, by means of which the service computer system 150 then reads out an attribute of the user 102 stored in a database of the service computer system 150, such as a delivery address.
  • the test criterion here is whether a user is registered with the pseudonym included in the response 174 on the part of the service computer system 150.
  • the transaction is performed based on the transaction data and the additional information 168.
  • the program 1 13 is a browser plug-in which is registered in a registry of an operating system of the user computer system with a plug-in identifier, wherein the operating system is, for example, a Windows operating system, Android or iOS can act.
  • the message 172 from the ID provider computer system to the Internet browser 1 12 includes this plug-in identifier 184, so that the plug-in 3 is started due to the receipt of the message.
  • the program 1 13 is a separate from the Internet browser 1 12 application program, such as a so-called citizen app or ID card app.
  • This application program 1 13 is started by the Internet browser 1 12 by calling a local URL, the local URL includes a fixed port number according to the TCP protocol.
  • This local URL along with the web page 160, is transmitted from the service computer system 150 to the user computer system 100 via the first session 201 to allow the application program 1 13 to be launched by the internet browser 12 using the local URL cause.
  • the response 74 contains only this cipher, not but the additional information 168 itself.
  • the service computer system 150 decrypts the ciphertext using the private key of the service computer system 150 to then perform the requested transaction using the additional information 168. This may be, for example, the execution of a financial transaction, such as the execution of a transfer in the amount of the payment amount, which is specified in the additional information 168.
  • the implementation of the payment by the ID provider computer system 36 is triggered. This can be done so that the ID provider computer system 136 receives the requisite transaction data about the request 166 and the additional information 168 and then performs or causes the payment.
  • the response 174 then includes confirmation from the ID provider computer system 136 that the payment has been made.
  • submission of the additional information 168 to the service computer system 150 can then be omitted, which is advantageous for protecting the confidentiality of this additional information 168, since this additional information 168 then only has to be disclosed to the trusted ID provider computer system 136.
  • the actual transaction eg the delivery of the ordered product, becomes then upon receipt of the payment confirmation included in the response 174, prompted by the service computer system 150.
  • the additional information 168 includes an OTP.
  • the service computer system 150 checks whether the OTP is valid as an additional prerequisite for the transaction to be performed.
  • the OTP is encrypted by the user's computer system 100 with the public key of the service computer system 150 and then decrypted by the service computer system 150 upon receipt of the additional information with the encrypted OTP, to then check its validity.
  • the computer system includes a terminal 186, which may be, for example, a vending machine, in particular a cash machine or vending machine.
  • a terminal 186 which may be, for example, a vending machine, in particular a cash machine or vending machine.
  • the user 102 may enter into the terminal 186 a sum of money to withdraw cash from his account.
  • An optically detectable pattern is then displayed on a display 188 of the machine, such as a QR code that includes a URL of the service computer system 150 and the amount of money desired by the user 102.
  • This optical pattern is detected by the display 188 by means of a camera 190 of the user computer system 100.
  • the user computer system 100 then generates the transaction request 158 indicating this amount of money.
  • the first session 201 is constructed here using the URL of the service computer system 150 detected from the optical pattern, and the transaction request 158 with the desired amount of money is transmitted to the service computer system 150 via this first session 201.
  • the service computer system 150 then generates a corresponding request 166 to retrieve the attributes and additional information 168 required for the payment of the desired amount of money.
  • the load of an account of the user 102 is then caused by the ID provider computer system 136 or by the service computer system 150. Due to the receipt of the response 174 and the cause of the Payment then receives the terminal 186 a signal to issue the desired amount of money, for example in the form of cash or to charge a cash card of the user 102. This can be done so that the terminal 186 is directly connected to the service computer system 150 or via the network 116.
  • the terminal 86 may also be a vending machine, whereupon no cash but a desired product, such as a beverage can or cigarette pack, is dispensed from the vending machine after the payment is signaled by the service computer system 150 has been.
  • a desired product such as a beverage can or cigarette pack
  • the terminal 186 may be a mobile telecommunications device, in particular a smartphone. If the user 102 wants to buy something from the owner of the terminal 186, the holder of the terminal 186 enters the corresponding purchase price in the terminal 186, so that then on the display 188 in the form of the optically detectable pattern turn this purchase price as a payment amount and the URL of the service computer system 150 is output. Upon completion of the transaction, the terminal 186 receives from the service computer system 150 a signal indicating that the payment has been made and the owner of the terminal 186 then delivers the product to the user 102. This can also be implemented in the POS system of, for example, a supermarket.
  • a taximeter which covers taxi fees or another consumption meter, such as a consumption meter for the electricity or gas consumption of a household, especially a so-called smart meter.

Abstract

L'invention concerne un procédé de transaction électronique à l'aide d'un jeton d'identification (106) qui est associé à un utilisateur (102). Le jeton d'identification comporte une mémoire électronique (118) avec un secteur de mémoire protégé (124) dans lequel sont enregistrés un ou plusieurs attributs, un accès au secteur protégé de la mémoire étant possible uniquement par l'intermédiaire d'un processeur (128) du jeton d'identification, et le jeton d'identification comporte une interface de communication (108) en vue de la communication avec un appareil de lecture d'un système informatique d'un utilisateur (100). Ledit procédé comprend les étapes suivantes : - l'établissement d'une première session (201) entre un programme d'application (112), en particulier un navigateur Internet du système informatique de l'utilisateur, et un système informatique de service (150) par l'intermédiaire d'un réseau (116) ; - la réception d'une demande de transaction (158) au cours de la première session par le système informatique de service en provenance du programme d'application (112) ; - la génération d'une requête (166) par le système informatique de service en raison de la réception de la demande de transaction, la requête étant signée par le système informatique de service et la demande contenant une spécification d'attributs, des attributs à lire dans le jeton d'identification pour l'exécution de la transaction, des données de transaction pour la spécification de la transaction, un code (180) de la demande, une adresse URL d'un système informatique de fournisseur d'identification et une adresse URL du système informatique de service ; - la transmission d'une page Web (160) et de la demande au cours de la première session par le système informatique de service au système informatique de l'utilisateur, la page Web comportant un champ de saisie (162) pour la saisie d'une information supplémentaire (168) en vue de l'exécution de la transaction ; - l'affichage de la page Web par le programme d'application et saisie de l'information supplémentaire par l'utilisateur dans le champ de saisie ; - l'établissement d'une deuxième session (202) entre le programme d'application (112) et le système informatique du fournisseur d'identification par l'intermédiaire du réseau à l'aide de l'adresse URL du système informatique de fournisseur d'identification, la deuxième session étant établie avec une couche de transport sécurisée ; - le transfert de la requête et de l'information supplémentaire par le programme d'application au système informatique du fournisseur d'identification au cours de la deuxième session ; - en raison de la réception de la requête, la génération d'une identification de session pour une troisième session (203) par le système informatique du fournisseur d'identification et l'enregistrement de la requête ainsi que de l'information supplémentaire par le système informatique du fournisseur d'identification ; - l'envoi d'un message par le système informatique du fournisseur d'identification au programme d'application (112) avec l'identification de la troisième session et avec une adresse logique, en particulier une adresse URL, au cours de la deuxième session ; - l'établissement de la troisième session entre un programme (113) du système informatique de l'utilisateur et le système informatique du fournisseur d'identification par l'intermédiaire de la couche de transport sécurisée de la deuxième session, le programme pouvant être différent du programme d'application (112) ; - la transmission au programme (113) d'au moins un certificat (144) du système informatique du fournisseur d'identification, le certificat contenant une indication des droits de lecture du système informatique du fournisseur d'identification pour la lecture d'un ou de plusieurs attributs enregistrés dans le jeton d'identification et la transmission du certificat étant effectuée au cours de la troisième session ; - la vérification par le programme (113) si les droits de lecture indiqués dans le certificat sont suffisants pour autoriser un accès en lecture du système informatique du fournisseur d'identification à l'attribut ou aux attributs à lire selon la spécification d'attribut ; - la génération d'une réponse (174) qui contient le ou les attributs lus et au moins le code (180) de la requête et qui est signée par le système informatique du fournisseur d'identification ; - l'enregistrement de la réponse pour l'appel à l'aide de l'adresse logique ; - la lecture de la réponse du système informatique du fournisseur d'identification par le système informatique de l'utilisateur par l'appel de la réponse au moyen d'une instruction de lecture de l'adresse logique par le biais du réseau ; - le transfert de la réponse par le système informatique de l'utilisateur au cours de la première session au système informatique de service ; - l'association de la réponse à la requête à l'aide du code, qui est contenu dans la réponse, par l'intermédiaire du système informatique de service ; - l'exécution de la transaction à l'aide de la réponse par le système informatique du fournisseur d'identification.
EP14725701.8A 2013-06-28 2014-05-22 Procédé de transaction électronique et système informatique Pending EP3014539A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102013212627.1A DE102013212627B4 (de) 2013-06-28 2013-06-28 Elektronisches Transaktionsverfahren und Computersystem
PCT/EP2014/060576 WO2014206660A1 (fr) 2013-06-28 2014-05-22 Procédé de transaction électronique et système informatique

Publications (1)

Publication Number Publication Date
EP3014539A1 true EP3014539A1 (fr) 2016-05-04

Family

ID=50771497

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14725701.8A Pending EP3014539A1 (fr) 2013-06-28 2014-05-22 Procédé de transaction électronique et système informatique

Country Status (3)

Country Link
EP (1) EP3014539A1 (fr)
DE (1) DE102013212627B4 (fr)
WO (1) WO2014206660A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111212062A (zh) * 2019-12-31 2020-05-29 航天信息股份有限公司 信息补全的方法、装置、存储介质及电子设备

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016200003A1 (de) * 2016-01-04 2017-07-06 Bundesdruckerei Gmbh Zugriffskontrolle mittels Authentisierungsserver
EP3232399A1 (fr) * 2016-04-12 2017-10-18 Visa Europe Limited Système permettant d'effectuer un contrôle de validité d'un dispositif utilisateur
CN110458660A (zh) * 2018-08-30 2019-11-15 腾讯科技（深圳）有限公司 虚拟宠物商品的交易方法、装置、系统及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008000067A1 (de) * 2008-01-16 2009-07-23 Bundesdruckerei Gmbh Verfahren zum Lesen von Attributen aus einem ID-Token
DE102011082101A1 (de) * 2011-09-02 2013-03-07 Bundesdruckerei Gmbh Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem
US20130085941A1 (en) * 2008-09-30 2013-04-04 Apple Inc. Systems and methods for secure wireless financial transactions

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1416551A (zh) * 2000-03-09 2003-05-07 北川淑子 带光学数据读取器的信息处理设备、各种服务器及电子商业交易方法
KR20050042694A (ko) * 2003-11-04 2005-05-10 한국전자통신연구원 보안토큰을 이용한 전자거래방법 및 그 시스템
DE102011089580B3 (de) * 2011-12-22 2013-04-25 AGETO Innovation GmbH Verfahren zum Lesen von Attributen aus einem ID-Token

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008000067A1 (de) * 2008-01-16 2009-07-23 Bundesdruckerei Gmbh Verfahren zum Lesen von Attributen aus einem ID-Token
US20130085941A1 (en) * 2008-09-30 2013-04-04 Apple Inc. Systems and methods for secure wireless financial transactions
DE102011082101A1 (de) * 2011-09-02 2013-03-07 Bundesdruckerei Gmbh Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO2014206660A1 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111212062A (zh) * 2019-12-31 2020-05-29 航天信息股份有限公司 信息补全的方法、装置、存储介质及电子设备

Also Published As

Publication number Publication date
WO2014206660A1 (fr) 2014-12-31
DE102013212627B4 (de) 2021-05-27
DE102013212627A1 (de) 2014-12-31

Similar Documents

Publication Publication Date Title
DE102011082101B4 (de) Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem
EP3089061B1 (fr) Methode de lecture des attributs d'un token id
EP2304642B1 (fr) Procédé pour lire les attributs depuis un jeton id
EP2454703B1 (fr) Procédé de lecture d'attributs contenus dans un jeton d'identification
DE102012219618B4 (de) Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem
EP2949094B1 (fr) Procédé d'authentification d'un usager vis-à-vis d'un distributeur automatique
EP2454705B1 (fr) Procédé pour lire les attributs d'un jeton d' identification et générateur de mot clefs a usage unique
EP2817758B1 (fr) Procédé de paiement informatisé
DE102013212627B4 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013212646B4 (de) Elektronisches Transaktionsverfahren und Computersystem
EP2879073B1 (fr) Procédé de transaction électronique et système informatique
EP2752785B1 (fr) Procédé de personnalisation d'un élément sécurisé (Secure Element SE) et système informatique
EP2916252B1 (fr) Procédé de transaction électronique et système informatique
DE102013022434B3 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013022433B3 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013022436B3 (de) Elektronisches Transaktionsverfahren und Computersystem
EP2819079B1 (fr) Procédé de transaction électronique et système informatique
DE102013022435B3 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013022438B3 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013022448B3 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013022447B3 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013022445B3 (de) Elektronisches Transaktionsverfahren und Computersystem

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20160128

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20171108

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

APBK Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNE

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230526