AT13122U1 - METHOD AND PROGRAM LOGIC FOR PROCESSING ELECTRONIC PAYMENT INSTRUCTIONS THROUGH A TELEPHONE NETWORK - Google Patents

Abstract

Method for processing electronic payment instructions (1) via a telephone network (4) to which at least one account server (7) and one proxy server (10) are connected, comprising the steps of: assigning (13, 15, 19) a unique code (Cd ) to a triple (9) for recipient account, payment amount and intended use data (B, €, A) in the proxy server; providing (16, 21) the code (Cd) for a user (2) on a user's telephone (2 '; inputting (23) the code (Cd) into the user's telephone (2 ') and sending (23-25) the code (Cd) and the sender's identifier (MS) via the telephone network (4) to the proxy server (10); determining (26) the triplet (9) associated with the code (Cd) in the proxy server (10); and transmitting (29) the triple (9) and either the sender identifier (MS) or sender account data (A) derived therefrom to the account server (7) as a payment instruction (1).

Description

Austrian Patent Office AT13 122U1 2013-06-15

Description [0001] The present invention relates to a method and a program logic for processing electronic money orders over a telephone network.

For payment transactions via telephone networks numerous solutions are known. These often require a time-consuming pre-registration of the user or the tedious entry of all relevant for a payment instruction data, such as sender account, recipient account, payment amount and purpose. This is cumbersome especially with small-size mobile terminals for mobile phone networks and therefore of low user acceptance. The invention has for its object to provide a simple and easy-to-use solution for processing electronic money orders via telephone networks, in particular mobile telephone networks.

This object is achieved in a first aspect of the invention with a method of the kind mentioned in the opening paragraph, comprising the steps of: assigning a unique code to a triple of receiver account, payment amount and usage data in the proxy server; Providing the code to a user on a user's telephone having a sender identification; Entering the code into the user's telephone and sending the code and the sender identifier to the proxy server over the telephone network; Determining the code associated with the triplet in the proxy server; and [0008] sending the triple and either the sender identifier or derived sender account data to the account server as a payment instruction.

With the aid of the method according to the invention, the user can make the payment at his terminal by entering a single code which replaces the long data sequence of recipient account, payment amount and intended use data. The terminal, e.g. Mobile phone, it is already identified by its sender ID in the system. It is particularly advantageous if the code is numeric and a maximum of eight digits, so that it is easy to remember and can also be entered via a conventional telephone number keypad. Payees such as authorities, insurance or the like. For example, this code can be printed on a bill or a hard copy and sent in paper form to the debtor, who only needs to enter the code in his mobile phone. This represents a tremendous relief to the end user for making money orders in daily life. For this purpose, no separate pre-registration of the user is required because the code references all transfer-relevant data such as recipient account, payment amount and purpose and is completed by the automatic sender ID of the user's phone.

According to a particularly preferred embodiment of the invention, the code and the subsequent payment instruction are archived in the proxy server and this code is released for a new assignment to a new triple once the payment order has been processed by the account server. Codes need thus only for "unpaid claims", comprising a triple of recipient account, payment amount and intended use, assigned and stored; as soon as a claim has been settled by a corresponding payment instruction, the same code can be reassigned. Thereby, the code length can be kept particularly short, e.g. even only 6 or 7 digits.

According to a further feature of the invention, the user's telephone to an input code can receive the associated triples from the proxy server and display on a display to the user for confirmation to increase the security and transparency for the user.

In a further embodiment of the invention, the code can also be provided to the user as a printed two-dimensional barcode and entered into the user's telephone by means of a barcode reader. This allows the user - if his phone is equipped accordingly, for example, with the help of a camera and corresponding barcode reading software - simply photograph the code, instead of typing on the keyboard. For users with conventional telephones without a barcode reader, the code can still be entered via the keyboard.

A further preferred embodiment of the invention is characterized in that each potential payee assigned a separate pool of codes and the assignment of a code from this pool is triggered to a triple by the payee. Large payees such as government agencies, insurance companies, etc. can thereby manage the assignments of the codes to the payment instruction triples themselves.

