WO2014086972A1

WO2014086972A1 - Method and system for mobile money

Info

Publication number: WO2014086972A1
Application number: PCT/EP2013/075796
Authority: WO
Inventors: Mischa Schmidt; Andreas Kunz
Original assignee: NEC Europe Ltd
Current assignee: NEC Europe Ltd
Priority date: 2012-12-06
Filing date: 2013-12-06
Publication date: 2014-06-12
Anticipated expiration: 2015-06-06

Abstract

A method and system for performing a mobile payment transaction between two transaction participants via a mobile network, comprising: on the part of the first transaction participant (2), providing a first transaction device – mobile subscriber's UE (3) – that is authenticated with the mobile network (4), on the part of the second transaction participant (6), providing a second transaction device that is connected to the mobile network (4), and registering said second transaction device with a dedicated application server (5) that manages the transaction details, wherein said dedicated application server (5) obtains mobile network subscription information of said mobile subscriber's UE (3), and wherein said dedicated application server (5), based on said obtained subscription information, interacts with the mobile operator charging infrastructure for performing the transaction by charging the mobile subscriber's account according to the transaction details.

Description

METHOD AND SYSTEM FOR MOBILE MONEY

The present invention relates to a method and a system for performing a mobile payment transaction between two transaction participants via a mobile network.

In order to pay at shops, e.g. supermarkets, users typically have to carry their wallet along with either cash money or moneyless payment cards. This bears several risks, e.g. the risk of robbery, loss of ID cards, etc. Especially shops have the risk of being robbed due to potentially having a high amount of cash money in their registers.

In order to address these problems, numerous alternative methods have been developed in the state of the art, many of them focusing on Near Field Communication (NFC) systems. However this requires massive rollout of NFC capable devices and depending on the solution implementation, this might be an over the top service (like the paybox service). Typically, these payment services use either specific hardware (like a mobile NFC wallet) or specific additional user credentials for additional payment services into which users often (not always) have to pay money into before using these services for paying goods or services.

In view of the above it is an objective of the present invention to improve and further develop a method and a system for performing mobile payment transactions between two transaction participants via a mobile network in such a way that a fast, easy and secure transaction procedure is enabled with only a lightweight impact to a user's mobile terminal.

In accordance with the invention, the aforementioned object is accomplished by a method comprising the features of claim 1. According to this claim such a method for performing a mobile payment transaction between two transaction participants via a mobile network, comprises

on the part of the first transaction participant, providing a first transaction device - mobile subscriber's UE - that is authenticated with the mobile network, on the part of the second transaction participant, providing a second transaction device that is connected to the mobile network, and registering said second transaction device with a dedicated application server that manages the transaction details,

wherein said dedicated application server obtains mobile network subscription information of said mobile subscriber's UE, and

wherein said dedicated application server, based on said obtained subscription information, interacts with the mobile operator charging infrastructure for performing the transaction by charging the mobile subscriber's account according to the transaction details. Furthermore, the above mentioned objective is accomplished by a system comprising the features of claim 18. According to this claim such a system for performing a mobile payment transaction between two transaction participants via a mobile network, comprises

a dedicated application server that manages the transaction details, on the part of the first transaction participant, a first transaction device - mobile subscriber's UE - that is authenticated with the mobile network,

on the part of the second transaction participant, a second transaction device that is enabled to connect to the mobile network and to register with said dedicated application server,

wherein said dedicated application server is configured to obtain mobile network subscription information of said mobile subscriber's UE and, based on said obtained subscription information, to interact with the mobile operator charging infrastructure for performing the transaction by charging the mobile subscriber's account according to the transaction details.

