[go: up one dir, main page]

EP2936406A1 - Procédé et système pour la communication basée sur des appareils terminaux entre des applications tierces et un portefeuille électronique - Google Patents

Procédé et système pour la communication basée sur des appareils terminaux entre des applications tierces et un portefeuille électronique

Info

Publication number
EP2936406A1
EP2936406A1 EP13821459.8A EP13821459A EP2936406A1 EP 2936406 A1 EP2936406 A1 EP 2936406A1 EP 13821459 A EP13821459 A EP 13821459A EP 2936406 A1 EP2936406 A1 EP 2936406A1
Authority
EP
European Patent Office
Prior art keywords
wallet
data
internet service
terminal
electronic wallet
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.)
Ceased
Application number
EP13821459.8A
Other languages
German (de)
English (en)
Inventor
Zhiyun Ren
Jörg Heuer
Klaus-Peter Hofman
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.)
Deutsche Telekom AG
Original Assignee
Deutsche Telekom AG
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 Deutsche Telekom AG filed Critical Deutsche Telekom AG
Priority to EP13821459.8A priority Critical patent/EP2936406A1/fr
Publication of EP2936406A1 publication Critical patent/EP2936406A1/fr
Ceased 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/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/326—Payment applications installed on the mobile devices
    • G06Q20/3267—In-app payments
    • 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
    • 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/085—Payment architectures involving remote charge determination or related payment 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/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/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3226—Use of secure elements separate from 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3229—Use of the SIM of a M-device as secure element
    • 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/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • 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/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
    • G06Q20/3674—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 involving authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/60—Subscription-based services using application servers or record carriers, e.g. SIM application toolkits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication

Definitions

  • the invention relates to a method and a system for terminal-based communication between foreign applications and an electronic wallet, wherein in particular data for the use of Internet services are managed via the electronic wallet.
  • API Programming Interface Application Programming Interface
  • An electronic wallet (hereinafter also referred to simply as a “wallet”) is a hardware and software module within a terminal, usually a mobile terminal such as a mobile phone or smartphone, which consists of two parts:
  • a “Secure Element”, hereinafter also referred to as “security element” eg in the form of a SIM card / UICC or a Javacard integrated in the chipset of the terminal, with Java applets thereon, on the one hand by applications can be addressed on the terminal and via wireless radio communication (for example NFC) of acceptance points (ie card readers) in card emulation mode.
  • security element eg in the form of a SIM card / UICC or a Javacard integrated in the chipset of the terminal
  • Java applets thereon on the terminal and via wireless radio communication (for example NFC) of acceptance points (ie card readers) in card emulation mode.
  • this architecture of the electronic wallet allows the mapping of real smart cards (for various applications such as payments, customer card, coupons) to the terminal, whereby the role of the chip of the real card is taken over by the Java applets on the security element, for example the UICC and the role of the imprint (ie, caption, design, logo, and / or other markings) on the physical card through the wallet software on the terminal, such as the mobile phone.
  • the role of the chip of the real card is taken over by the Java applets on the security element, for example the UICC and the role of the imprint (ie, caption, design, logo, and / or other markings) on the physical card through the wallet software on the terminal, such as the mobile phone.
  • Applet is here and below understood to mean an application which is configured for execution on a security element Instead of “applet”, the synonymous designation “cardlet” is also used in the following configured to run under the operating system of the terminal, referred to as "App”.
  • the electronic wallet is located on a mobile terminal, such as a mobile phone, then the electronic wallet should also be referred to as a "mobile wallet”.
  • the cards in the electronic wallet can then be used at appropriate acceptance points such as physical plastic cards, wireless wireless communication (for example, the NFC), applets on the security element (such as the UICC), for example, be addressed contactless at the cashier in the supermarket.
  • appropriate acceptance points such as physical plastic cards, wireless wireless communication (for example, the NFC), applets on the security element (such as the UICC), for example, be addressed contactless at the cashier in the supermarket.
  • this technique allows the use of a security element (such as the UICC) as a multi-functional smart card, allowing the user to enjoy the appropriate Security levels of a smart card application comes: Data can not be read from the smart card, the smart card can not be copied and releases your data if necessary after entering a PIN for use.
  • a security element such as the UICC
  • Similar procedures have been established for similar operations in the online world. For example, pay operations are performed by users on web pages reading information from their credit card and typing into web forms. The authentication of users to web pages is usually done by entering user ID and password.
  • platform On mobile platforms (here and below the term “platform” is understood to mean the operating system of a terminal, “mobile platform” is understood to mean the operating system of a mobile terminal), in turn, it is customary to pay for apps and other digital goods on the mobile Terminal, his payment card data once with an account of the mobile phone manufacturer to connect, so that the acquisition of such goods in the future, for example can be settled on a credit card.
  • apps and other digital goods on the mobile Terminal, his payment card data once with an account of the mobile phone manufacturer to connect, so that the acquisition of such goods in the future, for example can be settled on a credit card.
  • online services such as server-based storage of photos
  • US 2009/0234751 A1 discloses an electronic wallet for a wireless mobile device and a method of using the electronic wallet.
  • the electronic wallet includes: an invoker that responds to an external trigger external of the wallet; a user authentication device for authenticating the user of the electronic wallet when the wallet is called by the external trigger; and means for retrieving map information stored in the wallet in response to a form specified by the external trigger calling the wallet.
  • the external trigger may be a website visited via an Internet browser on the draleless mobile device, with a wallet trigger instruction embedded in the website.
  • the wallet trigger statement may be a supplement embedded in the header of the website visited via the internet browser.
  • the site may also contain field ID tags containing specific data fields in the wallet to form input fields provided by the website.
  • WO 2006/085805 A1 relates to a method for performing electronic transactions in a network, comprising: a mobile subscriber terminal with a digital wallet and a browser, a server for the management of the transactions and a content provider.
  • the subscriber selects a service and sends an application form to a content provider.
  • the content provider sends a transaction request form to the mobile subscriber.
  • the subscriber confirms the transaction and sends the transaction request form to the browser.
  • the browser reads the data required for the transaction form from the digital wallet and populates the application form with the transaction data read.
  • the complete form is then sent to the server, which converts the full form into a standard transaction format.
  • the content provider processes the complete application form and sends it to the content provider who answers the subscriber.
  • US 2012/01223868 A1 describes a system for dynamically adapting the wireless data emulation used by a portable communication device based on its geolocation.
  • the system determines a geolocation of the portable communication device by transmitting the current geolocation data to the server using the most appropriate channel; Receiving data from payment systems that might be in the vicinity of the portable communication device; and develop a payment system in the portable communication device with the data formats and other wireless point-of-sale data that are typical of payment systems that might be in the vicinity of the device.
  • US 2012/0166337 Al shows a near field communication (NFC) terminal for performing secure payment comprising an NFC unit and a control unit.
  • the NFC unit communicates with an external payment terminal, and the payment unit, using the NFC unit, transfers results acquired by the processing of transaction information and an electronic signature value of the transaction information to the payment terminal.
  • the payment terminal calls an external payment server to make the payment.
  • An authentication confirmation applet in the payment unit generates the electronic signature of the transaction information.
  • An electronic wallet applet included in the payment unit transmits the result obtained by the processing of the transaction information and the electronic signature value to the payment terminal.
  • US 2012/0 130 839 AI describes techniques for managing modules or applications installed in the mobile device.
  • each of the installed applications is provided with a server by the data transfer potential in a mobile device.
  • a provided application is associated with the personalized security element of the mobile device and works with a set of keys generated in accordance with a key set of the personalized security element. Furthermore, the control management of an installed application is described.
  • WO 2012/021 864 A2 shows a telephone-based electronic wallet that offers authenticated transactions over multiple trade routes.
  • the electronic wallet may be used for point-of-sale payments, remote mobile payments, and / or web-based payments, and may use authentication means such as offline PINs, SecureCode PINs, and / or online PINs.
  • the classic electronic wallet works only in the vicinity of an acceptance point by means of wireless radio communication (eg NFC radio technology).
  • wireless radio communication eg NFC radio technology
  • more and more people are using their mobile device to conduct transactions on the Internet. For example: (i) online payment of digital goods (eg MP3 download),
  • One aspect of the invention relates to a method for terminal based communication between a third party application and an electronic wallet.
  • the electronic wallet is installed on a terminal, and the third-party application is installed on the terminal.
  • the method comprises the following steps:
  • connection requires transmission of data to the Internet service; (b) receiving by the foreign application a request of the Internet service directed to the transmission of said data;
  • step (c) forwarding the request received by the Internet service in step (b) to the electronic wallet by the foreign application;
  • step (f) receiving an acknowledgment of the forwarding of the response to the Internet service according to step (e), wherein the receiving is done by the foreign application.
  • a security element is connected to the terminal; and step (d) of processing the request and generating a response comprises the steps of:
  • Radio communication for example, radio-based short-range communication (NFC) is configured.
  • NFC radio-based short-range communication
  • the security element is a universal integrated circuit card (UICC) or a SIM card.
  • UICC universal integrated circuit card
  • step (d) of processing the request and generating a response comprises the steps of:
  • the terminal is suitable for mobile radio communication; the terminal may be, for example, a mobile device or a smartphone and / or be suitable for WLAN communication. In which Terminal may also be, for example, a laptop / notebook or a tablet computer.
  • the data has confidential and / or user-specific information.
  • the data may include authentication information.
  • the data may include information for a login or for a payment transaction.
  • the data may also include personal information.
  • step (e) of forwarding the data comprises the following steps:
  • step (e) of forwarding the data comprises the following steps:
  • the foreign application is a service provider application installed on the terminal that is configured to use the Internet service.
  • the foreign application is an Internet browser installed on the terminal.
  • One aspect of the invention relates to a system for terminal-based communication between one or more foreign applications and an electronic wallet.
  • the system has a terminal.
  • the system is characterized in that an electronic wallet is installed on the terminal and one or more third-party application (s) are installed on the terminal.
  • the third-party application (s) are each configured to: establish a connection to an Internet service, the connection requiring transmission of data to the Internet service; for receiving a request for transmission of the data of the Internet service; and for forwarding the request received from the Internet service to the electronic wallet.
  • the electronic wallet is configured to: process the said request and generate a corresponding response; to forward the answer to the internet service.
  • the foreign application (s) are each configured to: receive an acknowledgment of a forwarding to the Internet service, the receiving being done by the foreign application.
  • the answer that is generated in accordance with the request for the transmission of said data all the requested data, a part of the requested data or none of the requested data (the latter corresponds to a denial of data transmission), the response in encrypted and / or unencrypted form.
  • the terminal is configured to receive one or more security elements, with one or more programming interfaces (APIs) installed on the terminal for listing, selecting, and interacting with the security elements.
  • the system further includes one or more security elements (e) incorporated in the terminal, the terminal being connected to the one or more security elements.
  • the electronic wallet is configured to process the said request and generate a corresponding response: to send requests for said data to the one or more security elements (e); for receiving replies to said data from or from the security element (s).
  • the security element is preferably configured for wireless radio communication, for example radio-based short-range communication (NFC).
  • NFC radio-based short-range communication
  • the security element is a Universal Integrated Circuit Card (UICC) or a SIM card.
  • the electronic wallet is further configured to process said request and generate a corresponding response: to send a request for said data to an app, for example, another foreign application; and for receiving a response regarding said data from the app.
  • the terminal is suitable for mobile radio communication; the terminal may be, for example, a mobile device or a smartphone, and / or be suitable for WLAN communication.
  • the terminal may also be, for example, a laptop / notebook or a tablet computer.
  • the data comprises confidential and / or user-specific information.
  • the data may have information for authentication.
  • the data may include information for a login or for a payment transaction.
  • the data may also include personal information.
  • the electronic wallet is configured to forward the response to the Internet service: to transmit the data to a wallet backend. It also configures the wallet backend: to connect the wallet backend to the internet service; and for transmitting the data to the Internet service.
  • the electronic wallet is configured to forward the response to the Internet service: transmitting the data to the foreign application (s). Furthermore, the foreign application (s) are each configured to transmit the data to the Internet service.
  • the third-party application is a service provider application installed on the terminal that is configured to use the Internet service. In one embodiment of the system, the third-party application is an Internet browser installed on the terminal.
  • the present invention shows how the electronic wallet can be extended by means of on-device APIs in such a way as to enable the execution of transactions on the Internet, and thus in particular also the scenarios described above under points (i) to (iv) the electronic wallet can be supported (see Fig. 1).
  • the electronic wallet is already designed for short-range use via wireless radio communication (such as NFC) as a secure application on the terminal.
  • This infrastructure can be reused for the storage of all security or privacy relevant personal data.
  • the smart card function of the security element for example the UICC
  • the security element for example the UICC
  • FIG 1 Use of wallet functions by third-party applications (third-party apps);
  • FIG. 1 Process of using on-device APIs
  • FIG. 3 an overview of the system according to the invention
  • FIG. 4 an (NFC) ecosystem with on-device API
  • FIG. 5 user operation 1: the user selects vouchers in the app of a third party and pays by means of a wallet;
  • FIG. 6 user operation 2: the user selects vouchers in the app of a third party by means of a wallet;
  • FIG. 7 a view of the components of the on-device API
  • FIG. 8 Shows dependencies between the wallet and an app of a third party
  • FIG. 9 a flow diagram of the anonym profile
  • FIG. 10 a flow chart of the minimum protection profile
  • Figure 11 A flow chart of the protection profile with high protection.
  • the user has a mobile phone or other device that can hold one or more security features.
  • APIs exist on the terminal to list, select and address security elements with APDU commands.
  • the platform allows the integration of separately installed apps via appropriate platform-specific mechanisms - the so-called “on-device APIs” or “wallet APIs”.
  • the inventive method is based on creating programming interfaces between any third-party applications (third-party apps) on the terminal and the wallet on the terminal in order to create a use of the functions of the electronic wallet by these third-party applications.
  • the third-party application on the terminal connects to a service on the Internet (Internet service), which requires authentication for login or payment or the transmission of personal data (step 1).
  • the third-party application receives data for transmission to the wallet from the Internet service (step 2).
  • the wallet may use authentication services of the security element, eg. the UICC (steps 4 and 5).
  • the wallet forwards the authentication information to a wallet backend (step 6A).
  • the Wallet Backend contacts the service on the Internet for forwarding the authentication information edited by the Wallet (step 7A)
  • the wallet forwards the authentication information to the foreign application (step 6B).
  • the foreign application forwards the authentication information to the service on the Internet (step 7B).
  • the foreign application learns of the successful authentication of the Internet service (step 8).
  • the on-device APIs are used here in particular in steps 3 and 6B. Some of these steps are optional depending on the specific application scenario.
  • the integration of the safety function is optional.
  • the invention also makes it possible to use wallet services with rich functionality on such limited platforms.
  • the wallet can bundle payment functions and, in this case, "routing" from a third-party application that requires a payment to an app-implemented payment instrument in the wallet (eg a special credit card and not the existing EC card) Using security features of a security element, this payment app can use other mechanisms to secure the transaction.
  • the wallet backend used in variant A in the above example is located on a server of the wallet operator and is in turn addressed by the terminal via an Internet connection.
  • the background is to inform the Internet service about the correct execution of the payment via a merchant interface if the communication flow is to be used via steps 6A and 7A.
  • Wallet APIs can be implemented according to this scheme and connected to the wallet in step 3.
  • Interprocess communication mechanisms of the platform are used (for example, intents on Android platforms):
  • In-app purchase The third-party application initiates a payment process for the delivery of digital goods from a server on the Internet. Information about the type of goods as well as the price is passed on to the wallet.
  • In-app authentication The third-party application initiates a login to a server on the Internet (eg to access cloud data). The wallet will be given information about the type of login.
  • Personal data configuration for social network The social network app logs on to a social network on the Internet and forwards the request for personal information to the wallet. The wallet returns after consultation with the user, the personal data.
  • data is delivered digitally signed, with an applet on the security element, such as a
  • UICC e.g., age verification
  • on-device APIs Many more on-device APIs are possible.
  • the scenarios of "in-app purchase” and “in-app authentication” can be easily extended to a web browser (for example, the mobile web browser on a smartphone) instead of the third-party application.
  • This uses the URL mechanism of the platform for the on-device API, i.
  • the Internet service can address the Wallet app directly via certain web wallet URLs using the web browser.
  • further examples relating to the on-device API according to the invention are given in connection with voucher handling and loyalty scenarios. While the API is not limited to a particular class, any additional scenario can be supported. Definition and area of loyalty / voucher handling
  • Loyalty refers to a point-based bonus program targeting one or more merchants.
  • the user gets a certain amount of points, which are calculated based on a logic that defines the provider of the loyalty model. Therefore, each time the user makes a purchase, he forwards his customer loyalty identification number via the NFC / QR to the POS system, which calculates the bonus points and adds them to the user's account balance.
  • This loyalty style is POS-IT backend-focused, i. the wallet is responsible only for storing and forwarding the user's loyalty code. The loyalty bonus processing and administration is done via the POS system and the IT of the loyalty provider.
  • Vouchers allow certain groups of users to receive discounts or other benefits when making a purchase. Vouchers can be a discount (relative or absolute) to the entire cart or to dedicated products. Certain vouchers may also have conditions that must be met by the user to redeem the particular voucher (eg, pay for one, get two). The settlement of coupons is handled by the POS system. The motivation of the issuer of the voucher is to direct the behavior of the user by creating an incentive for certain products or buying patterns. Vouchers are generally meant to be used only once. Therefore, every used coupon must be validated. User Journeys
  • the current range of the electronic wallet (e.g., mWallet) on-device API allows the user to follow two user journeys.
  • the focus of the journey is on the voucher settlement scenario, but it can be applied to loyalty and other cards in the same way.
  • a journey is described wherein the user selects coupons in the third-party app and pays with the wallet:
  • Step One The user can pre-select wallet vouchers in the third party app and click on the "Pay with Wallet” button to proceed to further payment with the wallet (Figure 5a).
  • Step two The wallet appears and must be opened by the user with the wallet PIN. After successful authentication, the coupon dialog is shown ( Figure 5b).
  • Step three The user is free to choose additional vouchers or payment cards before starting the payment process. Vouchers can be selected from various third-party apps (Figure 5c). Step four: When the user has completed the card selection, payment can be started by clicking on the "Send" button ( Figure 5d). Step Five: An overview of all selected cards I is displayed while the user is prompted to connect the mobile phone to the NFC terminal. Alternatively, the user may be prompted to scan a set of QR codes at the POS ( Figure 5e). Referring now to Figure 6, an alternative journey is described in which the user selects third party coupons with the wallet:
  • Step one From the coupon selection view of the wallet, the user can start a registered third party app for coupon selection (Figure 6a).
  • Step two Vouchers can be selected in the Third Party application. Clicking the "Pay with Wallet” button will take the user back to the wallet and see an updated view of all selected coupons (Figure 6b).
  • Step three The user is free to select additional vouchers by selecting from their own wallet or third-party vouchers. The list of third party coupons may be filtered according to some criteria defined by the third party's application ( Figure 6c).
  • Step four When the user has completed the card selection, payment can be started by clicking the "Send" button ( Figure 6d).
  • Step Five An overview of all the selected cards I is displayed while the user is prompted to connect the mobile terminal to the NFC terminal. Alternatively, the user may be prompted to scan a set of QR codes at the POS ( Figure 6e).
  • Use Case 1 (Register Item Provider): The entry point for third-party apps as an item provider for using the on-device API is an introductory login Call. The item provider login notifies the wallet of the existence of the IP app on the mobile device and enables on-device features supported by the item provider. Preferably, use case 1 is mandatory.
  • Use Case 2 After booting the electronics, the wallet (e.g., mWallet) asks all registered item providers for available items. It is up to the IP to decide which items to return to the electronic wallet (e.g., mWallet). Depending on the application, these may be items preselected by the user, items of interest or all available items. Items of all providers are displayed to the user in a list view for the item usage and selection for an additional detail view. The wallet does not presume to store these items and only keeps temporary references to the items that are in the item provider application. Preferably, use case 2 is mandatory.
  • Use Case 3 Depending on the item usage scenario (payment, access key), the user can either select one or more items from different domains for a transaction.
  • the transport channel (NFC, QR, HTTP) prescribes whether the user must sequentially specify the data of the item of the interacting party or whether all item data can be transmitted in a user interaction.
  • the user when using the wallet, the user should be able to select one or more items before starting the transaction. For example, at an NFC point of sale, tokens for the selected items are requested from the item provider or a corresponding cardlet is activated. If the use of a specific is token-based, the item provider must return the requested token to the electronic wallet (eg mWallet).
  • use case 3 is mandatory.
  • Use Case 4 (Use item from Item Provider): The Item Provider can open the electronic wallet (eg mWallet) to use an item through specific capabilities of the electronic wallet (eg mWallet), such as NFC, QR code or HTTP.
  • Use Case 5 In the case of an NFC transaction, the wallet knows the final transaction status and will report the item usage to the item provider. Depending on the contract between the NFC interaction point and the item provider, additional item-specific data may be forwarded to the item provider. For example, redeemed vouchers can be validated and removed from the mobile wallet, or earned loyalty points can be added to the user's loyalty account. Preferably, use case 5 is mandatory.
  • Use Case 6 Items displayed in the Wallet can be removed or deleted by the user. The responsible item provider is notified about this action and should remove the item from the item list provided to the wallet. It is up to the provider to perform additional actions, such as physical deletion from local storage or in the backend of the provider. Preferably, the use case 5 is optional.
  • Use Case 7 Item that is issued, for example, at a point of sale and retrieved from the mWallet via an NFC or scanning a QR code is imported by the electronic wallet (eg mWallet) passed on to the appropriate item provider application.
  • Use Case 8 (Define Default Item): Items can be marked as default items in the electronic wallet (e.g., mWallet). The default item (one per domain) is used as default without explicit selection. The item provider is notified if an item is set as default or if its setting is canceled. It is up to the IP to perform any actions, such as enabling or disabling a corresponding cardlet.
  • Use Case 9 (Item Call):
  • the electronic wallet eg mWallet
  • the electronic wallet can request dynamic item data from the item provider that will be used to get item details display. For example, this may be the actual number of loyalty points, the name of the owner, or the balance. If the item includes HTML-specific JavaScript code, the Wallet will query item-specific dynamic data at the Item Provider.
  • Use Case 10 To add additional items to the electronic wallet (e.g., mWallet), the item provider can provide a catalog from which the user can select additional items. For example, these can be found as 'should be provisioned to the wallet' or accessed online and physically imported into the provider's data store.
  • the item provider can provide a catalog from which the user can select additional items. For example, these can be found as 'should be provisioned to the wallet' or accessed online and physically imported into the provider's data store.
  • Permits required and enforced by the electronic wallet e.g., mWallet.
  • this requirement is mandatory.
  • the UICC can be used as a security anchor (prerequisite: OTA channel available). Preferably, this requirement optional.
  • the communication channel should be protected in an acceptable manner. Preferably, this requirement is optional.
  • the electronic wallet (e.g., mWallet) on-device API allows third party applications - so-called item providers (IP) - to benefit from the wallet functionality. For example, it allows items to be called in different transactions.
  • IP item providers
  • the on-device API targets multiple functional wallet components, resulting in two interfaces, which are described in detail below.
  • Wallet interface Wallet transactions, Item Provider registration, Payment and IdM;
  • Item Provider interface Wallet API with item management functionality.
  • Fig. 7 relationships are provided between components and the interfaces provided and used.
  • further elements of a complete wallet ecosystem on the UICC and backend side are shown by way of example.
  • the Wallet App which offers the Wallet Interface, which can use third party applications on the device to communicate with the Wallet.
  • third party applications from the areas of couponing and loyalty are shown, which use this interface.
  • applets are shown on the UICC or the Secure Element, which are managed by the Wallet.
  • the backend area also shows the backend systems of both the wallet and third party applications that communicate over the Internet with the corresponding client applications on the end device.
  • the on-device API defined below is an abstract API that can be mapped to mobile platforms, such as Android or Windows 8, as long as the mobile platform provides an IPC mechanism between apps, which does not require user interaction.
  • the following are the platform-specific implementation topics.
  • the wallet interface contains all the operations that are called by item providers.
  • AccessToken knows: tokens,
  • Item Provider Interface The following table lists operations that are implemented by the Item Provider App and should be called by the Wallet, if available.
  • the item provider ItemData IP-advice, a new item-specific identifier
  • Primitive data types are basic data types, such as string, integer, or arrays, that have restricted ranges of values such as enumerations.
  • the on-device API uses the following primitive types:
  • This data may be GS1 encoding or something else. Syntax and semantics must be understood between the IP and the interaction point.
  • Complex data types are compound data types that contain multiple element attributes.
  • the display token consists of the following attributes:
  • imageUrl URL URL that points to the image to be displayed.
  • the picture could be dynamic
  • Contain data such as loyalty points or the coupon product or discount to be presented to the user.
  • the attribute is optional if imageEmbedded exists.
  • Android is designed to host a variety of applications and maximize user choice.
  • the platform is intended to eliminate the duplication of functionality in various applications, to allow functionality to be spontaneously found and accessed, and to have users replace applications with others that provide similar functionality.
  • Applications must have as few dependencies as possible and must be able to assign operations to other applications that may change at the user's discretion.
  • Interprocess communication is therefore the basis for some key features of the Android programming model.
  • the technique for the on-device API relevant techniques are:
  • Intents can be sent to any recipient as a broadcast.
  • Intents can be sent to a specific recipient, and results are ignored.
  • Intents can be sent to a specific recipient and the sender will be notified of the results.
  • intents will be the start option 2 - Activity.startActivity () or the start option Activity. use startActivityForResult ().
  • the item retrieval operation will use another more efficient IPC mechanism provided by the Android named ContentProvider.
  • Content Providers manage the access to a structured data record.
  • Content Providers are the standard interface that connects data in one process with code that runs in another process.
  • Wallet interface illustration
  • the login intent sent by Item Providers informs the electronic wallet (e.g., mWallet) of the existence of the handset. In addition to the name, description, and image of the provider, it places its endpoint URI to the ContentProvider for querying DisplayTokens, and an Intent action prefix used by the electronic wallet (such as mWallet) to return the ItemProvider's intentions-based operations. Call the interface, ready.
  • the login intent should be sent on two events:
  • mWallet is sent as a broadcast.
  • the intent for mapping the login operation is defined by the following attributes:
  • the useltem operation can be called from the item provider app to open the electronic wallet (e.g., mWallet) with a preselected item that can be invoked immediately.
  • the electronic wallet e.g., mWallet
  • the IP application When retrieving a register intent that is sent as a broadcast to the Android system when the electronic wallet starts up (eg mWallet), the IP application should send the login intent defined above to the electronic wallet (eg mWallet).
  • the IP application To retrieve the broadcast intent, the IP application must implement a class that extends the BroadcastReceiver class of Android and overrides the onReceive () method.
  • the mWallet will call the android.content.ContextWreapper.sendBroadcast (Intent intent) - ethode with the following Intent attributes:
  • the operations getltems () and getDisplayToken () of the IP interface are implemented using ContentProvider feature.
  • the wallet uses the ContentProvider mechanism to query and update data provided by the IP app.
  • the IP App must implement a ContentProvider that conforms to the definitions described below.
  • the manifest defmitions of the provider should be as follows:
  • the ContentProvider should provide a table that is addressed by the following attributes: Authortty: content: / / ⁇ YOUR_AUTHORITY>
  • a single card item should be accessible through the URI:
  • the item table is intended to provide the following list of columns, which are attributes of the display token as defined above, plus some parameters required to map the ⁇ interface operations to the Android ContentProvider mechanism.
  • imageUrl String maps to display Token.imageUrl
  • the cursor instances returned by the ContentProvider.query () operation should have the provider content URI set with cursor.setNotificationUri (CONTENT_URI). This is a mandatory condition for a later change message if the record is changed. For example, refer to the removeItem () operation described below. Intent imaging
  • getToken is a mandatory operation called by the electronic wallet (e.g., m Wallet) to retrieve tokens to be used within a transaction.
  • the token is displayed via QR code, transmitted via NFC, or sent as an HTTP request to a callback URI.
  • mapping for this operation is defined by the following attributes:
  • the getToken operation is called with Activiry.startActivityforResult () and expects a result intent with the following attributes.
  • the notifyUsage operation is called by the electronic wallet (eg, mWallet) when an item has been used in a transaction. It is up to the IP to interpret the payload parameters or to take any action on this event. For example, one-time items can be marked as redeemed and removed from the wallet.
  • the intent for mapping this operation is defined by the following attributes:
  • the removeltem operation is called by the electronic wallet (e.g., mWallet) when the user deletes an item. It is up to the IP to delete the item from its own data store, but the item should no longer appear in the cursor returned with the next ContentProvider query () call.
  • the electronic wallet e.g., mWallet
  • mapping this operation is defined by the following attributes:
  • the implementing IP should call context.getContentResolver (). NotifyChange (CardProvider.CARD_CONTENT_URI, null) to trigger the update of the electronic wallet view (eg mWallet).
  • importItem When provided by the item provider, the importltem operation is called by the electronic wallet (eg mWallet) when a new item is received. For example, as a result of a payment transaction, a coupon may be issued. It is up to the IP to interpret the data and store the item in its own data store. The item should appear in the cursor returned with the next ContentProvider query () call.
  • mapping this operation is defined by the following attributes:
  • the implementing IP should call context.getContentResolver (). NotifyChange (CardProvider.CARD_CONTENT_URI, null) to trigger the update of the electronic wallet view (e.g., mWallet). setDefault () If provided by the item provider, the setDefault operation is called by the electronic wallet (e.g., mWallet) when an item is marked as a default item. For example, a payment card may be preselected for transactions to ensure a fast payment or a low power mode. It's up to the IP to activate a cardlet or do some other action.
  • the intent mapping for this operation is defined by the following attributes:
  • the unsetDaul operation When provided by the item provider, we call the unsetDaul operation from the electronic wallet (e.g., mWallet) when the setting of a default item is overridden.
  • the intent for the mapping for this operation is defined by the following attributes:
  • the invoceltem operation is called by the electronic wallet (e.g., mWallet).
  • the electronic wallet e.g., mWallet
  • a Java script in the detailed description HTML can call a wallet.invoke operation and pass any kind of parameters to it.
  • a JSON string is passed here.
  • the electronic wallet e.g., mWallet
  • the electronic wallet will forward this item to the item provider by invoking the invoceltem operation. It is up to the IP to interpret the parameter and return a result JSON string passed from the electronic wallet (e.g., mWallet) to the WebView. In this way, dynamic information of an item, such as the number of loyalty points, can be displayed.
  • mapping this operation is defined by the following attributes:
  • the operation is called with Activity.startAcivityforResult () and expects a result intent with the following attributes.
  • launchCatalogue When provided by the Item Provider, the launchCatalogue operation is called by the electronic wallet (e.g., mWallet). It is expected that the ⁇ application will open and provide the user with a list of additional items that can be placed in the wallet.
  • the intent for mapping this operation is defined by the following attributes:
  • a secure on-device API is critical to preventing the wallet feature and data from unregistered third-party apps from being accessed.
  • An unsecured API would provide numerous opportunities for hostile applications that could add spam data to the wallet or collect critical data. Nonetheless, there will be some methods that can be freely used by any application, and others that can only be used in the case of strong authentication.
  • the on-device API is under the control of the provider. Since this requirement conflicts with the security architecture of some mobile operating systems, at the level of On-device API additional protection mechanisms are defined. In addition, the user is free to grant an app of a third party at the OS level the right to access the wallet.
  • the wallet supports various types of items, such as coupons, loyalty cards, payment cards and more in the future. It is obvious that potential losses and damages are quite different for each manifestation of card types.
  • the registered third-party apps are assigned a protection profile during the registration process on the DT. The assigned profile defines the security measures that the app must comply with. Depending on the assigned profile, a limited set of functions is available on Wallet's on-device API. Allocation is agreed between DeutscheInstitut and the third party developer based on a risk and business analysis for the third party, the card issuer and the end user.
  • the wallet implements all defined protection profiles. It knows the association between a third party app and the associated protection profile, which ensures that the third party app authenticates itself with the correct authentication mechanism and credentials. In addition, the Wallet will be updated with new assignments if the new third party app is registered in a Wallet backend system and accepted by DT. Fig. 8 shows these dependencies.
  • Security measures assume a non-compromising mobile operating system. If the system is affected by malicious programs, such as key loggers or spyware, the measures can be bypassed.
  • the app provider should be sensitive to possible damage caused by the app to the end user or on the card issuer's site if abused or maliciously altered.
  • the decision as to which protection profile the developer should choose is a compromise between the potential for harm and expense for app development and key distribution.
  • Anonymous profile (Fig. 9)
  • the anonymous profile can not be seen as a true protection profile because any third-party application unknown to the wallet will be sorted into that profile. It does not require credentials that must be submitted by the third party app to identify the application.
  • the profile targets apps that want to use only a subset of noncritical functions provided by the wallet that are shared for use by each application.
  • Figure 9 shows the measures that must be taken at a high level to use the unprotected on-device API.
  • the minimal protection profile aims to protect the Wallet against the unexpected use of the on-device API to prevent damage and misuse by third-party apps at the level of basic protection. It provides assurance of low development and organizational costs for third-party developers or card issuers. But it does not protect against malicious attacks since it it will be possible to spy on credentials with some effort in spying or revising.
  • This profile targets apps with no potential for harm to the end user and minimal potential damage to the card issuer. For example, it works with free coupon apps or loyalty card apps that can not cause financial harm to the end user due to the functional nature of the card.
  • the damage potential for the card user can be limited in combination with unique card IDs and real-time validation at the point of sale during redemption.
  • a single identifier for a third party app acts as the same identifier across all third party installations.
  • Fig. 10 shows the one-time actions taken at a high level for using the on-device API.
  • Strong protection profile (Fig. 1 1)
  • the strong protection profile aims to protect the wallet to prevent damage and misuse by malicious third-party apps. It ensures cryptographically that the wallet is aware of and trusted by a third-party app. As a result, development and key deployment efforts are not trivial.
  • the profile protects the wallet against the use of unregistered third-party apps and does not allow a revocation of credentials. It targets apps with significant potential damage for the user and the card issuer. For example, it fits gift card or money-worthy cards, and possibly payment cards.
  • the Wallet application ID is unique to all Wallet installations on different mobile phones. Individual credentials must be verifiable by third-party apps.
  • Each identifier of a third-party app will act as a single identifier in the wallet domain.
  • Fig. 11 shows the individual measures which must be taken for using the on-device API at a high level.
  • the first step in communicating with a third party / wallet app is the registration phase, where a third party app is promoted to the wallet ecosystem and vice versa.
  • a third party app is promoted to the wallet ecosystem and vice versa.
  • some of the registration details differ from profile to profile. Details are described per profile in the next two subsections. Registration process for anonymous profile
  • the minimal protection profile defines the authentication mechanism between the third-party app and the wallet based on a shared secret.
  • the Wallet ecosystem needs to know the secret of a third party app, and a third party app needs to know the secret of the wallet.
  • the sharing of shared keys is done in the registration process, with the third party developer registering the app after developer registration and login to the DT wallet backend.
  • sharedKey Enter shared key from the third party app
  • this can be a generated random key or the digital signature of the installation package.
  • Authentication should be used. Depending on the OS capabilities, this may be a generated random key or the digital signature of the installation package
  • the third party developer is responsible for packing the three parameters into the installation package or for deploying the information after installing the app, for example through its own backend system.
  • Every installation (wallet and third-party app) in the Wallet ecosystem acts as a single identifier. This increases the number of existing identifiers, which requires either a strict assignment between the wallet and the installations of a third-party app or a certificate hierarchy that helps to reduce the tag management overheads.
  • the third party app is registered by the developer on the wallet backend.
  • the following parameters are exchanged:
  • registrationURL output The URL used by the third party app in the second
  • the second registration step must be performed by the third-party app and wallet and will take place after the application is installed on the mobile phone.
  • the application of a third party and the wallet must generate a private / public key pair that is used by the application (in the case of the Wallet
  • UICC UICC
  • the URL was retrieved in the first step and packaged in the app installation package.
  • the backend will check the sender's ID based on the mobile network and booked service offerings.
  • This parameter contains the CA certificate (s) for the
  • this parameter will include the wallet Ca cert to verify the wallet
  • the signed certificate and the Wallet CA certificate are returned to the installation of a third-party app.
  • the certificate in combination with a signature is passed to the wallet during the authentication process by a third-party app.
  • the Wallet CA cert is used to verify the Wallet's mutual authentication certificate.
  • the parties Before the wallet's on-device API can be used, the parties must authenticate each other. Depending on the agreed protection profile, the app must provide specific credentials and must use a profile-specific authentication method provided by the Wallet API.
  • the wallet processes the login call and verifies the credentials, and finally acts as a security token service issuing a session token.
  • the session token contains a temporary session key and additional attributes needed later to calculate an access token to be passed with each API call.
  • the resulting session token is independent of specific protection profiles and has the following format:
  • Session ID Unique identifier Pid Process identifier of the calling application to ensure that the token is issued by the correct process (pid of the caller must be during the
  • encSessionkey The shared session key used to calculate and verify access tokens on subsequent API calls.
  • the session key is encrypted with the wallet credentials that are the shared key in the minimum PP or the wallet's private key if the strong PP is used. Encryption prevents anyone else from getting the secret of the session,
  • signature A signature signs all token attributes to prevent modification of the token during transit.
  • the signature is generated with the credentials of the wallet, which are the shared keys in the minimum PP or the private keys of the wallet using the strong PP.
  • Apps that are not registered with the wallet require a session token to calculate a one-time access token on every API call.
  • the session token is retrieved by calling the login method without passing any credentials.
  • the wallet will assign the session to the anonymous profile and allow only the invocation of methods whose use is free for each application. Authentication process for minimal protection profile
  • the minimum protection profile-defined authentication is based on a shared secret between the wallet and a third-party app.
  • Third party apps authenticate to the wallet by calling the login method.
  • the shared key does not become direct passed on with the call.
  • the fragmented key is used to calculate an HMAC that is passed with the call.
  • the login method provides the following parameters:
  • the wallet first checks the assignment of the application identifier and the protection profile. If the wallet knows the app's assignment to the minimal protection profile, then the HMAC provided is verified by performing the same steps as the third party app did by using the shared reasoning registered for the given application identifier. If successful, a session token including the temporary session key and another HMAC for authenticating the wallet will be generated and returned to the third party app.
  • a third-party app is free to validate the returned HMAC to validate the Wallet's identifier. Authentication process for the strong protection profile
  • the strong protection profile-defined authentication is based on a digital signature that is calculated using the app's private key and a certificate hierarchy. On the third party and wallet side, the same mechanism is used to enable mutual authentication.
  • Third party apps authenticate to the wallet by calling the login method, providing the following parameters:
  • the wallet returns a new hmac using the same computation rules, but its own shared key, which is known to the third-party app through the registration process.
  • the wallet first checks the assignment of the application identifier and the protection profile. If the wallet knows of the allocation of the strong protection pro, the given digital signature is validated. This is done by decrypting the signature with the given certificate and then comparing the decrypted hash value to the result of its own hash computation following the same steps as the third party app did. A final certificate must be validated and checked to see if it is trusted, which means that it will be issued by one of the familiar CA certs known to the wallet. The wallet returns a session token, including a temporary symmetric key and additional attributes used for further on-device API calls. A third-party app is free to validate the returned HMAC to verify the wallet's identifier. On-device API usage process
  • the on-device API can only be used if the third-party app has successfully authenticated to the wallet and retrieves a session token. It can use any Wallet API operation that belongs to the protection profile that the app complies with. For example, a coupon application can use all the methods shown by the CoreWallet interface and coupon interface.
  • the API call is processed by the wallet only if the first parameter of the
  • the access token is a unique token and is sent by the sender of the message (either the app of a third party)
  • the access token format is a custom format that is similar to popular standardized token formats that unfortunately
  • Target network communication protocols that do not necessarily apply to the Wallet On-Device API.
  • OAuth is married to HTTP and SAML to the XML format, but the on-device API can be mapped to the planned mechanism of Android.
  • the access token consists of the following attributes:
  • Sessionld identifier that identifies the current session (token)
  • Including a nonce and a timestamp in the signature calculation ensures that the access token is valid for single use only and prevents replay attacks in the event that another process on the mobile has caught an API call.
  • the access token Before processing the API call functionality, the access token must be validated at the receiver side.
  • the signature is validated by computing the HMAC signature by processing the same computation steps as the sender did, but using the shared token from the session token.
  • the attributes of the session token are validated. This step validates the validFrom and validTo attributes of the session token and matches the process ID of the sender with the PID in the Session tokens. Only if both tokens are successfully validated will the method be processed.
  • the invention also includes individual features in the figures, even if they are shown there in connection with other features and / or not mentioned above.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Telephone Function (AREA)

Abstract

L'invention concerne un procédé et un système permettant la communication basée sur des appareils terminaux entre des applications tierces et un portefeuille électronique. Le procédé comprend les étapes suivantes : (a) l'établissement d'une liaison à un service Internet par l'intermédiaire de l'application tierce, la liaison nécessitant une transmission de données au service Internet ; (b) la réception d'une demande concernant la transmission desdites données au service Internet par l'application tierce ; (c) la transmission de la demande, reçue par le service Internet à l'étape (b), au portefeuille électronique par l'application tierce ; (d) le traitement de la demande et la production d'une réponse correspondante par le portefeuille électronique ; (e) la transmission de la réponse du portefeuille électronique au service Internet ; (f) la réception d'une confirmation liée à la transmission réussie de la réponse au service Internet selon l'étape (e), la réception étant effectuée par l'application tierce.
EP13821459.8A 2012-12-19 2013-12-17 Procédé et système pour la communication basée sur des appareils terminaux entre des applications tierces et un portefeuille électronique Ceased EP2936406A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP13821459.8A EP2936406A1 (fr) 2012-12-19 2013-12-17 Procédé et système pour la communication basée sur des appareils terminaux entre des applications tierces et un portefeuille électronique

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP12198252 2012-12-19
EP13821459.8A EP2936406A1 (fr) 2012-12-19 2013-12-17 Procédé et système pour la communication basée sur des appareils terminaux entre des applications tierces et un portefeuille électronique
PCT/EP2013/076885 WO2014095850A1 (fr) 2012-12-19 2013-12-17 Procédé et système pour la communication basée sur des appareils terminaux entre des applications tierces et un portefeuille électronique

Publications (1)

Publication Number Publication Date
EP2936406A1 true EP2936406A1 (fr) 2015-10-28

Family

ID=47471559

Family Applications (1)

Application Number Title Priority Date Filing Date
EP13821459.8A Ceased EP2936406A1 (fr) 2012-12-19 2013-12-17 Procédé et système pour la communication basée sur des appareils terminaux entre des applications tierces et un portefeuille électronique

Country Status (3)

Country Link
US (1) US9898734B2 (fr)
EP (1) EP2936406A1 (fr)
WO (1) WO2014095850A1 (fr)

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10839321B2 (en) 1997-01-06 2020-11-17 Jeffrey Eder Automated data storage system
KR20140105682A (ko) * 2013-02-22 2014-09-02 삼성전자주식회사 월렛 구성요소에 관한 제휴 정보를 전달하는 단말 장치 및 그 제어 방법
US9898782B1 (en) 2013-06-28 2018-02-20 Winklevoss Ip, Llc Systems, methods, and program products for operating exchange traded products holding digital math-based assets
US10068228B1 (en) * 2013-06-28 2018-09-04 Winklevoss Ip, Llc Systems and methods for storing digital math-based assets using a secure portal
US10354325B1 (en) 2013-06-28 2019-07-16 Winklevoss Ip, Llc Computer-generated graphical user interface
US9602949B2 (en) * 2013-12-11 2017-03-21 Capital One Financial Corporation Systems and methods for populating online applications using third party platforms
CN105099984B (zh) * 2014-04-16 2019-07-02 百度在线网络技术（北京）有限公司 一种app间账号互通的方法和装置
SG11201608945WA (en) * 2014-04-25 2016-12-29 Tendyron Corp Secure data interaction method and system
US10084601B2 (en) * 2014-06-17 2018-09-25 Sony Corporation Method, system and electronic device
US9769122B2 (en) * 2014-08-28 2017-09-19 Facebook, Inc. Anonymous single sign-on to third-party systems
US9825934B1 (en) * 2014-09-26 2017-11-21 Google Inc. Operating system interface for credential management
TWI599903B (zh) * 2014-12-31 2017-09-21 鴻海精密工業股份有限公司 電子裝置的加解密系統及其加解密方法
EP3059918B1 (fr) * 2015-02-23 2018-12-12 Giesecke+Devrient Mobile Security GmbH Procédé pour accéder à un élément de sécurité
SG10201506661UA (en) * 2015-03-03 2016-10-28 Mastercard Asia Pacific Pte Ltd Method For Standardising Communication Between A Plurality Of Redemption Applications
KR101680525B1 (ko) * 2016-07-12 2016-12-06 김주한 앱 위변조 탐지 가능한 2채널 인증 대행 시스템 및 그 방법
CN111615105B (zh) * 2016-07-18 2023-08-04 创新先进技术有限公司 信息提供、获取方法、装置及终端
US10630682B1 (en) * 2016-11-23 2020-04-21 Amazon Technologies, Inc. Lightweight authentication protocol using device tokens
CN107018063A (zh) * 2017-01-19 2017-08-04 阿里巴巴集团控股有限公司 基于应用的数据交互方法及装置
US11538025B1 (en) 2017-02-14 2022-12-27 Wells Fargo Bank, N.A. Mobile wallet first time customer
GB2561396B (en) * 2017-04-13 2020-07-15 Barclays Execution Services Ltd Data security using two operating environments operating in parallel
WO2019113629A1 (fr) * 2017-12-13 2019-06-20 Metamako General Pty Ltd In Its Capacity As General Partner Of Metamako Technology Lp Système et procédés de génération et d'authentification de trafic de réseau vérifiable
US11909860B1 (en) 2018-02-12 2024-02-20 Gemini Ip, Llc Systems, methods, and program products for loaning digital assets and for depositing, holding and/or distributing collateral as a token in the form of digital assets on an underlying blockchain
US12141871B1 (en) 2018-02-12 2024-11-12 Gemini Ip, Llc System, method and program product for generating and utilizing stable value digital assets
US10438290B1 (en) 2018-03-05 2019-10-08 Winklevoss Ip, Llc System, method and program product for generating and utilizing stable value digital assets
US11025595B2 (en) 2018-04-16 2021-06-01 Samsung Electronics Co., Ltd. Secure and anonymous data sharing
US10922678B2 (en) 2018-04-24 2021-02-16 Visa International Service Association System, method and computer program product for automatic and remote control of NFC transaction processing
CN112912912A (zh) * 2018-06-28 2021-06-04 科恩巴斯公司 钱包恢复方法
US11392924B2 (en) * 2019-09-11 2022-07-19 Ebay Inc. In-person transaction processing system
CN114222988A (zh) * 2019-09-29 2022-03-22 深圳市欢太科技有限公司 支付处理方法、装置、电子设备以及存储介质
US10701560B1 (en) * 2019-10-02 2020-06-30 Capital One Services, Llc Client device authentication using contactless legacy magnetic stripe data
CN111541542B (zh) * 2019-12-31 2023-09-15 远景智能国际私人投资有限公司 请求的发送和验证方法、装置及设备
FR3116407B1 (fr) * 2020-11-13 2023-11-17 Banks And Acquirers Int Holding Procédé de traitement d’une opération impliquant des données secrètes, terminal, système et programme d’ordinateur correspondant
CN112511510B (zh) * 2020-11-18 2022-09-30 中国建设银行股份有限公司 一种授权认证方法、系统、电子设备及可读存储介质
CN112732288B (zh) * 2020-12-11 2024-05-28 北京握奇智能科技有限公司 一种数字货币硬件钱包应用升级的方法和装置
US11074142B1 (en) * 2021-01-15 2021-07-27 Coupang Corp. Systems and methods for automatically resolving system failure through force supplying cached API data
US11546159B2 (en) 2021-01-26 2023-01-03 Sap Se Long-lasting refresh tokens in self-contained format
US11757645B2 (en) * 2021-01-26 2023-09-12 Sap Se Single-use authorization codes in self-contained format
CN113672460B (zh) * 2021-08-19 2023-10-03 北京奇艺世纪科技有限公司 一种服务监控方法及装置
US11966460B2 (en) * 2022-01-25 2024-04-23 Dell Products, L.P. Facilitating generation of credentials and verification thereof within a distributed object storage system
WO2024076703A1 (fr) * 2022-10-07 2024-04-11 Best Network Systems Inc. Système de messagerie de contenu numérique

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120266220A1 (en) * 2010-11-17 2012-10-18 Sequent Software Inc. System and Method for Controlling Access to a Third-Party Application with Passwords Stored in a Secure Element

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1851695A1 (fr) * 2005-02-14 2007-11-07 SmartTrust AB Procede pour la realisation d'une transaction electronique
US9240009B2 (en) * 2006-09-24 2016-01-19 Rich House Global Technology Ltd. Mobile devices for commerce over unsecured networks
US20090234751A1 (en) * 2008-03-14 2009-09-17 Eric Chan Electronic wallet for a wireless mobile device
CA2915867C (fr) 2010-08-12 2018-03-13 Shoon Ping Wong Portefeuille utilisant des canaux de commerce multiples pour effectuer des transactions authentifiees
US20120123935A1 (en) * 2010-11-17 2012-05-17 David Brudnicki System and Method for Physical-World Based Dynamic Contactless Data Emulation in a Portable Communication Device
KR20120071982A (ko) * 2010-12-23 2012-07-03 주식회사 케이티 안전 결제를 위한 근거리 무선 통신 단말，및 근거리 무선 통신 단말을 이용한 안전 결제 방법

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120266220A1 (en) * 2010-11-17 2012-10-18 Sequent Software Inc. System and Method for Controlling Access to a Third-Party Application with Passwords Stored in a Secure Element

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
US20150348015A1 (en) 2015-12-03
WO2014095850A1 (fr) 2014-06-26
US9898734B2 (en) 2018-02-20

Similar Documents

Publication Publication Date Title
EP2936406A1 (fr) Procédé et système pour la communication basée sur des appareils terminaux entre des applications tierces et un portefeuille électronique
EP3207661B1 (fr) Infrastructure d'identité en tant que service
US7610390B2 (en) Distributed network identity
JP5423397B2 (ja) アクセス権限管理システム、アクセス権限管理方法及びアクセス権限管理用プログラム
EP2533172B2 (fr) Accès sécurisé aux données d'un appareil
CN1829227B (zh) 在单个用户范例中集成多个身份、身份机制和身份提供者的方法和系统
US9825917B2 (en) System and method of dynamic issuance of privacy preserving credentials
JP2019523493A (ja) ブロックチェーンにより実現される方法及びシステム
DE102011082101A1 (de) Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem
KR101106285B1 (ko) 통합 바코드를 이용하여 결제 정보를 처리하는 시스템 및 모바일 디바이스의 제어 방법
EP4092958B1 (fr) Émission d'une identification numérique vérifiable
DE102018005038A1 (de) Smartcard als Sicherheitstoken
EP3909221A1 (fr) Procédé pour fournir de manière fiable une identité électronique personnalisée sur un terminal
CN108319827A (zh) 一种基于osgi框架的api权限管理插件及方法
EP4128695B1 (fr) Mécanisme d'authentification personnalisé et pour un serveur spécifique
CN116915493A (zh) 安全登录方法、装置、系统、计算机设备和存储介质
EP3908946B1 (fr) Procédé pour fournir en toute sécurité une identité électronique personnalisée sur un terminal
US8181257B2 (en) Method to allow role based selective document access between domains
US7836510B1 (en) Fine-grained attribute access control
Akram et al. A novel consumer-centric card management architecture and potential security issues
US7565356B1 (en) Liberty discovery service enhancements
EP2397960B1 (fr) Procédé de lecture d'attributs d'un jeton d'identification sur une carte à puce de télécommunications et un système d'ordinateur-serveur
Rech et al. A decentralized service-platform towards cross-domain entitlement handling
Al-Sinani et al. Client-based cardspace-openid interoperation
Dmitrienko et al. Market-driven code provisioning to mobile secure hardware

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

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)
17Q First examination report despatched

Effective date: 20160901

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

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

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20170707