Preferably, the transmission of the code and the sender identification via the telephone network to the proxy server by means of an SMS message, which allows a broad applicability in GSM, UMTS or LTE networks due to the high spread of SMS-enabled mobile phones. Alternatively, the sending of the code and the sender identification via the telephone network can be effected by means of a smartphone app of the user's telephone, which app can provide the user with additional information in Internet-enabled telephone network environments.

It is particularly favorable if, after successful processing of the payment instruction in the account server, a confirmation message is sent via the telephone network to the user's telephone, preferably by means of an SMS message.

In a further aspect, the invention also provides a program logic which implements the described method.

The invention is explained below with reference to exemplary embodiments illustrated in the accompanying drawings. In the drawings: FIG. 1 shows hardware components for carrying out the method according to the invention; FIG. 2 shows a first embodiment of the method of the invention in the form of a sequence diagram; FIG. and FIG. 3 shows an alternative embodiment of the method of the invention with reference to FIG

Detail of Fig. 2.

With reference to Figures 1 and 2, the present method is concerned with the processing of payment instructions 1 (Figure 2) between a payment sender 2 with a user's telephone 2 'and a payee 3 with a computer 3' over a telephone network (Figure 2). Fig. 1). The telephone network 4 may be a public land mobile network (PLMN) and / or a public switched telephone network (PSTN). The telephone network 4 can also be connected via corresponding gateways 5 with data networks and / or the Internet 6 in connection.

To the telephone network 4 is connected - directly or in the example shown on the Internet 6 - an account server 7, which in a conventional manner for each payment sender 2 a sender account A and for each payee 3 a recipient account B in a database. 8 leads. The account server 7 can be the computer of an external bank, a customer account server of the telephone network 4 itself or a clearing server (intermediary) located between the telephone network 4 and an external bank, for example also a customer or credit card account server in the Internet 6.

The purpose of the processing of the payment instruction 1 is to transfer a payment amount € from a sender account A of the sender 2 to a recipient account B of the payee 3, while specifying a payment or use purpose D, which may contain any alphanumeric data, For example, an invoice number, transaction number, tax number, ticket number, a mere text such as "donation". The payment order 1 is therefore composed (at least) of data for the sender account A, the recipient account B, the payment amount € and the use case AT for the D 2 122U1 2013-06-15.

In order to process the payment instructions 1, the data receiver account B, payment amount € and intended use D are subsequently (at least) combined to form a triple {B, €, D} or 9, e.g. can be prepared by the payee 3 and represents, for example, its claim against the payment sender 2. The triple 9 is deposited by the payee 3 in a proxy server 10, more specifically its database 11. The proxy server 10 can be connected directly or via the data network or Internet 6 to the telephone network 4 and is therefore directly or indirectly connected to the account server 7 in connection.

With particular reference to FIG. 2, in a first step 12, the corresponding triples 9 are provided by the payee 3 to the proxy server 10, for example, when a claim arises, it is fed into the database 11. The proxy server 10 then assigns a unique code Cd in its database 11 to each triple {B, €, D} 9 in step 13. The codes Cd are unique throughout the system and preferably short, e.g. a maximum of 12 digits, in particular a maximum of 10 digits or more preferably a maximum of 6 to 8 digits. The codes Cd may be alphanumeric, but are preferably numeric, so that they can also be entered via a conventional numeric keypad of a mobile phone. 14 denotes the process in the proxy server 10, via which the association 15 between code Cd and triple {B, €, D} 9 is stored or maintained.

In a subsequent step 16, the code Cd is communicated to the user or Zahlungssen-the 2. The step 16 can also take place in any way outside the telephone network 4 or Internet 6, e.g. by printing the code Cd in paper form on an invoice, a payment slip, a traffic ticket, etc., and sending the paper from the payment sender 2, or in any electronic manner.

