EP2786327A1 - Système de paiement électronique - Google Patents

Système de paiement électronique

Info

Publication number
EP2786327A1
EP2786327A1 EP12852479.0A EP12852479A EP2786327A1 EP 2786327 A1 EP2786327 A1 EP 2786327A1 EP 12852479 A EP12852479 A EP 12852479A EP 2786327 A1 EP2786327 A1 EP 2786327A1
Authority
EP
European Patent Office
Prior art keywords
user
bank
server
account
payment
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.)
Withdrawn
Application number
EP12852479.0A
Other languages
German (de)
English (en)
Other versions
EP2786327A4 (fr
Inventor
Simo Salminen
Tuomo Kajava
Hannu MATILAINEN
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.)
Onsun Oy
Original Assignee
Onsun Oy
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 Onsun Oy filed Critical Onsun Oy
Publication of EP2786327A1 publication Critical patent/EP2786327A1/fr
Publication of EP2786327A4 publication Critical patent/EP2786327A4/fr
Withdrawn 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/22—Payment schemes or models
    • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking 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/3223—Realising banking transactions through 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/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • 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/22—Payment schemes or models
    • G06Q20/24—Credit schemes, i.e. "pay after"

Definitions

  • the invention relates to methods, equipment and systems for electronic payment.
  • An electronic monetary and banking system enabling electronic payment functions in a known way so that accounts of clients are maintained in the data systems of different banks.
  • Information about the resources, such as money or book-entry securities, on the account is associated to these accounts.
  • technical solutions must be applied to secure that the recipient's account is credited with the same sum as the remitter's account was debited, and that no credits or debits are generated, for which no corresponding debit or credit is found, respectively.
  • the transfer In transactions between banks, the transfer must also take place from one bank to another, and for this there are systems, by which the equivalence of the credits and debits can be secured.
  • Such technical systems in which the reliability of monetary transactions is secured by information technology equipment, are the basis for electronic payment.
  • Electronic payment is also needed in shopping on the Internet, where the merchant has to be provided with information about the transfer of the money before the merchant can provide the goods to be delivered.
  • the Internet is mostly used on mobile terminals, such as mobile phones. Therefore, various payment systems have been developed for electronic payment, based on verifications by computer and the transfer of resources (money) even without any physical interaction.
  • various systems of electronic payment there is still, for example, the risk that a third party impersonates the remitter. For this reason, the remitter has to be authenticated in the system.
  • the system may comprise, for example, the user's mobile terminal connected to a mobile communications network for the transmission of a pay- ment request, and the user's network terminal connected to the Internet for the registration of the user, and a server comprising a memory unit and an Internet server with a web application, the server being provided with means of communication with the Internet and with the mobile communications network.
  • the money transfer can be arranged to be made in three steps, the first being the registration of the user in the system by using a web application, the second being a request for mobile payment, and the third being a transaction.
  • the user can use his/her network terminal to log into the web application, enter the user specific data, and the data are transferred to the server which checks at least part of the data and transmits the user a request for confirmation.
  • the user confirms the confirmation request to the server with his/her mobile terminal.
  • the server After receiving the confirmation, the server generates register data and a trust card number of the user.
  • the user transmits a payment request to the server with the mobile terminal, the server checks the data of the pay- ment request on the basis of predetermined criteria, and either accepts or rejects the payment request on the basis of the checking, and the server transmits a confirmation request to the user.
  • the user confirms the confirmation request to the server, and the server receives the confirmation.
  • the server transmits a payment request to a bank, and the bank transfers the money to the recipient's account.
  • the server comprises software means configured to manage the system's own numerous bank accounts, to select for payment at least one source bank account from said bank accounts of the system, by applying an automatic algorithm on the basis of the bank account data of the recipient of the money, and to transfer a payment request to the banking service of the bank defined in the selected source bank account, for transferring the money from the source bank account to the recipient's account.
  • the bank transfer can be made by using a minimum number of transactions, because the system selects the source bank account in such a way that it is in the same bank or in the same banking group as the recipient's account. In this way, the bank transfer occurs as fast as possible.
  • the payment data may be verified without manual checking by employees, which requires labour.
  • the system according to the invention may be more secure than the systems of the state of the art, because in the system according to the invention the money transaction is made without the user's sensitive bank account data, by only using the system's own bank account for making payments.
  • the money is transferred from the system's bank account to the recipient's account.
  • the system grants a credit to the registered user and invoices for the credit later on.
  • the server is configured to carry out the steps of the money transfer as distinct software processes independent of each other. This increases the data security, because an error or a data security breach in one process will not spread to another process.
  • the user specific data may include at least data on the number of the user's mobile terminal, a user specific trust card number, and a user specific PIN code. By means of these data, the system can verify the user's identity in connection with a money transfer.
  • the data entered by the user are configured to be verified in three steps in connection with both the registration and the payment request.
  • the three-step verification is used to make sure that the transmitter of the payment request is the authentic user and not, for example, a person who has stolen the mobile phone from the user, whereby the security of the system for the user is improved.
  • the server may be configured to automatically compare the user specific data stored in the memory of the server with the data confirmed by the user on the mobile terminal.
  • the data to be verified may include the number of the user's mobile terminal, a user specific trust card number, and a user specific PIN code.
  • an automatic algorithm is advantageously configured to select, on the basis of the bank account data of the recipient of the money, at least one source bank account from said bank accounts of the system for the payment, said source bank account being in the same bank or banking group as the account of the recipient of the money.
  • the server is configured to make the bank transfer auto- matically. In this way, the system minimizes the need for manual work.
  • the server is configured to check the user's credit information in connection with each payment request by consulting a database of a third party. In this way, one can be sure of the acceptability of the user's credit information in connection with every money transfer.
  • the network terminal is the same device as the mobile terminal.
  • both the network terminal and the mobile terminal are the same device which can be used for both the registration and the payment requests.
  • the system further comprises a server for payment transactions and a debiting server for automatic debiting.
  • the system is configured to include a payment specific reference number in each SMS message. In this way, it is considerably easier to follow up the payments.
  • the verifications to be sent both via the web application and the mobile terminal are configured to use a common interface.
  • the system is configured to generate a corresponding virtual bar code on the basis of the user's money transaction, and to transmit the virtual bar code to the mobile terminal of the recipient of the money transaction.
  • the recipient may use the virtual bar code in the form of a conventional bar code or a number sequence for payment for example in a store, wherein the money transaction can be made without the recipient's bank account.
  • the system according to the invention it is possible to make bank trans- fers and payments of bills conveniently on a mobile terminal.
  • the invention is also characterized in that it is a system for money transfer independent of time, place and the Internet.
  • the invention provides a server system for making payments, the server system comprising means for receiving a payment request from a user; means for generating payment data to be transmitted to a bank, comprising payment data for transferring money from the user's account to the recipient's account, where said user's account and recipient's account are in different banks; means for managing the bank accounts of the system, the bank accounts of the system being in different banks, and the bank accounts of the system being different accounts than the bank accounts of said user and said recipient; means for selecting a source bank account from said bank accounts of the system by using an automatic algorithm on the basis of the bank account data of the recipient of the money, where said selection is made for generating at least one item of payment data in the bank of the selected source bank account, for transferring money from said source bank account to the recipient's account.
  • the server system may comprise means for selecting said source bank account in such a way that said source bank account is in the same bank or banking group as said target bank account.
  • the system may comprise means for tracking the durations of the bank transfers, and means for selecting said source bank account in a learning manner on the basis of said tracking.
  • the invention also provides a method for making a payment, which method comprises receiving a payment request from a user, generating payment data to be transmitted to a bank, comprising payment data for transferring money from the user's account to the recipient's account, wherein said user's account and recipient's account are in different banks, characterized in that the method comprises automatic administration of the bank accounts of the system, which bank accounts of the system are in different banks, and which bank accounts of the system are accounts different from the bank accounts of said user and said recipient; selecting by an automatic algorithm the source bank account from said bank accounts of the system on the basis of the bank account data of the recipient of the money, wherein said selection is made for generating at least one item of payment data to the bank of the selected source bank account, for transferring money from said source bank account to the recipient's account.
  • FIG. 1a shows a simplified hardware presentation of a system according to the invention, illustrating a minimum set of equipment
  • Fig. 1 b shows a simplified hardware presentation of system according to the invention, illustrating another, slightly larger set of equipment
  • Fig. 2 shows a general representation of all the processes in the system according to the invention, in block charts,
  • Figs. 3a to 3b illustrate examples of data records relating to registration (in
  • Figs. 4a to 4b illustrate data records defined in a text message for mobile payment, in general and as an example
  • Figs. 5a to 5b illustrate data records relating to a money transfer to be made in a web application, in general and as an example.
  • money transfer refers to various money transactions, including various payments, payments of bills, bank transfers, transfers from one person to another, donations, and other corresponding applications of money transfer.
  • Various terminals are connected to the system over commonly agreed interfaces.
  • a terminal may refer to any device which comprises a display and by which a connection can be implemented either via SMS mes- sages or over the normal Internet, either connected by a network cable or in a wireless manner.
  • a bank service should be understood as a wider concept than conventional banking, comprising for example such an embodiment in which the server itself acts as a bank.
  • the bank account of the user and the recipient of the money transaction may be an account belonging directly to the system.
  • the crediting and debiting of the accounts have to correspond to each other in the money transactions, as described above, and for this reason, the bank system and the money transfer have to be understood as a technical system by which the transfer of resources from one account to another can be implemented in a reliable way.
  • the system 10 comprises, as a minimum, user's mobile terminal 12 connected to a mobile communications network 130 for transmitting a money transfer request and connected to the Internet 134 for registration; and a server 114 comprising an Internet server 126, which server 114 is provided with a connection to the Internet 134 and the mobile communications network 130.
  • the mobile communications network 130 advantageously refers to a cellular radio network, but it may also comprise a WLAN network, in which case the use of a cellular radio network is not necessary.
  • the system advantageously comprises a database 120 of a third party, for checking the user's credit information, used by the server 114.
  • the mobile terminal 112 advantageously refers to a smart mobile phone having a connection to both the mobile communications network 130 and the Internet 134, wherein the same mobile terminal 112 can be used for performing both the registration and the money transfer request.
  • the mobile terminal 12 can also be an ordinary mobile phone for transmitting and receiving text messages.
  • the database 120 of the third party may be, for example, a client data register which registers persons' credit information and issues relating to that in general.
  • Figure 1 b shows an embodiment in which the user performs the registration by means of a network terminal 132.
  • the network terminal 132 may be a computer which is equipped with an Internet connection and by which the user registers his/her information in the Internet server 126 of the system.
  • the server 114 and the Internet server 126 comprised by it are shown as separate units, but in practice they can be functionalities within the same server. According to Figs. 1a and 1b, the user can also transmit the payment request via the web application by using the Inter- net 134.
  • the mobile communications network 130 comprises a service provider which is advantageously a teleoperator.
  • the teleoperator or SMS gateway service provider provides a text message service, by means of which the user trans- mits his/her payment request to the system, and by means of which the system transmits a confirmation request to the user's mobile terminal.
  • the system comprises a mobile phone for transmitting and receiving SMS messages.
  • the Internet server it is possible to use a web hotel provided by a third party, having Linux as the operating system, 2 GB of disc space, Apache 2.2 software as the www server software, PHP S as the programming language, MySQL 5.0 as the database software, and an Internet connection rate of 10 Mbit/s.
  • a suitable server for the system is a dedicated server that corresponds to an Internet server in view of the operating system, the www server software, the programming language, the database software, as well as the Internet connection, but whose disc space is 100 GB.
  • the system comprises a service provider which is directly a mobile phone operator, or an SMS gateway service provider that provides duplex SMS messages (transmission + reception), for example Securycast.
  • Third party services i.e. the credit checking, the authentication of the person, the banking services, and the debiting
  • Figure 2 shows overall presentations of all the processes to be carried out by the system according to the invention, in a schematic view. In the figure, all the steps under the heading "Automatic processes" are stand-alone and often independent of each other. The automatic procedures do not require staff.
  • the recipient of a money transfer or an invoice may be any person (except for the user him/herself) or company.
  • the recipient does not need to be registered in the system.
  • the transmitter and the recipient themselves do not need to have a bank account.
  • the receiving account may also be an account in a payment office where the recipient can call for a received remittance.
  • the trust card may be provided by a third party.
  • the trust card may also be, for example, the number of a Facebook profile or a serial number for identifying a person in a corresponding service.
  • the server is called a finance server
  • the web application is called web
  • the database of a third party is called a credit checking server.
  • the pro- vider of the system is, in these embodiment examples, called by the imaginary name Onsun.
  • FIG. 2 shows the registration of a user in a finance server, i.e. server 114, in a schematic view.
  • the registration is thus always performed via a web application 116.
  • Step 3 represents a start page
  • step 4 represents a start button for registration.
  • the user is identified, i.e. authenticated in step 5, for example by the TUPAS service (in Finland) of the user's own bank, where the user logs in the system, for example by using the credentials to the online services of his/her bank in the same way as in electronic bank- ing applications.
  • the web application checks if the authentication was successful, and if the authentication fails, the system returns the user to step 5 for authentication.
  • the system of the bank 1 8 returns the user's personal identification code back to the web application 116 for the registration process in step 6, the registration process receives the user's personal identification code in step 7, and the user selects a PIN code for him/herself for the payment of invoices or money transfers in step 8.
  • step 9 the user enters his/her own registration data, i.e. contact data, tele- phone number, email address, bank account number, and selects a PIN code that he/she wants to use in the system.
  • Figure 3a illustrates some examples of data records relating to registration (in Finland).
  • Figure 3b shows an example data record, in which the user has entered his/her data in the registration columns.
  • the user transmits the registration data to a server 114 for registration in step 9, and the server 114 stores the registration data in a memory.
  • the finance server will be commonly called a server.
  • step 10 the server 114 receives the user's registration data, and in step 11 it generates an individual trust card number for the user, which number is needed for the payment of invoices or money transfers to another party. Furthermore, in step 12, the server 114 transmits a credit check request on the basis of the user's personal identification code to a credit checking server 120, the credit checking server 120 receives the credit check request on the basis of the user's personal identification code in step 13, performs the credit checking in step 14, and returns the credit information to the server 114 in step 15.
  • the server transmits a confirmation request as a confirmation message to a mobile telephone number given by the user, i.e. the user's mobile terminal 112, in step 16.
  • the user receives the confirmation request
  • the user confirms the confirmation request with a confirmation message "CONFIRM pin_code", which he/she sends back to the server 114 on his/her own mobile terminal 112.
  • the server 114 processes the confirmation and checks if the processing was successful. If an error occurs in the processing, the server transmits an error message to the user's mobile phone.
  • An error may be caused, for example, if the PIN code entered by the user does not match the code transmitted in the confirmation message. An error may also be caused by an incorrect telephone number or by exceeding of a time limit.
  • the server 114 registers the user in its memory in step 19. As a sign of a successful registration, the server 14 transmits a text message of the successful registration to the user's mobile terminal 112. In step 20, the server remains waiting for new operations.
  • the money transfer is initiated already when the registered user sends a payment request on his/her mobile terminal 112 to the server 14 in step 22.
  • the money transfer can be performed alternatively either by a mobile phone by using text messages, or by means of a mobile phone or another mobile terminal by using an Internet connection and a web applica- tion.
  • the mobile phone can have a common mobile operating system, such as Meego, iPhone IOS, Android, or the like, for performing corresponding operations.
  • the payment request is thus sent as a text message or as a payment request of the web application.
  • each message contains a payment reference number, wherein the message traffic of different payments can be easily followed up in the system.
  • the payment application has to contain an individual trust card number generated for the user.
  • the text message it is possible to define the data records according to Figs. 4a and 4b. The data records of the payment request in the web application are shown in Figs. 5a and 5b.
  • the server 1 4 receives the payment request in step 23 and checks the content of the request and, for example on the basis of the telephone number, from which user the message was received.
  • the checking of the content refers to the following basic checks: registration of the user in the system on the basis of the telephone number, verification of the user's trust card number, verification of the PIN code selected by the user, a credit check, number of unsettled invoices, the user's age, as well as the user's blocking list.
  • the server 114 checks that the trust card number matches the trust card number of the authentic user. On the basis of the checking result, the server 114 transmits an error notice to the user's mobile terminal 112, if the data in the request are deficient.
  • the server 114 transmits a request to confirm the payment order to the user's mobile terminal 112 in step 25, to which SMS or web application request the user has to reply within a given time window.
  • the user receives the confirmation request
  • the user confirms the confirmation request by transmitting a confirmation text message "CONFIRM pin_code" or a web application confirmation to the server 114.
  • a web application it is possible to use double checking; that is, the confirmation request has to be confirmed both in the application and by an SMS.
  • the server 114 receives the confirmation in step 28 and checks in step 29 from which user/telephone number the message was received. Furthermore, the server 114 checks that the PIN code matches the PIN code of the authentic user. After this, in step 30, the server 114 passes the invoice to a payment queue. In step 31 , the server 114 remains waiting for new orders.
  • the server can send the user the following confirmation request relating to the invoice: "Confirm payment of the invoice by sending the message 'INVOICE your pin code' to number 16174. SMS: 4325".
  • the user can transmit the server the message: "invoice 1234;”.
  • the server transmits a message: "Payment of the invoice is confirmed. Delete the SMS messages relating to this transfer 544 transmitted by you. SMS: 4326".
  • the first step is that the user selects "mobile payment" as the payment option at the online store which has made a contract with the system.
  • the online store displays, in its application, the payment data of the system, for example a reference number for the payment.
  • the steps correspond to the steps described above.
  • a requirement for the online shopping is that the user has been registered in the system, has selected the items, and has started the payment of the items.
  • the system can generate a vir- tual bar code which is the reference number upon making the payment.
  • the bar code can also be generated by the system of the store.
  • Steps 32 to 40 describe how a mobile payment request is made in the sys- tern according to the invention.
  • the system differs from the systems of state of the art in that bank accounts held by the actor are maintained in the server of the system. More precisely, in a number of financial institutions or banking groups, such as banks, the actor has bank accounts which the actor has opened for business or other suitable purposes.
  • the actor's accounts are arranged in an efficient data structure.
  • the data structure that contains the actor's bank accounts and is maintained on the server is searched by an efficient algorithm for a bank account in the same financial institution or banking group, which account is set as the payment source, i.e. the source bank account.
  • a data record for the bank transfer is compiled and transmitted to the financial institution where the source and target accounts are located.
  • the bank accounts managed by the server of the system are selected so that the system would have a bank account in as many banks as possible, in view of the users.
  • Money transactions between accounts of the same bank take place almost instantaneously.
  • the system normally does not have a bank account in every bank in the world, it will suffice to have a bank account in such a bank that belongs to a given banking group.
  • Money transactions between banks in the same banking group take place quickly, wherein it will suffice that the server of the system has at least one managed bank account in each banking group.
  • the software means of the server of the system use an algorithm primarily to find, for the bank transfer, such a source bank account managed by the server that is in the same bank as the recipient's account. Secondarily, the algorithm attempts to find such a bank account managed by the server that is in the same banking group as the bank where the recipient's account is. If even such above-mentioned bank account is not found, the algorithm tries to find such a bank account managed by the server that is in a banking group which has connections to a second banking group where the bank that has the recipient's account is located. The whole payment operation is automated from the receipt of the payment request in the actor's server up to the transmission of the payment request to the bank.
  • the accounts of the user and the recipient can be in different banking groups, wherein, for each recipient's account, the server selects the fastest account from its own accounts on the basis of predeter- mined criteria. In this way, the speed of the money transfer is not dependent on the accounts of the user and the recipient being in the same bank or banking group.
  • the system may be learning with respect to payment transfer speeds, wherein it gradually learns, on the basis of trial and error, from which accounts the money is transferred in the fastest way to the recipient's account in a given bank. For the learning system, the bank transfers and their durations are followed up and stored in a memory.
  • the transaction is started in step 31 , in which the server 114 starts a new process.
  • the server 1 4 retrieves and creates payment data on new accepted payments bank by bank at regular intervals in step 33 and transmits them in step 34 to a payment transaction server 122.
  • the payment transaction server can be, for example, Opus Capita or the like.
  • the server 114 of the system can collect several payments in a "bundle" and make the bank transfers of these collectively after a sufficient number of payment requests has accumulated.
  • the payment transaction server receives data on accepted payments, and in step 36 it transfers the payment data files to the bank 118.
  • step 37 the bank 118 receives the payment file, and in step 38 it remits the payments according to the payment file from the accounts of the system to the recipients 128 specified in the payment file.
  • step 39 the recipient 128 receives the payment in his/her own account, and the process ends in step 40.
  • the bank 1 8 may inform the server 114 of the successful bank transfer, wherein the server 14 may send the user a text message or email on the successful transaction.
  • the payment transaction takes place automatically.
  • the payment is made from a bank account which is not the bank account of the user or, more generally, the party that triggers the money transaction.
  • the bank account is the account owned and managed by the actor that is the authenticating party.
  • the user of the application does not need to enter any sensitive data (account data, smart card number) in the system.
  • This increases the data security of the system considerably with regard to documents of state of the art.
  • This is made possible by a solution on the technical software level, in which the request by the user to transfer money from the actor's "optimal" account (automatic algorithm) to the target account is for- warded to such a party that can make the transfer. More precisely, such a transaction becomes free from a strong two-way trust relationship, because the source of the transaction does not need to trust the actor's system strongly. In other solutions of state of the art this is not true, because the account data of the source of the transaction are part of the transaction, and the payment is made from the source account, wherein strong authentication of the actor is needed by the user of the system.
  • the initiation of the transaction i.e. the payment request by the user with the server
  • the bank transfer are two separate processes with confined internal functionalities. This increases the security on the software level, because an error in one process will not spread to the other process and cause, for example, an incorrect bank transfer without managed and controlled automatic communication between the processes.
  • Logging in the TUPAS service on a bank website can be an operation outside the web application.
  • Figure 2 also shows a credit checking server 120, i.e. a database of a third party, by which the user's credit information is checked in connection with the registration.
  • the system may also comprise a payment transaction server and a debiting server for automatic debiting.
  • the user is granted a credit, wherein the collecting of the debt is performed in a separate process described in steps 41 to 52.
  • the server 1 4 starts a new process, and in step 42 it creates invoice data on payments that have been remitted.
  • the server 114 transfers the invoice data to an invoicing server 124, and in step 44 it remains waiting for information on new payments that have been remitted.
  • the invoicing server 124 receives the invoicing data, in step 46 it creates invoices on the basis of the invoicing data, and in step 47 it sends the invoices to the user 112'.
  • the user 112' receives the invoice, and in step 49 he/she pays the invoice, for example by mobile payment.
  • the invoicing server 124 receives information on the user 112' that has paid the invoice, and on the basis of this, it generates an invoice data record on users 112' who have paid their invoices in step 51. After this, the invoicing server 124 sends the data on the paid users to the server 114 in step 52, and in step 53 the server 114 receives the data on the users 12 ! who had paid their invoices. In step 54, the server 114 allocates the invoice data to the respective users on the basis of the reference number, and the process ends in step 55. As an alternative operation for the conventional transaction, the server can transfer the money to the recipient in the form of a virtual bar code.
  • the virtual bar code is a number sequence or an image file corresponding to a conventional bar code and generated by the system, which code can be transmitted to the mobile phone of the user or recipient in the form of an SMS or multimedia message, or by data transmission to a smart phone.
  • the owner of the mobile phone can use the virtual bar code, for example in the same way as a bottle recycling receipt at the cash desk, where the cashier reads the bar code from the display of the mobile phone or enters by typing in the cash system.
  • the bar code is for single use only.
  • the virtual bar code can be used, for example, as a gift voucher, and its value may be, for example, EUR 100.
  • the transmitter and the recipient of the vir- tual bar code do not necessarily need a bank account, and the recipient does not need to be registered in the system or connected to the system in any way.
  • Transferring money to another in the form of a virtual bar code is performed, in other respects, in the same way as a conventional transaction, up to the step 31 in Fig. 2, but the transaction itself takes place in such a way that the server transmits a single-use virtual bar code to the recipient's mobile terminal, and the recipient receives the virtual bar code in his/her mobile phone.
  • the recipient can pay at a cash desk in a store, or withdraw money from a payment office or another company that has signed a contract with the provider of the system.
  • the system may also include a mobile payment application, i.e. a "money button” application.
  • a mobile payment application i.e. a "money button” application.
  • the program asks for an account number or a possible reference number, or the like. After the fields have been filled in, the trust card number is entered, and an "accept” button is pressed. The system asks for a confirmation, to which the PIN code is given as a reply.
  • the princi- pie of operation of the money button makes it possible, for example, to buy a metro ticket quickly and simply.
  • the sums displayed on the buttons are fees for travel tickets.
  • the prerequisites for using the "money button" is that the user has registered in the system, the user has loaded the mobile application in his/her mobile terminal, and has entered the required data (user identification, trust card number) in the mobile application.
  • the mobile operating system used in the mobile phone can be one of the systems mentioned above.
  • the recipient is a company
  • the recipient of the money has to be registered as a company user in the system, and the user has to be logged in the application.
  • money is transferred by entering the recipient's account number in the application. If the application is used for paying services, the recipient has to be registered as a company user in the service. In the server, the following steps are taken automatically.
  • Example embodiments of the money button may include: A money transfer for oneself or for a friend, as well as payment of an invoice. This will require a few pressings, and the payment transaction takes place.
  • Paying of a metro ticket a program is started, in which the trip is paid by pressing a button, and the server sends a payment identification to the mobile phone. By showing this, one can enter the metro.
  • a lunch voucher, a club ticket or another payment application in an analogous manner.
  • the web service provider sets, for example, "Onsun mobile payment" as a payment alternative.
  • the data of the payment, the account number and the reference will be displayed in a protected connection. This is paid by sending a message that contains the payment and the reference of the invoice on a mobile phone, and confirming the message. In this way, the payment is transmitted from the system directly to the service provider, and the payment has been made.
  • the data transmitted by the user to the server are automatically checked by means of an algorithm.
  • the data are checked in connection with the registration and a money transfer.
  • auto- matic data checking is also used for checking credit information in connection with money transfers.
  • the algorithm of the server is advantageously configured to verify the telephone number of the mobile terminal that transmitted the payment request, the user specific PIN code relating to the transfer, as well as the trust card number; in addition, the server automatically requests for a confirmation for the money transfer, to which the user has to reply by a new message. In the automatic verification, it is possible to include any data entered by the registered user and other data which are essential for the money transfer.
  • the aim of the verification is to avoid misuse of the system. Thanks to the automatic verification, considerably less labour is needed in the system according to the invention than in the systems of state of the art, because the checking of the payment request is performed automatically and by machine. Furthermore, the automatic verification is significantly faster than manual verification, and it is carried out without human errors.
  • a smart phone refers to a mobile phone which comprises, in addition to conventional mobile phone functions, also features resembling a personal digital assistant, such as an Internet connection and software expandability.
  • the mobile operating system of the smart phone may be a common operating system, such as Meego, iPhone IOS, Android, or the like, for performing similar functions.
  • the mobile terminal used in the system may also be another mobile device having a connection to the Internet and to a mobile communications network. Such a device may be, for example, a tablet computer or a portable computer.
  • the server may be a server representing a known server technology.
  • the mobile communications network advantageously refers to a mobile phone network, which may be a GPRS, 3G, or corresponding more advanced network.
  • the user can set desired time limited withdrawal limits or a user-specific limit, for example EUR 200 per month, in the system.
  • a user-specific limit for example EUR 200 per month
  • the server sends a confirmation request to, for example, the user's mobile phone and email.
  • the large sum of money can be, for example, greater than EUR 200.
  • the system may recognize the currency used in the region of operation, wherein the user can make a payment request for exactly the correct sum in the correct currency.

Landscapes

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

Abstract

L'invention concerne un système de transfert d'argent, le système (10) comprenant - un terminal mobile (112) d'un utilisateur (112'), connecté à un réseau de communication mobile (130) pour transmettre une requête de paiement, - un terminal de réseau (132) de l'utilisateur (112'), pour l'enregistrement de l'utilisateur (112'), et - un serveur (114) comprenant une unité de mémoire et un serveur Internet (126) avec une application Internet (116), et système (10) dans lequel le transfert d'argent est configuré pour être réalisé en trois étapes, la première étant l'enregistrement de l'utilisateur (112'), la deuxième étant une requête de paiement mobile, et la troisième étant le transfert bancaire. Dans le système, le serveur (114) comprend des outils logiciels configurés - pour gérer un nombre des propres comptes bancaires du système, - pour sélectionner au moins un compte bancaire source parmi les propres comptes bancaires du système pour le paiement, par utilisation d'un algorithme automatique, sur la base des données de compte bancaire du destinataire (128) de l'argent, - pour transmettre une requête de paiement pour transférer l'argent.
EP12852479.0A 2011-12-02 2012-11-29 Système de paiement électronique Withdrawn EP2786327A4 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FI20116222A FI20116222A (fi) 2011-12-02 2011-12-02 Järjestelmä rahansiirtoa varten
PCT/FI2012/051177 WO2013079793A1 (fr) 2011-12-02 2012-11-29 Système de paiement électronique

Publications (2)

Publication Number Publication Date
EP2786327A1 true EP2786327A1 (fr) 2014-10-08
EP2786327A4 EP2786327A4 (fr) 2015-08-05

Family

ID=48534732

Family Applications (1)

Application Number Title Priority Date Filing Date
EP12852479.0A Withdrawn EP2786327A4 (fr) 2011-12-02 2012-11-29 Système de paiement électronique

Country Status (3)

Country Link
EP (1) EP2786327A4 (fr)
FI (1) FI20116222A (fr)
WO (1) WO2013079793A1 (fr)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10997592B1 (en) 2014-04-30 2021-05-04 Wells Fargo Bank, N.A. Mobile wallet account balance systems and methods
US11288660B1 (en) 2014-04-30 2022-03-29 Wells Fargo Bank, N.A. Mobile wallet account balance systems and methods
US11615401B1 (en) 2014-04-30 2023-03-28 Wells Fargo Bank, N.A. Mobile wallet authentication systems and methods
US11610197B1 (en) 2014-04-30 2023-03-21 Wells Fargo Bank, N.A. Mobile wallet rewards redemption systems and methods
US11574300B1 (en) 2014-04-30 2023-02-07 Wells Fargo Bank, N.A. Mobile wallet systems and methods using trace identifier using card networks
US11748736B1 (en) 2014-04-30 2023-09-05 Wells Fargo Bank, N.A. Mobile wallet integration within mobile banking
US9652770B1 (en) 2014-04-30 2017-05-16 Wells Fargo Bank, N.A. Mobile wallet using tokenized card systems and methods
US11461766B1 (en) 2014-04-30 2022-10-04 Wells Fargo Bank, N.A. Mobile wallet using tokenized card systems and methods
US10445739B1 (en) 2014-08-14 2019-10-15 Wells Fargo Bank, N.A. Use limitations for secondary users of financial accounts
US11853919B1 (en) 2015-03-04 2023-12-26 Wells Fargo Bank, N.A. Systems and methods for peer-to-peer funds requests
US11468414B1 (en) 2016-10-03 2022-10-11 Wells Fargo Bank, N.A. Systems and methods for establishing a pull payment relationship
US11295297B1 (en) 2018-02-26 2022-04-05 Wells Fargo Bank, N.A. Systems and methods for pushing usable objects and third-party provisioning to a mobile wallet
US11074577B1 (en) 2018-05-10 2021-07-27 Wells Fargo Bank, N.A. Systems and methods for making person-to-person payments via mobile client application
US11775955B1 (en) 2018-05-10 2023-10-03 Wells Fargo Bank, N.A. Systems and methods for making person-to-person payments via mobile client application
US12045809B1 (en) 2018-08-30 2024-07-23 Wells Fargo Bank, N.A. Biller consortium enrollment and transaction management engine
US11551190B1 (en) 2019-06-03 2023-01-10 Wells Fargo Bank, N.A. Instant network cash transfer at point of sale
US11995621B1 (en) 2021-10-22 2024-05-28 Wells Fargo Bank, N.A. Systems and methods for native, non-native, and hybrid registration and use of tags for real-time services

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070005498A1 (en) * 2000-11-06 2007-01-04 Cataline Glen R System and method for optimized funding of electronic transactions
KR100930457B1 (ko) * 2004-08-25 2009-12-08 에스케이 텔레콤주식회사 이동통신단말을 이용한 인증 및 결제 시스템과 방법
US8160959B2 (en) * 2006-07-06 2012-04-17 Firethorn Mobile, Inc. Methods and systems for payment transactions in a mobile environment
GB0804803D0 (en) * 2008-03-14 2008-04-16 British Telecomm Mobile payments
US8606706B2 (en) * 2009-02-13 2013-12-10 Bank Of America Corporation Systems, methods and computer program products for standardization of payment requests to facilitate comprehensive payment hub processing

Also Published As

Publication number Publication date
WO2013079793A1 (fr) 2013-06-06
FI20116222A (fi) 2013-06-03
EP2786327A4 (fr) 2015-08-05

Similar Documents

Publication Publication Date Title
US11983700B2 (en) System built by connection between a mobile terminal and a service providing device, and service providing method
EP2786327A1 (fr) Système de paiement électronique
US11694200B2 (en) Secure account creation
US10902403B2 (en) Electronic payment system and method thereof
US20070005467A1 (en) System and method for carrying out a financial transaction
US20120136781A1 (en) Real-time payments through financial institution
US20180225659A1 (en) Information processing device and information processing method
US20170337531A1 (en) System and methods for supporting in-flight purchase with delivery at destination airport
KR20150022754A (ko) 결제장치 및 방법
US20190164161A1 (en) System and method for Sharing account anonymously and using image coded account for easy transactions
KR20100123896A (ko) 모바일 전화기 거래 시스템 및 방법
JP6989118B2 (ja) 決済システム、ユーザ端末及びそれで実行される方法、決済装置及びそれで実行される方法、並びにプログラム
US20120330824A1 (en) Cash retrieval using payment provider
US20120173436A1 (en) Method and system for authorizing, authenticating, implementing, brokering data transfers, and collecting fees for data transfers among distributed electronic devices and servers
WO2012143547A1 (fr) Contrôle de paiement sans papier en temps réel
US20190188680A1 (en) Method and system applied to financial transactions via mobile or embedded devices
RU2479031C2 (ru) Перевод средств множеству получателей для выплаты без использования карты
JP2009015503A (ja) 業務システム、サーバ、携帯端末、オンライン端末及び来客からの処理要求の受理方法
AU2012203282A1 (en) Method and system of managing micro financial transactions on mobile communication device

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

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

DAX Request for extension of the european patent (deleted)
RA4 Supplementary search report drawn up and despatched (corrected)

Effective date: 20150703

RIC1 Information provided on ipc code assigned before grant

Ipc: G06Q 20/10 20120101ALI20150629BHEP

Ipc: G06Q 40/00 20120101ALI20150629BHEP

Ipc: G06Q 20/00 20120101AFI20150629BHEP

Ipc: G06Q 20/32 20120101ALI20150629BHEP

17Q First examination report despatched

Effective date: 20160301

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

19U Interruption of proceedings before grant

Effective date: 20160708

19W Proceedings resumed before grant after interruption of proceedings

Effective date: 20211001

PUAJ Public notification under rule 129 epc

Free format text: ORIGINAL CODE: 0009425

32PN Public notification

Free format text: COMMUNICATION PURSUANT TO RULE 142 EPC (RESUMPTION OF PROCEEDINGS UNDER RULE 142(2) EPC DATED 06.04.2021)

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20220401