According to the present invention it has been recognized that many disadvantages of prior art solutions can be avoided by focusing on a higher degree of integration of the payment transaction with the mobile operator's infrastructure. Therefore, the present invention focuses at an integrated solution leveraging mobile operator charging and billing infrastructure with a lightweight impact to the mobile terminal. In other words, the present invention uses the mobile operator billing infrastructure for mobile operator subscribers to perform money transactions. For this, the subscriber ID may be used to charge payments/transactions, and also the authentication/authorization mechanisms of the mobile network can be taken into account. As such, the present invention presents a lightweight method of turning "off the shelf devices, such as tablets and/or smartphones into cash station and virtual wallet, both connected to dedicated application server - hereinafter denoted Mobile Money Payment System (MMPS) Application Server (AS) - utilizing the mobile operator charging system.

Consequently, the present invention provides a solution that does not produce any impact to a buyer's UE, i.e. there is no need for NFC or the like. Basically, the mobile device employed for a payment transaction only has to be equipped with a browser application and means for identifying a billing token, which could be e.g. a QR reader. Thus, the invention enables fast, secure, easy to use and transparent traceable payment. It is compatible with pre- and post-paid customers and enables mobile operators to offer two-way monetary transactions, essentially turning them into banks.

Implementations of the present invention are easiest when the first and the second transaction participants acting as tablet and wallet belong to the same mobile operator, else the MMPS AS needs to be connected to the other operators too, which could be simply realized as 3^rd party AS.

According to one embodiment the payment transaction may be targeted at the bank account of the first transaction participant, i.e. the mobile subscriber. Alternatively, the payment trends action could be targeted at the mobile subscriber's account with his mobile operator, e.g. with the monthly bill (in case of post-paid subscribers) or the mobile subscriber's account balance (in case of prepaid subscribers). In still another embodiment, the subscriber account may be charged indirectly, for instance through means of a premium SMS or MMS.