Fig. 3 shows an alternative embodiment of steps 12 to 16 for the assignment of the code Cd to the triple 9 and the provision 16 of the code Cd to the user 2. Here, in a first step 17, each potential payee 3 becomes a complete set {Cds} or 18 provided by codes Cd, eg a value range of a numeric code, and the payee 3 itself assigns the triple {B, €, D} 9 to a single code Cd from the set {Cds} 18, see step 19, e.g. on his own computer 3 '. Subsequently, the payee 3 notifies both the triple 9 and the associated code Cd to the proxy server 10 (step 20). Alternatively, the payee 3 may be e.g. make a mapping 15 between a code Cd of his sentence {Cds} 18 and a triple {B, €, D} 9 via a web interface in a shared area of the proxy server 10, which also known to him and the proxy server 10, the assignment 15 becomes.

Subsequently, the payee 3 provides the payment transmitter 2 the associated code Cd or sends it to this (step 21), for example by printing the code Cd on a bill or a payment slip and sending by mail or other transmission by electronic means.

Returning to FIG. 2, the user 2 can now use the user's telephone 2 'to send the code Cd provided or transmitted to him via the telephone network 4. The user telephone 22 is, for example, a mobile telephone, in particular according to the GSM, UMTS or LTE standard, preferably SMS-capable, and particularly preferably a smartphone that can also execute smartphone apps (software programs) and via packet-switched data connections, in particular according to the Internet Protocol, via the mobile phone network 4 and possibly the Internet 6 can communicate with the proxy server 10. However, in the preferred embodiment of the code Cd as a numeric, maximum 8-digit code, a simple user's telephone 2 'with a conventional numeric telephone keypad is sufficient to enter the code Cd, e.g. in the form of touch-tone tones (DTMF tones). A short numeric code is favorable even if it is entered in the form of an SMS and transmitted over the telephone network 4, since a short digit sequence is easy to remember and easy to input via a numeric telephone keypad. The user telephone 2 'has, in a conventional manner, a sender identification with which it can be identified in the telephone network 4, e. G. its telephone number, IMSI (International Mobile Subscriber Identity), TIMSI (Temporary IMSI), IMEI (International Mobile Equipment Identity), etc. All these unique identifications of the user's telephone 2 'are referred to herein as the sender's identifier MS. If the sender ID MS, for example, directly the phone number of the user's phone 2 'and this is directly linked to a customer account in a subscriber billing system on the account server 7 of the telephone network 4, the sender ID MS could identify the sender account A in the simplest case directly.

In steps 23 and 24, the code Cd entered by the user into the user's telephone 2 'together with the sender ID MS of the user's telephone 2' are sent via the telephone network 4 to the proxy server 10. In those cases in which the sender identification MS does not directly identify the sender account A of the payment sender 2 directly, in an intermediate step 25 the sender identifier MS can be used to find the assigned sender account A, e.g. from a customer database in the telephone network 4 or a subscriber accounting system connected thereto. The step 25 can also run directly in the proxy server 10, if this has the appropriate assignment information between sender ID MS and sender account A.

After the steps 23 to 25, the proxy server 10 thus has the user-entered code Cd and information about its sender account A. In step 26 is now in the proxy server 10 the code Cd in the process 14 associated triple {B, €, D} 9 determined.

In the optional steps 27 and 28 the tripel 9 can be sent back to the user's telephone 2 'and displayed on the user's telephone 2' in order to confirm the payment order again, e.g. as SMS or as part of a smartphone app. In step 28, the user sends back such an acknowledgment from the user's telephone 2 'to the proxy server 10, which waits for them and only then continues with the processing of the payment instruction 1. If the confirmation of step 28 does not arrive within a predetermined period of time, the code Cd and the payment instruction 1 are discarded.

The proxy server 10 now has all the data to compile a complete payment order 1 comprising the triple 9 with recipient account B, payment amount € and intended use D and the information about the sender account A. In step 29, the proxy server 10 sends the completed payment instruction [{B, €, D}, A] 1 to the account server 7. The account server 7 then executes the payment instruction 1 in step 30 and posts the payment amount € from the sender account A to the recipient account B, indicating the intended use D um.