According to a preferred embodiment, the second transaction device may identify the goods and/or services that are intended to be subject of the payment transaction. More specifically, it may be provided that the second inspection device, which may be e.g. an LTE tablet, scans a bar code of the goods the first transaction participant would like to purchase, for instance with the help of a built- in camera. ln one embodiment the dedicated application server may provide the transaction details to the mobile subscriber's UE together with a unique billing token for identification by the mobile subscriber's UE. For instance, in one embodiment the billing token may contain a link to dedicated application server, which may be implemented in form of a Mobile Money Payment System where transaction details (e.g. items to purchase) and billing details (e.g. receiver's bank account) are stored. The mobile subscriber's UE may access this link and may instruct the Mobile Money Payment System to interact, based on the subscriber ID, with the mobile operator to charge the mobile subscriber's account according to the transaction details.

In an alternative embodiment, the subscriber device, i.e. the mobile subscriber's UE, may interact with the mobile operator to charge the indicated amount to its subscription account, get a corresponding unique billing token to the subscriber device and deliver this to the Mobile Money Payment System for validating the payment. In yet another embodiment, the unique billing token may be sent from the mobile operator to the Mobile Money Payment System directly. In another embodiment, the billing token may contain the transaction details directly. The subscriber device then interacts with the Mobile Money Payment System to charge the subscriber's account according to the transaction details.

According to preferred embodiment, which is particularly suitable for web shopping applications, the transaction details may be provided in form of a website with a virtual shopping basket including a pay button. The dedicated application server may then generate the billing token encoding a link to the created website, which is then transmitted to the second transaction participant's device. Via this device the billing token is presented/displayed to the mobile subscriber's UE, which scans and interprets the billing token and directly opens the link to the shopping basket in a browser. It is noted that at this point the mobile subscriber's UE is not authenticated to the dedicated application server, which means that the dedicated application server has no knowledge about the mobile subscriber and subscription details and the creditability of the user. Therefore, according to a preferred embodiment it may be provided that the mobile subscriber's UE uses the IP address it received from the mobile network to access the dedicated application server. The dedicated application server can then resolve the IP address of the mobile subscriber's UE into the user's subscription identity.

According to one embodiment the unique billing token that the subscriber's device identifies may be generated by one of the transaction participants (e.g. by a shop cash register or equivalent such as a tablet device), in particular based on transaction details (e.g. items purchased, bank account, amount, timestamp, etc.). In another embodiment, the billing token may be generated by a computer system (denoted "Mobile Money Payment System (MMPS)" hereafter) to which the transaction details are sent. The billing token is then sent through state of the art mechanisms to at least one of the transaction participants for the subscriber to access.

In one embodiment the billing token may be in form of a QR code.

In one embodiment, the unique billing token can be used multiple times (e.g. for donations). Alternatively, it may be provided that the billing token can be used only once.

According to a preferred embodiment it may be provided that a dedicated bearer is set up for all mobile payment related traffic exchanged between the first and the second transaction participant and the dedicated application server. Such dedicated bearer would come along with the advantage that the mobile operator could offer a special billing and treatment for the traffic going from and to the Mobile Money Payment System.

In a beneficial embodiment, the mobile subscriber's UE is prompted for confirmation of the transaction process. In addition, the first and/or second transaction participant may be informed of success or failure of the transaction process. ln one embodiment, the Mobile Money Payment System is integrated with the mobile operator infrastructure. In another embodiment, the Mobile Money Payment System may be hosted by a 3^rd party. In a beneficial embodiment, the mobile operator and/or the Mobile Money Payment System keep a record of transactions and their details for the subscriber.

There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end it is to be referred to the patent claims subordinate to patent claims 1 and 18 on the one hand and to the following explanation of preferred embodiments of the invention by way of example, illustrated by the drawing on the other hand. In connection with the explanation of the preferred embodiments of the invention by the aid of the drawing, generally preferred embodiments and further developments of the teaching will be explained. In the drawing is a schematic view illustrating the basic architecture of a system for performing mobile payment transactions in accordance with an embodiment of the invention, is a flow diagram illustrating the process of performing a payment transaction in a shopping scenario in accordance with an embodiment of the invention, Fig. 3 is a flow diagram illustrating registration of an LTE tablet to mobile money payment system in accordance with an embodiment of the invention,

Fig. 4 is a schematic view illustrating a non-roaming scenario of WLAN offloading for a 3GPP domain supporting an application function of a mobile money payment system, and

Fig. 5 is a schematic view illustrating a roaming scenario with the application function of the mobile money payment system in HPLMN. Fig. 1 schematically illustrates a possible deployment architecture of a mobile payment transaction system 1 in accordance with an embodiment of the present invention related to a shopping scenario. The first transaction participant 2, who is assumed to act as customer/buyer, is a user having a user device, hereinafter briefly denoted UE 3, such as a smartphone equipped with a browser and kind of camera, that is subscribed to the mobile network 4. The UE 3 is connected to a Mobile Money Payment System (MMPS) 5, which acts as a dedicated Application Server (AS) that manages the transaction details. Hereinafter, the expressions dedicated application server, Mobile Money Payment System, or MMPS AS will be used synonymously. The transaction process is performed by turning the UE 3 into a virtual wallet, as will be described in more detail below.

The second transaction participant 6, who is assumed to act as vendor, uses a device with subscription and connectivity capabilities to the mobile network 4, e.g. GRPS, UMTS, WiFi, etc. The transaction process is performed by turning the second transaction participant's 6 device into a cash station, as will be described in more detail below. In Fig. 1 , two possible embodiments are illustrated: an LTE Tablet 7 connected via the mobile network 4 to the Mobile Money Payment System 5 and a WiFi Tablet 8 connected via a Gateway Component (HGW) 9 to the Mobile Money Payment System 5. It is noted that the second transaction participant's 6 device could also be a smartphone with corresponding above capabilities. In any case, the device must have the capabilities of presenting a billing token, e.g. in form of a QR code, to the UE 3, as illustrated by the dashed lines.

The HSS (Home Subscriber Server) 10 illustrated in Fig. 1 is a subscriber database containing subscriber details for billing and UE 3 authentication. Fig. 2 shows a procedure of a payment process in accordance with an embodiment of the invention. More specifically, Fig. 2 shows a possible call flow where the second transaction participant's 6 device, which is an LTE Tablet 7 in the illustrated embodiment, is used as a cash register replacement in a shop. However, it is noted that the field of application of the present invention is not limited to shopping scenarios: even subscribers who would like to exchange money for arbitrary reasons might use the Mobile Money Payment System 5 instead of traditional bank transfers. In an extreme use case of such scenario, the mobile operator and/or the Mobile Money Payment System 5 take over the role of a bank.

The LTE Tablet 7 has a build-in LTE modem and has a valid subscription of the operator of the mobile network 4, briefly denoted mobile operator hereinafter. Once the Tablet performed the Initial Attach (for instance, in accordance with the 3GPP TS 23.401 specifications), it has a default bearer ready for communication. It is assumed that a dedicated application, hereinafter referred to as Mobile Payment Application (MPA), is implemented on the LTE Tablet 7, which, once started by the user of the LTE Tablet 7, tries to register with the MMPS AS 5. This registration call flow is depicted in Fig. 3.

Turning now to Fig. 3, in Step 1 the user of the LTE Tablet 7 starts the MPA. Thereupon, in Step 2 the LTE Tablet's 5 MPA sends via the default bearer a registration request to the MMPS AS 5, e.g. addressed with a routable name/URI like mmpsas.home1.net. In the illustrated embodiment the registration request contains the relevant information, e.g. the registered user identity of the LTE tablet 7 in the mobile network 4, which could be e.g. IMS (IP Multimedia System) public user identity, Public Service Identity, MSISDN (Mobile Subscriber ISDN Number), IMSI (International Mobile Subscriber Identity), etc. Also a specific mobile payment identifier (MP ID) that helps the MMPS AS 5 to identify a specific MPA of a user can be considered. Such MP IDs could be also used by the MMPS AS 5 to group mobile payment identifiers of several tablets to one shop. The MMPS AS 5 can act as an Application Function (AF) and can provide Application information about the payment traffic to the PCRF (Policy and Charging Rules Function) 11 (Step 3). Since the MMPS AS 5 has no Subscription ID and SIP/SDP (Session Initiation/Description Protocol) related information, it can leave them out in the AAR message, which may be based on the AAR message defined in 3GPP TS 29.214 "Policy and charging control over Rx reference point": := < Diameter Header 265, REQ, PXY > Session-Id >

Auth-Application-Id }

Origin-Host }

Origin-Realm }

Destination-Realm }

Destination-Host ]

AF-Application-Identifier ]

Service-Info-Status ]

AF-Charging-Identifier ]

Specific-Action ]

Supported-Features ]

Reservation-Priority ]

Framed-IP-Address ]

Framed-IPv6-Prefix ]

[ Called-Station-Id ]

Sponsored-Connectivity-Data ]

MPS-Identifier ]

Rx-Request-Type ]

Required-Access-Info ]

Origin-State-Id ]

Proxy-Info ]

Route-Record ]

AVP ]

The PCRF 1 1 identifies the corresponding Subscription ID that is bound to the IP Address and can do a policy decision (Step 4). In particular, the PCRF 1 1 could provide a PCC (Policy and Charging Control) rule to the PCEF/PGW (Policy and Charging Enforcement Function/PDN Gateway) 12, e.g. for setting up a dedicated bearer for all traffic from and to the MPA, a "dedicated mobile payment bearer" (Step 5). This would have the advantage that the mobile operator could offer a special billing and treatment for the traffic going from and to the MMPS AS 5. After processing the rule and taking the actions, the PCEF/PGW 12 acknowledges the PCC rule to the PCRF 1 1 (Step 6) and the PCRF acknowledges the application information to the MMPS AS 5 (Step 7). In case the LTE Tablet's 7 MPA is used "over the top" of the mobile operator's packet switched (PS) data service and the LTE Tablet 7 has not provided any user identity in the registration request, e.g. only a specific mobile payment identity, then the MMPS AS 5 would receive the user identity in Step 7 and can make a binding of IP address, user identity and mobile payment identity. The AAA message may be based on the AAA message defined in 3GPP TS 29.214 "Policy and charging control over Rx reference point" and may have the following format: <AA-Answer> ::= < Diameter Header: 265, PXY >