Optionally, account server 7 may retrieve confirmation of payment sender 2 on user telephone 2 'via telephone network 4 prior to execution of payment instruction 1 at step 30, see steps 30' and 30 ", e.g. by voice prompt and keypad input, exchange of other SMS or in the context of the described smartphone app. The user specified in step 30 " entered confirmation can also be a specific for the payment transaction system of the account server 7 PIN code, which is verified by the account server 7 to authorize the execution of the money order 1.

If the payment instruction 1 was successfully executed in step 30, the account server 7 in steps 31 and 32 can optionally send confirmation messages to the user's telephone 2 'of the payment sender 2 and / or to the computer 3' of the payee B.

Further, in an optional step 33, the code Cd just used may be released to be available for a renewed assignment 15 in steps 13 and 19, respectively. Thereby a total of a smaller number of codes Cd and thus with codes Cd with a lower number of digits, e.g. a maximum of six to eight digits, the Auslangen be found because the codes Cd only for outstanding claims, i. not yet executed payment instructions 1 must be unique. In order to ensure the traceability of the payment instructions 1 for checking purposes, preference is given to all the codes 4/8 Austrian Patent Office AT13 122U1 2013-06-15

Cd and all subsequent payment instructions 1 archived in the proxy server 10 with corresponding time stamps.

The invention is not limited to the illustrated embodiments, but includes all variants and modifications that fall within the scope of the appended claims. 5.8

Claims (9)

Austrian Patent Office AT 13 122 Ul 2013-06-15 Claims 1. A method for processing electronic payment instructions (1) via a telephone network (4) to which at least one account server (7) and one proxy server (10) are connected, comprising the steps : - associating (13, 15, 19) a unique code (Cd) to a triple (9) from recipient account, payment amount and usage data (B, €, D) in the proxy server; - providing (16, 21) the code (Cd) to a user (2) on a user's telephone (2 ') having a sender identifier (MS); - entering (23) the code (Cd) into the user's telephone (2 ') and sending (23-25) the code (Cd) and the sender identifier (MS) via the telephone network (4) to the proxy server (10); - determining (26) the code (Cd) associated with the triple (9) in the proxy server (10); and - transmitting (29) the triple (9) and either the sender identifier (MS) or sender account data (A) derived therefrom to the account server (7) as a payment instruction (1); - wherein the code (Cd) and the consequent payment instruction (1) are archived in the proxy server (10), and wherein this code (Cd) is released again for a new assignment (15) to a new triple (9) (33) as soon as the payment instruction (1) has been processed by the account server (10) (30). 2. The method according to claim 1, characterized in that the unique code (Cd) is numeric and a maximum of 8 digits. 3. The method according to claim 1 or 2, characterized in that the user's telephone (2 ') for an input code (Cd) receives the associated triple (9) from the proxy server 10 (27) and on a display to the user (2) for confirmation (28). 4. The method according to any one of claims 1 to 3, characterized in that the code (Cd) as a printed two-dimensional barcode to the user (2) and input by means of a bar code reader in the user's phone (2 '). 5. The method according to any one of claims 1 to 4, characterized in that each potential payee (3) assigned a separate pool (18) of codes (Cd) and the assignment of a code (Cd) from this pool (18) to a triple (9) is triggered by the payee (3). 6. The method according to any one of claims 1 to 5, characterized in that the transmission (23-25) of the code (Cd) and the sender identification (MS) via the telephone network (4) to the proxy server (10) by means of an SMS message he follows. 7. The method according to any one of claims 1 to 5, characterized in that the transmission (23 - 25) of the code (Cd) and the sender identification (MS) via the telephone network (4) by means of a smartphone app of the user's phone (2 ') he follows. 8. The method according to any one of claims 1 to 1, characterized in that after successful processing (30) the payment instruction (1) in the account server (10) an acknowledgment message (31) via the telephone network (4) to the user's telephone (2 ') sent is, preferably by means of an SMS message. 9. program logic, implementing a method according to one of claims 1 to 8. For this 2 sheet drawings 6/8