< Session-Id >

{ Auth-Application-Id }

{ Origin-Host }

{ Origin-Realm }

[ Result-Code ]

[ Experimental-Result ]

* [ Access-Network-Charging-Identifier ]

[ Access-Network-Charging-Address ]

[ Acceptable-Service-Info ]

[ IP-CAN-Type ]

►* [ Subscription-Id ]

[ RAT-Type ]

* [ Flows ]

* [ Supported-Features ]

*[ Class ]

[ Error-Message ]

[ Error-Reporting-Host ]

* [ Failed-AVP ]

[ Origin-State-Id ]

* [ Redirect-Host ]

[ Redirect-Host-Usage ]

[ Redirect-Max-Cache-Time ]

* [ Proxy-Info ]

* [ AVP ]

The newly introduced field "Subscription-ID" (marked with *- in the above text) carrying the mobile payment identity is only needed if there are several tablets/MPAs sharing the same shop in the MMPS AS 5. The subscription ID is necessary to uniquely identify the subscriber 2 for later billing of the shop bill.

The MMPS AS 5 can now do a User Data Request from the mobile operator's HSS 10 in Step 8 and will receive the User Data Answer in Step 9 with all relevant subscription information. The MMPS AS 5 detects the shop linked to the subscription and mobile payment identifier in Step 10 and sends an acknowledgement to the registration in Step 1 1. In case a dedicated mobile payment bearer was setup, the message will be send via this bearer. Also additional security means for encryption of the messages e.g. with https, can be now taken into account, since now the LTE tablet 7 is identified by the MMPS AS 5 and can be considered trusted. Turning now back to Fig. 2, it is first of all explicitly noted that one or more of the procedural steps described hereinafter in detail may be omitted in certain embodiments, or may be executed in a different order. As a prerequisite the LTE Tablet 7 is assumed to be registered to the MMPS AS 5 as described above in connection with Fig. 3. In Step 1 , the LTE tablet 7 scans the bar code of goods the first transaction participant 2, who is subscribed to the mobile network 4, would like to purchase, for instance with the help of a built in camera. In Step 2, the LTE tablet 7 interacts with the Mobile Money Payment System 5 by submitting the item list and prices the first transaction participant 2 intends to purchase as well as account details. It also provides its MP ID and registered user identity, if known by the MPA. If the registered user identity of the mobile network 4 is not provided, then the identification Steps 3-7, as described in connection with Fig. 3, can be carried out to identify the subscription. The Mobile Money Payment System 5 may create a web site with a virtual shopping basket in which the items and the prices are listed together with a confirmation button (denoted "pay button" for later use by the UE 3) (Step 3). The Mobile Money Payment System 5 then creates a unique billing token in form of a QR code encoding a link to this created web page, possibly with authentication credentials. This QR code is then sent back to the LTE tablet 7 (Step 4). The LTE tablet 7 displays the QR code, containing the link to the shopping basket at the MMPS AS 5 (Step 5).

In Step 6, the UE 3 scans and interprets the QR code presented by the LTE tablet 7, and the UE 3 will directly open the link to the shopping basket in a browser and sends a HTTP GET to the MMPS AS 5 (Step 7). At this point in time, the UE 3 is not authenticated to the MMPS AS 5, and the MMPS AS 5 has no knowledge about the subscriber and subscription details and the creditability of the user. The MMPS AS 5 just sees the IP address given by the PGW 12 to the UE 3 for the default bearer. ln Step 8, the MMPS AS 5 acts as an Application Function (AF) and sends application information to the PCRF 1 1. Since the MMPS AS 5 has no Subscription ID of the UE 3 and no SIP/SDP related information, it can leave them out in the AAR message, which may be based on the AAR message defined in 3GPP TS 29.214 "Policy and charging control over Rx reference point":

<AA-Request> ::= < Diameter Header: 265, REQ, PXY >

< Session-Id >

{ Auth-Application-Id }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

[ Destination-Host ]

[ AF-Application-Identifier ]

[ Service-Info-Status ]

[ AF-Charging-Identifier ]

* [ Specific-Action ]

* [ Supported-Features ]

[ Reservation-Priority ]

[ Framed-IP-Address ]

[ Framed-IPv6-Prefix ]

[ Called-Station-Id ]

[ Sponsored-Connectivity-Data ]

[ MPS-Identifier ]

[ Rx-Request-Type ]

* [ Required-Access-Info ]

[ Origin-State-Id ]

* [ Proxy-Info ]

* [ Route-Record ]

* [ AVP ]

The PCRF 1 1 identifies the corresponding Subscription ID that is bound to the IP Address and may decide on a rule to establish a dedicated mobile payment bearer (Step 9). In Step 10, the PCRF 1 1 sends a rule to the PCEF/PGW 12. After processing the rule and taking the actions, the PCEF/PGW 12 acknowledges the PCC rule to the PCRF 11 (Step 1 1 ), and the PCRF 1 1 acknowledges the application information to the MMPS AS 5 (Step 12). The MMPS AS 5 would receive the user identity (newly introduced field "Subscription-ID", *- in below text) in Step 12 and can make a binding of IP address and user identity of the UE 3. The AAA message may be based on the AAA message defined in 3GPP TS 29.214 "Policy and charging control over Rx reference point" and may have the following format:

<AA-Answer> = < Diameter Header: 265, PXY >

Session-Id >

Auth-Application-Id }

Origin-Host }

Origin-Realm }

Result-Code ]

Experimental-Result ]

Access-Network-Charging-1dentifier ]

Access-Network-Charging-Address ]

Acceptable-Service-Info ]

IP-CAN-Type ]

[ Subscription-Id ]

RAT-Type ]

Flows ]

Supported-Features ]

* [ Class ]

Error-Message ]

Error-Reporting-Host ]

Failed-AVP ]

Origin-State-Id ]

* [ Redirect-Host ]

[ Redirect-Host-Usage ]

[ Redirect-Max-Cache-Time ]

* [ Proxy-Info ]

* [ AVP ]

The MMPS AS 5 can now do a User Data Request from the mobile operator's HSS 10 in Step 13 and will receive the User Data Answer in Step 14 with all relevant subscription information of the UE 3. The MMPS AS 5 can now do a check of the subscription profile and, e.g., the financial status of the first transaction participant 2, for instance in case of prepaid customers (Step 15). The MMPS AS 5 will send in Step 16 the acknowledgement to the HTTP GET with the website to the UE 3. In case a dedicated mobile payment bearer was setup, the message will be send via this bearer. Also additional security means for encryption of the messages can be now taken into account. ln Step 17, the UE 3 accesses the virtual shopping basket and the pay button. In Step 18, upon pressing the pay button, the UE 3 proceeds to step 19 where it confirms the transaction at the Mobile Money Payment System 5.

In Step 20, the Mobile Money Payment System 5 interacts with the mobile operator's HSS 10 and/or charging system for performing the transaction, e.g. by adding the chargeable amount to the subscriber's monthly phone bill. For traceability, the Mobile Money Payment System 5 and the HSS 10 add the bought items to the subscriber history of bought items.

In Steps 21 and 22, confirmation messages relating to the successful transaction are sent both to the LTE tablet 7 and to the UE 3. As shown above, the present invention enables that by relying on state of the art web shopping functionality a user can pay using his mobile bill without the need to use specific credentials. Embodiments of the present invention rely on the fact that the mobile subscriber's UE authenticated with the mobile operator network with the correct credentials beforehand and received an IP address to the UE. The present invention provides the means of verifying, identifying and charging the user by resolving said UE IP address used to access the MMPS AS (e.g. a website showing a shopping basket to the user) to the user subscription identity. This identity is then used to charge the user. Essential features and embodiments of the present invention can thus be summarized as follows: a. Using a device (e.g. a tablet PC) with a Mobile Payment Application, turning it into a cash station

b. Using a user device (UE) such as a smartphone with QR reader and browser, turning it into a virtual wallet

c. MMPS AS is able to act as an Application Function and can authenticate a UE based on its IP address with PCC procedures,

d. UE and Tablet can use dedicated mobile payment bearers for real time transactions. e. MMPS AS can interact with the mobile operators charging system and add the chargeable amount of money to the buyers phone bill.

It should be noted that a 3rd party service provider (i.e. the shopping website cooperating with (but not tightly integrated into) the operator network) can also retrieve the user ID (e.g. the user's IMSI) from the operator network by using the present invention and then use the operator charging system to charge the user appropriately. In another embodiment, the method described above can be also used in scenario for non-seamless WLAN offloading (NSWO) as illustrated in Fig. 4. According to this embodiment, the UE 3 is connected to the mobile network 4, which is a 3GPP operator network 15, via a BBF (Broadband Forum) defined access and network 16. Since the skilled artisan is familiar with this kind of network, only those components that are required for executing a method in accordance with the present invention will be described hereinafter, while the description of other components is omitted.

The AF 17 (implemented with the MMPS AS 5) cannot identify the subscriber itself, i.e. the first transaction participant 2 or the UE 3, respectively, based on the IP address, so it has to send an AAR request to the PCRF 1 1. The BPCF (Broadband Policy Control Framework, as specified in TR-134, Issue 1 , July 2012) 18 receives the IMSI and the Fixed Broadband Access allocated UE local IP address when 3GPP access authentication is performed. The BPCF 18 includes the IMSI, IP-CAN type, UE local IP address and the NSWO-APN in the message to the PCRF, so the PCRF 1 1 can do the binding of subscription ID and IP address and can answer the AF 17 with such information in the AAA.

In case of roaming and home services, illustrated in Fig. 5, the AF 17 resides in the HPLMN (Home Public Land Mobile Network) 19 while the PDN-GW 12 performs a local breakout in the VPLMN (Visited Public Land Mobile Network) 20. Requests now arriving at the AF 17 might have traversed transit networks and NATs so that the source IP address cannot be used uniquely as an identification to be linked with the subscription ID. According to 3GPP TS 23.401 , when the UE 3 performs the initial attach, the PCEF in the PDN-GW 12 triggers the IP-CAN session establishment procedure as described in 3GPP TS 23.203. In this procedure the PDN-GW 12 sends an Indication of IP-CAN bearer establishment, including the following information: UE Identity (e.g. MN NAI), a PDN identifier (e.g. APN), the IP CAN type and the IPv4 address and IPv6 network prefix. The PDN identifier, IP address(es) and UE 3 identity enables identification of the IP CAN session. The UE 3 identity sent to the H-PCRF 21 is recommended to be from the format of a MN NAI (3GPP TS 23.003 describes how the NAI is derived from the IMSI, especially for UEs without ISIM application). 3GPP TS 23.203 further describes if the PCRF does not have the subscriber's subscription related information, it sends a request to the SPR in order to receive the information related to the IP CAN session. The PCRF provides the subscriber ID and, if applicable, the PDN identifier to the SPR. The PCRF may request notifications from the SPR on changes in the subscription information.

Now the H-PCRF 21 has the subscription identity and can include it in the AAA to the AF 17, in case the subscription identity was missing in the AAR.

Many modifications and other embodiments of the invention set forth herein will come to mind the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

C l a i m s

1. Method for performing a mobile payment transaction between two transaction participants via a mobile network, comprising:

on the part of the first transaction participant (2), providing a first transaction device - mobile subscriber's UE (3) - that is authenticated with the mobile network (4),

on the part of the second transaction participant (6), providing a second transaction device that is connected to the mobile network (4), and registering said second transaction device with a dedicated application server (5) that manages the transaction details,

wherein said dedicated application server (5) obtains mobile network subscription information of said mobile subscriber's UE (3), and

wherein said dedicated application server (5), based on said obtained subscription information, interacts with the mobile operator charging infrastructure for performing the transaction by charging the mobile subscriber's account according to the transaction details.

2. Method according to claim 1 , wherein the payment transaction is targeted at the mobile subscriber's bank account or at the mobile subscriber's mobile operator account.

3. Method according to claim 1 or 2, wherein said second transaction device identifies the goods and/or services that are intended to be subject of the payment transaction.

4. Method according to any of claims 1 to 3, wherein said dedicated application server (5) provides the transaction details to said mobile subscriber's UE (3) together with a unique billing token for identification by the mobile subscriber's UE (3).

5. Method according to claim 4, wherein said billing token is generated to contain a link to said dedicated application server (5) where the transaction details are stored.

6. Method according to claim 4 or 5, wherein said billing token is generated to contain the transaction details directly.

7. Method according to of claims 1 to 6, wherein the transaction details are provided in form of a website with a virtual shopping basket including a pay button.

8. Method according to of claims 1 to 7, wherein said mobile subscriber's UE (3) uses the IP address it received from the mobile network (4) to access said dedicated application server (5).

9. Method according to claim 8, wherein said dedicated application server (5) resolves said IP address of the mobile subscriber's UE (3) into the first transaction participant's (2) subscription identity.

10. Method according to of claims 4 to 9, wherein said billing token is generated based on the transaction details.

1 1. Method according to of claims 4 to 10, wherein said billing token is generated by one of the transactions participants or by said dedicated application server (5).

12. Method according to of claims 4 to 1 1 , wherein said billing token is generated in form of a QR code.

13. Method according to of claims 4 to 12, wherein said billing token is generated to be valid for a single payment transaction only.

14. Method according to of claims 1 to 13, wherein a dedicated bearer for all mobile payment related traffic exchanged between said first and second transaction participants (2, 6) and said dedicated application server (5) is set up.

15. Method according to of claims 1 to 14, wherein the mobile subscriber's UE (3) is prompted for confirmation of the payment transaction process.

16. Method according to of claims 1 to 15, wherein the mobile subscriber's UE (3) is informed of success or failure of the payment transaction process.

17. Method according to of claims 1 to 16, wherein the mobile operator and/or said dedicated application server (5) keep a record of payment transactions performed for the mobile subscriber.

18. System for performing a mobile payment transaction between two transaction participants via a mobile network, in particular for executing a method according to any of claims 1 to 17, the system comprising:

a dedicated application server (5) that manages the transaction details, on the part of the first transaction participant, a first transaction device - mobile subscriber's UE (3) - that is authenticated with the mobile network,

on the part of the second transaction participant, a second transaction device that is enabled to connect to the mobile network and to register with said dedicated application server (5),

wherein said dedicated application server (5) is configured to obtain mobile network subscription information of said mobile subscriber's UE (3) and, based on said obtained subscription information, to interact with the mobile operator charging infrastructure for performing the transaction by charging the mobile subscriber's account according to the transaction details.

19. System according to claim 18, wherein said dedicated application server (5) is integrated with the mobile operator infrastructure.

20. System according to claim 18, wherein said dedicated application server (5) is hosted by a third party.

21. System according to any of claims 18 to 20, wherein said first and/or said second transaction device are equipped with means adapted to capture and analyze said billing token, in particular a QR reader.

22. System according to any of claims 18 to 21 , wherein said first transaction device is a smartphone.

23. System according to any of claims 18 to 22, wherein said second transaction device is an LTE tablet (7), a WiFi tablet, or a smartphone.