WO2009004393A1 - System, central clearing unit and method for effectuating financial transactions in a virtual environment, electronic commerce system and method, and computer program product - Google Patents

System, central clearing unit and method for effectuating financial transactions in a virtual environment, electronic commerce system and method, and computer program product Download PDF

Info

Publication number
WO2009004393A1
WO2009004393A1 PCT/HU2008/000077 HU2008000077W WO2009004393A1 WO 2009004393 A1 WO2009004393 A1 WO 2009004393A1 HU 2008000077 W HU2008000077 W HU 2008000077W WO 2009004393 A1 WO2009004393 A1 WO 2009004393A1
Authority
WO
WIPO (PCT)
Prior art keywords
virtual
pay
client application
demand client
bank
Prior art date
Application number
PCT/HU2008/000077
Other languages
French (fr)
Inventor
Ádám MÓNUS
Antal Kuthy
Gábor Garami
Original Assignee
Monus Adam
Antal Kuthy
Garami Gabor
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 Monus Adam, Antal Kuthy, Garami Gabor filed Critical Monus Adam
Publication of WO2009004393A1 publication Critical patent/WO2009004393A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]

Definitions

  • the present inventions relates to cashless payment systems and methods. More particularly, the present invention relates to a system, a central clearing unit and a method for effectuating financial transactions in a virtual environment, as well as an electronic commerce system and method, and computer program product. Due to the rapid development of the computer techniques and the telecommunications, as well as to spreading of the internet, the services based on cashless payment, in particular the online commerce services, have been used to an increasing extent.
  • the object of the present invention is to eliminate the drawbacks of the aforementioned systems and other similar systems and to provide a system and a method for effectuating the shoppings or financial transactions of small amount, like money transfers, in an electronic way that incurs lower costs and allows higher efficiency and security than before.
  • the present invention is based on the recognition that if the transactions of small amount are effectuated in the virtual space, between virtual wallets managed by a separate, independent central clearing unit, rather than between real bank accounts, and the balance of the virtual wallets are carried over to the associated bank accounts only at predetermined times or under predetermined conditions, than the total cost of effectuating of said transactions of small amount will significantly reduce both at the system level and at the user level.
  • the online commerce in particular the internet shopping, provide several platforms allowing to effectuate financial transactions in the virtual space without the need of a direct participation of banks, but with information and financial co-operation with the banks.
  • the system further comprises at least one pay-on-demand client application adapted for accessing to a virtual wallet associated with a bank account to be debited through a communication interconnection; at least one second pay-on-demand client application adapted for accessing to a virtual wallet associated with a bank account to be credited through a communication interconnection; a communication interconnection between the at least one first pay-on-demand client application and the at least one second pay- on-demand client application; at least one bank computer for managing the bank accounts associated with the virtual wallets; and a central clearing unit communicating with the at least one first pay-on-demand client application, the at least one second pay-on-demand client application and the at least one bank computer.
  • the central clearing unit comprises means for storing the associations between the virtual wallets and the respective bank accounts; a client communication interface for communicating with the at least one first pay-on-demand client application and the at least one second pay-on-demand client application; a bank communication interface for communicating with the at least one bank computer; and a processing unit for managing the balances of the virtual wallets according to instructions received form the at least one first pay-on-demand client application, the at least one second pay-on- demand client application and the at least one bank computer.
  • the above objects are further achieved by providing an electronic commerce system based on virtual payment, in particular for use in internet shopping, wherein each of the buyers and the users has at least one virtual wallet and each of the wallets is associated with a bank account.
  • the system comprises at least one web application to allow for a buyer to select a product or service to be merchandized electronically; and at least one web server for operating the web pages containing the products and/or services that can be purchased in electronic way; wherein each of the products and/or services has a web page where a virtual payment for a selected product or service may be initiated.
  • This system further comprises at least one pay-on-demand client application adapted for accessing by a buyer to his virtual wallet through a communication interconnection; at least one second pay-on-demand client application adapted for accessing by a merchant to his virtual wallet through a communication interconnection; at least one bank computer for managing the bank accounts associated with the virtual wallets of the buyer and the merchant; and a central clearing unit communicating with the at least one first pay-on-demand client application, the at least one second pay-on-demand client application and the at least one bank computer, said unit forming a component of a system capable of effectuating virtual financial transactions in a virtual environment.
  • the client side communication interconnections are established through the internet, a landline telephone network, a mobile telephone network, a cable television network or other digital data transmission system or any combination thereof.
  • the bank side communication interconnection is established through a landline telephone network, other dedicated data transmission line or a combination thereof.
  • one or more virtual sub-purse is associated with at least one virtual wallet serving as a main virtual wallet, and the processing unit is adapted for managing the balances of the virtual sub-purse belonging to the respective main virtual wallets.
  • the processing unit further comprises means for filling up a virtual sub-purse with a specified virtual fund by debiting the associated main virtual wallet, and means for carrying over the specified fund from the virtual sub-purse to the bank account associated with the respective main virtual wallet through the main virtual wallet.
  • the central clearing unit preferably further comprises means for sending, to the first pay-on-demand client application, a request for approval of effectuating a virtual financial transaction initiated by the first pay-on-demand client application, and for receiving, from the first pay-on-demand client application, a response containing a permission or a prohibition of effectuating the virtual financial transaction.
  • the central clearing unit further comprises means for notifying at least the second pay-on-demand client application, more preferably both the first pay- on-demand client application and the second pay-on-demand client application, regarding the financial transaction effectuated in the virtual space.
  • the above mentioned objects are also achieved by providing a method for effectuating virtual transactions in a virtual environment, wherein each of the users has at least one virtual wallet.
  • the method comprises the steps of associating the bank account of each virtual wallet, and storing the associations between the virtual wallets and the respective bank accounts; operating at least one pay-on-demand client application adapted for accessing to a virtual wallet; sending a request, from a first pay- on-demand client application to a second pay-on-demand client application, for debiting the virtual wallet associated with the first bank account with a specified amount and for crediting said amount in a second virtual wallet associated with a second bank account; sending a request, from the second pay-on-demand client application receiving the request to a central clearing unit, for effectuating said transaction; checking whether the requested transaction can be effectuated in view of the balance of the first virtual wallet; if the requested transaction can be effectuated, effectuating the virtual financial transaction in the central clearing unit by decreasing the balance of the first virtual wallet by the specified amount and increasing the balance of the
  • the method further comprises the steps of sending a request, from the central clearing unit to the first pay-on-demand client application, for an approval of effectuating the virtual financial transaction initiated by the first pay-on-demand client application; sending a response from the first pay-on-demand client application to the central clearing unit, said response containing either a permission or a prohibition of the effectuation of the virtual financial transaction; and additionally examining the content of the approval message received from the first pay-on-demand client application when checking whether the virtual financial transaction can be effectuated.
  • the acknowledgement message with respect to the successful effectuation of the virtual financial transaction or the notification with respect to the unsuccessful effectuation of the virtual financial transaction is sent to both the first pay- on-demand client application and the second pay-on-demand client application. If one or more virtual sub-purse is associated with at least one virtual wallet serving as main virtual wallet, it is preferred that the balances of the virtual sub-purses associated with the respective main virtual wallets are managed separately.
  • the virtual sub-purse is filled up with a virtual fund by debiting the main virtual wallet with said fund, and the entire balance of the virtual sub-purse or a portion thereof is carried over to the bank account belonging to the main virtual wallet through the main virtual wallet.
  • the above objects are further achieved by providing a method of electronic commerce based on virtual payment, in particular for use in internet shopping.
  • the method comprises the steps of: operating at least one web application to allow a buyer to select a product or service to be merchandized in electronic way; operating at least one web server to manage the web pages containing the products and/or services that can be purchased in electronic way, wherein each one of the products and/or services has a web page where a virtual payment may be initiated in connection with the selected product or service.
  • the counter value of a product or service selected by the buyer is settled by means of the above mentioned virtual payment transaction.
  • the systems and the methods according to the invention allow payments in a virtual environment supported by the banks and using the internet, a mobile telecommunications network or other digital technology platforms, without the use of bank cards.
  • the systems according to the invention as business partners of the banks, offer services for the clients of the banks in cooperation with the banks.
  • the solution according to the inventions has the further important features: it provides a quasi anonymity for the clients, e.g. buyers on the internet, it is dynamic in terms of time, and it allows a secure shopping in a virtual environment, typically on the internet or through mobile telecommunications networks, in a physically different way from the use of the conventional banking means, in particular the bank cards.
  • FIG. 1 is a schematic block diagram of the system for effectuating financial transactions in the virtual space, according to the invention
  • - Figures 2. a and 2.b illustrate the schematic block diagrams of two embodiments of the electronic commerce system according to the invention.
  • - Figure 3 is a flow diagram of the method for effectuating financial transactions in the virtual space, according to the invention.
  • FIG. 4 illustrates the steps of the electronic commerce method according to the invention in a topological aspect by presenting message exchanges between a buyer, a vendor and a central clearing unit.
  • Figure 1 illustrates the schematic block diagram of a system 100 for effectuating financial transactions in a virtual environment, according to the invention.
  • each of the users has one or more virtual wallet 110, 112, each of which is associated to a bank account 141 , 143 in a one-to-one relationship.
  • the bank accounts are managed by bank computers 140, 142 of the respective banks 144, 146 of the users.
  • a bank account associated with a virtual wallet 110, 112 is a sub-account of a bank account of the user, wherein said sub-account is established definitely for the purposes of using it in the system according to the invention.
  • the system 100 comprises at least one first pay-on-demand client application 120 that in course of the financial transaction, allows for the owner of a virtual wallet 110 to access to the virtual wallet 110 associated with the bank account to be debited, i.e. in this particular case, the bank account 141 , through a communication interconnection 130.
  • the pay-on-demand client application 120 is a thin client application.
  • the system 100 further comprises at least one second pay-on-demand client application 122 through which, in course of the financial transaction, the owner of the virtual wallet 112 can access to the virtual wallet 112 associated with bank account to be credited, i.e. in this particular case, the bank account 143, through a communication interconnection 132.
  • the first pay-on- demand application 120 and the second pay-on-demand client application 122 can establish a connection with each other through a communication interconnection 131.
  • the pay-on-demand client applications run on computers, but they may be adapted for running on a mobile telephone set, PDA, a game paddle or any other portable device having communications capability.
  • a client application is running on a computer or a public terminal used for this purpose, it is obvious that a plurality of users can access to their virtual wallets through the particular client application.
  • the virtual financial transactions between the virtual wallets 110, 112 are effectuated by a central clearing unit 150 that is capable of communicating with the at least one first pay-on-demand client application 120 through the communication interconnection 130, with the at least one second pay- on-demand client application 122 through the communication interconnection 132 and with the bank computers 140, 142 of the banks 144, 146 through the communication interconnections 134, 136.
  • Said client side communication interconnections 130, 131 , 132 are typically established via the internet, although a landline telephone network, a mobile telephone network, a cable television network, any other digital data transmission system or any combination thereof may be used for this purpose.
  • the bank side communication interconnections 134, 136 are formed of dedicated lines of high security, but wired telephone lines may also be used for them.
  • the central clearing unit 150 communicates with the client applications 120, 122 through a client communication interface 151 , while as with bank computers 140, 142 through a bank communication interface 152.
  • the one-to-one relationships between the virtual wallets 110, 112 and the associated bank accounts 141 , 143 are stored within the central clearing unit 150 in a data storage means 155, preferably in a data base.
  • the central clearing unit 150 further comprises a processing unit 153 for managing the balances of the virtual wallets 110, 112 in response to instructions received from the at least one first pay-on-demand client application 120, the at least one second pay-on-demand client application 122 and the at least one bank computer 140, 142.
  • the processing unit 153 fills up the virtual wallets from the respective bank accounts 141, 143; it carries over a given amount from those to the respective bank accounts 141 , 143; and in the course of the virtual financial transactions, it effectuates the debiting or crediting actions with respect to the virtual wallets 110, 112 participating in the transaction. Operation of the processing unit 153 will be introduced in detail later on.
  • Figures 2. a and 2.b the schematic block diagram of an internet shopping system 200 based on virtual payment is illustrated that uses the virtual payment system described above.
  • components illustrated in Figures 2. a and 2.b which are also shown in Figure 1 are referred to by the same reference numbers as shown in Figure 1.
  • the system 200 comprises at least one web application 160 allowing a first user playing the role of a buyer to select a product or service to be merchandized in electronic way, and at least one web server 162 for operating the web pages including the products and/or services that can be electronically purchased.
  • each of the products and/or services has a web page where a virtual payment may be initiated with respect to a product or service selected by the buyer.
  • the communication interconnection 133 between the web application 160 and the web server 162 is established via the internet.
  • the pay-on-demand application 120 of the first user i.e.
  • the buyer, and the web application 160 both run on the same computing device 121 (illustrated with dashed line in Figures 2.a-b), such as a computer connected to the internet. It is obvious, however, that the two buyer side applications may run even on two different devices; for example the pay-on-demand client application 120 may run on a computer, whereas the web application 160 may run on a mobile telephone set, although in this case an additional communication line is to be provided between the two different devices.
  • the pay-on-demand client application 120 of the buyer and the pay-on-demand client application 122 of the vendor communicates with each other through an intermediate web service. Accordingly, in one embodiment of the system 200 in question, as illustrated in Figure 2. a, the pay-on-demand client application 120 of the buyer establishes a connection with the pay-on-demand client application 122 of the vendor through the buyer side web application 160 and the web server 162 operating the web pages of the vendor. The communication interconnection 133 between the web application 160 and the web server 162 is established via the internet. In an other embodiment of the system 200 (not shown in the drawings), the pay-on-demand client application 120 of the buyer establishes a direct connection with the web server 162, and communicates with the merchant side pay-on-demand client application 122 therethrough.
  • the system 200 may also be configured in such a way, that there is no pay-on-demand client application 122 installed for the merchant.
  • integration of the merchant may be carried out in a more efficient way, however, the merchant can effectuate several orders of magnitude less financial transaction through the central clearing unit 150 since the system of the merchant should authenticate every financial transaction separately (for example by using digital signature) for the central clearing unit 150.
  • operation of the virtual wallets will be described in detail.
  • POD Payment-On-Demand
  • a merchant type virtual wallet is used only in electronic applications, like in the system 200 shown in Figures 2.a-b, for a "merchant" user, i.e. a user merchandizing his products or services online.
  • a "merchant" user i.e. a user merchandizing his products or services online.
  • the users i.e. typically the users participating in the electronic commerce as buyers, or the users participating in other virtual financial transactions, e.g. in a money transfer between virtual wallets, have a "non-merchant" type virtual wallet.
  • the non-merchant type virtual wallet should be registered in the POD system by a non-merchant user prior to its use, which can be performed either directly through a pay-on-demand client application being used by himself or through the electronic channels of the bank.
  • the registration may be initiated on the web page of any virtual merchant accepting the virtual wallet by means of an interface adapted for this function.
  • a window on the web page of the merchant may be used for this purpose, wherein upon selecting said window, the user is linked to the official web page of the organization operating the system according to the invention.
  • a non-merchant user can register on this web page, and he can download the pay-on-demand client application for himself from this site.
  • the pay- on-demand client applications are applications each having a unique identifier.
  • each of the pay-on- demand client applications, as well as the user names and the passwords of the users logging in through such applications be identifiable.
  • the user name and the password are provided by the user itself during the registration procedure.
  • the registration may be completed directly by using a pay-on- demand client application previously downloaded or installed on the users computer in any other way, through the user interface of the client application adapted for this purpose.
  • the user receives a unique identification code as a response, that will be automatically stored also in his virtual wallet.
  • the user can access to his virtual wallet at any time by using a web application, e.g. a browser, or a pay-on-demand client application.
  • the user may initiate the registration procedure from the bank side as well, in which case the user communicates with the selected bank through a dedicated electronic channel connecting to the bank.
  • the request is forwarded by the bank to the POD system which, after checking accessibility and validity of the identifiers, generates a long-term POD identification code.
  • This POD identifier is sent by the POD system to the bank which, in turn, forwards it to the user.
  • the pay-on-demand client application may be downloaded by the user from the web page of the POD system or it can be installed on the computer in any other way. The user is allowed to modify the data provided in the registration procedure (e.g. user name, password) on the web page of the POD system or through the user interface of the pay-on-demand client application.
  • the virtual wallet of a non-merchant user is to be activated subsequently to the registration so that it will be capable of effectuating a virtual financial transaction.
  • a non-merchant user can activate his virtual wallet only through a given electronic channel of his bank (e.g. internet, wired telephone line, mobile telephone line, ATM, POS-terminal).
  • a virtual wallet may be filled up from its associated bank account at any time if the bank makes it possible (e.g. e-banking, mobile banking). It is preferred that the financial transactions relating to a virtual wallet are passed to the bank in a collection, preferably once a day, so as to update the balance of the bank account associated with the particular virtual wallet. In this preferred case, there is no online data link between the bank and the POD system.
  • the virtual wallet managed by the POD system and the associated bank account are assigned to each other by a one-to- one relationship by using a numeric identification code. Since besides the POD identification code no other user identifier (e.g. user name, password, transaction code, etc.) used in the POD system is known for the bank, and besides the bank no one else knows the client of which bank a particular user of the POD system is in fact, and which bank account belongs to him, the POD system according to the invention provides a quasi anonymity for the users, which is a feature of particular importance of the system from the point of view of its applicability.
  • a numeric identification code e.g. user name, password, transaction code, etc.
  • a virtual wallet may be a debit based or a credit based wallet.
  • the procedure of filling up is initiated by the user through a predetermined electronic channel of the bank. After identifying oneself towards the bank, the user should enter his POD identification code that is forwarded to the POD system by the bank. Based on the POD identification code received from the bank, the POD system selects the virtual wallet that will be the recipient of the filling up transaction. Together with the POD identification code, the amount of filling up is also forwarded by the bank to the POD system.
  • the POD system One of the important characteristics of the POD system according to the invention is that any user is allowed to fill up the virtual wallet of any other user. To this end, the user performing the filling up procedure should provide the POD identification code of another user as the recipient of the filling up transaction on the bank side, and not his own default POD identification code. In a preferred embodiment of the POD system according to the invention, filling up a virtual wallet through a corresponding electronic channel of the bank may be done even in the case where the user performing the filling up procedure has no own virtual wallet in the POD system.
  • a user can use a credit based virtual wallet in the POD system only in the case where the bank defines a credit line with respect to it. It is preferred that for a credit based virtual wallet any financial transaction can be effectuated only by applying a strong identification.
  • the bank may define a credit line for unrestricted use and/or it may define a separate credit line for product groups (trade credit).
  • a credit based virtual wallet may be used to effectuate financial transactions similarly to the credit cards, but with the restriction that the access to such a virtual wallet can be preferably allowed upon a strong identification.
  • One of the important characteristics of the POD system according to the invention is that it allows to create virtual sub-purses.
  • the user can assign virtual sub- purses to a virtual wallet, i.e. to a main virtual wallet in this case, on the POD system side.
  • a virtual wallet i.e. to a main virtual wallet in this case, on the POD system side.
  • one or more virtual sub-purse may be established, the balance of which is preferably allowed to be both positive and negative.
  • a virtual sub-purse may be filled up only from the respective main virtual wallet, and from a virtual sub-purse, an effective fund may be carried over to a selected bank account only through its main virtual wallet.
  • the processing unit of the central clearing unit of the POD system comprises additional means (typically corresponding program modules) for managing the balances of the virtual sub-purses, for filling up the virtual sub-purses and for carrying over their balances to the respective bank account.
  • Carrying over a fund from a virtual wallet to the associated bank account and settlements between the POD system and the bank may be initiated at any time.
  • the settlements may be done once a day, at a predetermined time or in real time as well.
  • a transaction of carrying over/settlement may be initiated by the user either from the POD system side or the bank side.
  • the fund of the (positive) balance or a portion of the balance of the virtual wallet may be transferred by the user only to the bank account belonging to his virtual wallet.
  • the amount to be carried over should be specified.
  • the user is allowed for the user to preset that the transaction of carrying over from the virtual wallet be effectuated automatically after the expiration of a predetermined inactive period and/or when exceeding a predetermined limit of amount.
  • the user can carry over the balance of his virtual wallet or a portion thereof to his bank account through a given electronic channel of the bank.
  • the POD system stops all debiting transactions being in process and does not allow any further transaction with respect to the particular virtual wallet of the user.
  • the POD system will perform the transaction of carrying out of the entire fund only after that.
  • the fund carried over is credited in the bank account by the bank preferably at the daily settlement or in real time.
  • Termination of a virtual wallet and the associated bank account may be initiated only through a dedicated electronic channel of the bank and it is completed by the bank only if the balances thereof are zero.
  • the balance of the virtual wallet is carried over to the bank account by the POD system automatically.
  • negative balance this information is passed from the POD system to the bank and the bank will carry over the negative balance to the bank account.
  • the virtual wallet and the associated bank account may be actually terminated.
  • the POD system also cancels the POD identification code, which, for security reasons, will not be ever re-used.
  • the transactions in connection with the virtual wallets are stored by the POD system in analytical breakup and preferably once a day, the difference between the actual balance and the balance of the preceding settlement for each virtual wallet is sent to the corresponding bank.
  • the banks receive only data relating to changes in the balances of the virtual wallets and data relating to the charged transaction fees and commissions from the POD system, thus the banks cannot access to any information with respect to the type of the transaction effectuated by the users and to the identity of other users participating in the transaction.
  • a merchant type virtual wallet has the same functions as a non- merchant type virtual wallet has, only the differences of particular relevance will be described hereafter.
  • the technical configuration of the merchant type virtual wallets is made independently of making the commercial systems suitable for cooperation with the POD system. In terms of time, configuration, registration and activation of the merchant type virtual wallets are preferably completed simultaneously with matching the merchants' system to the POD system.
  • the merchant type virtual wallets are registered and activated after making a contract with the bank.
  • the merchants are provided with a unique user name, a freely defined password and a unique POD identification code.
  • the POD system can be operated preferably with a strong identification (for example, by using a hardware key).
  • a strong identification for example, by using a hardware key.
  • the non-merchant users be capable of unambiguously deducing the identity of the merchant from the user name of the merchant.
  • a merchant type virtual wallet which can be accessed to also through a POD client application, has more function relative to a non-merchant type virtual wallet (e.g. transaction reversion, electronic storage of accounts, etc.), although some functions are not supported therein (e.g. transfer of a fund to another virtual wallet).
  • a merchant type virtual wallet is preferably accessible only by a strong identification (e.g. hardware key, token) and a merchant type virtual wallet can participate in a financial transaction only as a recipient.
  • the aggregate prepared by the POD system with respect to a merchant type virtual wallet at the daily settlement and forwarded then to the bank includes not only the credits in the merchant type virtual wallet but also the transaction fees, the commissions and the amounts of the occasionally reversed transactions.
  • each of the users is assumed to have at least one virtual wallet to which he can access through a pay-on- demand client.
  • a bank account is associated with each of the virtual wallets by a on-to-one relationship and the one-to-one mappings between the virtual wallets and the associated bank accounts, i.e. the POD identification codes, are stored in a central clearing unit.
  • a request is sent from a first pay-on-demand client application to a second pay-on-demand client application for debiting a first virtual wallet associated with the first bank account with a specified amount and for crediting said amount in a second virtual wallet associated with a second bank account.
  • the first virtual wallet will play the role of the virtual wallet to be debited, whereas the second virtual wallet will be regarded as the virtual wallet to be credited in the virtual transaction, wherein crediting said amount is requested with respect to the latter one.
  • step S304 the request for effectuating said transaction is forwarded from the second pay-on-demand client application to the central clearing unit.
  • step S306 it is checked whether the requested transaction can be effectuated on the basis of the balance of the first virtual wallet, and if so, the virtual financial transaction is effectuated by the central clearing unit in step S308, wherein the balance of the first virtual wallet is decreased by the specified amount, whereas the balance of the second virtual wallet is increased by the same amount, then in step S310, an acknowledgement message concerning the successful effectuation of the virtual financial transaction is sent from the central clearing unit to at least the second pay-on-demand client application.
  • step S306 If it is determined in step S306 that the requested transaction cannot be effectuated, the balance of the first and the second virtual wallet will be left unchanged in step S312, and then in step S314, a notification regarding the failure to effectuate the virtual financial transaction will be sent from the central clearing unit to at least the second pay-on-demand client application.
  • a request for approval of effectuating the virtual financial transaction initiated by the first pay-on-demand client application is sent from the central clearing unit to the first pay-on-demand client application, and a response including a permission or a prohibition of the effectuation of the virtual financial transaction is sent from the first pay-on-demand client application to the central clearing unit.
  • the content of the approving message received from the first pay-on-demand client is also examined.
  • step S310 an acknowledgement message concerning the successful effectuation of the virtual financial transaction, or in step S314, a notification regarding the failure of effectuation of the virtual financial transaction is sent to both the first pay-on-demand client application and the second pay-on-demand client application.
  • a virtual sub-purses associated with a virtual wallet also referred to as a main virtual wallet, wherein the balances of the virtual sub-purses associated with the main virtual wallets are managed separately.
  • a virtual fund preferably by debiting the main virtual wallet.
  • the entire (positive) balance or a portion of the balance of the virtual sub- purse is carried over through the main virtual wallet to the bank account associated with the main virtual wallet.
  • identification of a financial transaction - typically a virtual payment transaction - is carried out preferably in a dynamic way, i.e. the users should not be identified in each of the transactions due to the pay-on-demand client applications.
  • the internet shopping becomes much more efficient than before, since at the selection of the product to be purchased, the payment may take place in the background even automatically.
  • the virtual payment transaction may be effectuated automatically, once or several times after a predetermined amount of data have been downloaded or a digital content of a predetermined duration has been played, without the need of an additional action of the buyer.
  • a request for effectuating a virtual financial transaction is sent from the first pay-on- demand client application to several second pay-on-demand client applications one after the other, and the virtual financial transaction is effectuated with respect to at least two virtual wallets of those ones associated with the second pay-on-demand client applications receiving the requests.
  • This embodiment of the method may be used advantageously, for example in file sharing systems or in grid computing systems, where between a virtual wallet to be debited and a plurality of virtual wallets to be credited, a plurality of logically depending elementary virtual financial transaction are effectuated automatically.
  • the buyer 400 can pay for the selected product or service on the web page of any merchant 402, which is capable of cooperating with the POD system 404.
  • the counter value of the selected product or service is transferred to the virtual wallet of the merchant 402 by debiting the virtual wallet of the buyer 400 managed by the POD system 404.
  • the virtual payment becomes achievable in such a way that the merchant 402 integrates a module into the virtual commercial space, i.e. into the web page presenting the products or services, said module allowing for the buyer side pay-on-demand (POD) client application to interpret the interaction between the space of the buyer 400 and the commercial space of the merchant 402.
  • a module into the virtual commercial space, i.e. into the web page presenting the products or services, said module allowing for the buyer side pay-on-demand (POD) client application to interpret the interaction between the space of the buyer 400 and the commercial space of the merchant 402.
  • POD buyer side pay-on-demand
  • the buyer 400 can learn, inter alia, the exact name, the identification code, the price or pricing structure thereof (e.g. unit price per time, per size or per piece), as well as other pieces of information required for possible invoicing, like sales tax or other taxes included.
  • This piece of information has a size of at most 1kB since said piece of information should necessarily be forwarded to the POD system 404 as well, if the buyer 400 intends to purchase the product or service.
  • the process of purchase is based on the so called continuous triangulation and proceeds as follows. Basically each of the transactions is effectuated online, in real time.
  • step S410 the buyer 400 logs in to his virtual wallet through his own POD client application.
  • the process of purchase can be initiated only if the buyer 400 is provided with a POD client application, since only such an application is capable of communicating with the system of the merchant 402.
  • the merchant's system determines whether the buyer 400 has an active POD client application. If so, the POD client application of the merchant's system establishes a bilateral connection to the POD client application of the buyer 400. Preferably, this session has a standard format so that the POD system 404 be capable of identifying the buyer 400 on the basis of the information received from the merchant 402.
  • the POD client of the buyer 400 sends a request, in step S412, to the POD client of the merchant 402 through the previously established connection, said request indicating a purchase with debiting the virtual wallet of the buyer 400.
  • step S414 the merchant 402 sends a debit request containing valid identification data of the buyer 400 to the POD system 404, with respect to debiting the virtual wallet of the buyer 400.
  • the buyer 400 may preset that in all cases, his own POD client application should also provide an approval of the purchase (active approval), or it should only watch the debiting transactions without sending an additional approval (passive approval).
  • the POD system 404 sends a request to POD client application of the buyer 400 for the approval of debiting the virtual wallet of the buyer 400.
  • the buyer 400 replies to the POD system 404 by sending a response containing a permission (or a prohibition) of debiting.
  • steps S416 and S418 are omitted or the responses thereto are sent from the POD client application automatically, without an additional interaction of the buyer.
  • Settings with regard to the automatic approval may be stored in the POD system 404 and/or in the POD client application of the buyer 400.
  • the POD client application of the buyer 400 receives a new transaction identifier form the POD system 404 so that the merchant 402 may not be able to initiate a debiting transaction by using the identifiers of the buyer 400, which transactions are not accepted by the buyer 400 either in the passive or in the active manner. Besides the afore-mentioned transaction identifiers, all other identifiers remain constant during the period of the session. If the balance of the virtual wallet of the buyer 400 exceeds the requested amount of debit and no other conditions hinder debiting of the virtual wallet either, the POD system 404 will effectuate the virtual payment transaction, i.e.
  • step S420 the POD system 404 sends a notification to the merchant 402 with respect to the successful effectuation or the refusal of the payment transaction.
  • the notification on the successful effectuation or the refusal of the payment transaction is sent by the POD system 404 to the buyer 400 as well, in step S422.
  • the system of the merchant 402 should allow the use of the paid up product or service, which, for example, in case of providing digital contents or electronic services, may include even the immediate performance thereof.
  • a plurality of requests for a payment transaction is received by the POD system 404 from a plurality of buyers 400 through a particular merchant 402, and according to predetermined conditions, one of the received requests is selected, and finally, the virtual payment transaction is effectuated only between the virtual wallet of the buyer 400 sending the selected request for the payment transaction and the virtual wallet of the merchant 402 offering the particular product or service.
  • This embodiment of the method may be beneficial for the internet auction shoppings.
  • a direct money transfer may be effectuated between the virtual wallets without a payment transaction relating to shopping.
  • the recipient of the money transfer is preferably a user who is registered as a possible recipient after a strong identification in the POD system.
  • a non-merchant user selects another user, by using his POD client application, to whom he intends to transfer money, and he inputs the amount to be transferred. Occasionally, he may also link a notice to the financial transaction, wherein, if required, said notice can be seen only by himself when querying his own transactions.
  • the money transfer transactions are managed by the POD system which informs the banks thereon separately in the settlements prepared for the banks.
  • one or more bank allows for the POD system to send SMS messages to the users in connection with the use of the system.
  • This allows for the POD system to send certain messages (e.g. notifications, settlements, etc.) to the users to their mobile telephone set rather than through the internet, which further increases the security of the system.
  • the bank provides only the infrastructure for the POD system (including storing the mobile telephone numbers of the users), but the content of the SMS messages are generated and assigned to the respective POD identification codes within the POD system.
  • the methods and systems according to the invention may also be applied in other fields of application different from the application fields mentioned above, these other fields including, for example, auction shopping, operating bonus based systems, etc. and such systems do also fall in the scope of the invention.
  • the present invention also relates to a computer program comprising instructions which, when executed in one or more computer or processor device, carries out any one of the methods according to the invention.
  • the invention further relates to a computer program product stored on a computer readable data storage medium comprising instructions which, when executed in one or more computer or processor device, carries out any one of the methods according to the invention.

Landscapes

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

Abstract

The present invention provides a mechanism for effectuating financial transactions in a virtual environment, wherein each of the users has a virtual wallet which is associated 5 with a bank account. A first pay-on-demand client application is used to access to the virtual wallet of the bank account to be debited and a second pay-on-demand client application is used to access to the virtual wallet of the bank account to be credited. The two pay-on-demand client applications are interconnected via a communication link. The bank accounts of the virtual wallets are managed by computers in the banks. 0 The first and the second pay-on-demand client applications and the bank computers communicate with a central clearing unit comprising means for storing the associations between the virtual wallets and the bank accounts, a client communication interface for communicating with the first and second pay-on-demand client applications, a bank communication interface for communicating with the bank computers, and a processing 5 unit for managing the balances of the virtual wallets in response to instructions from the a -on-demand client a lications and the bank com uters.

Description

_ Qdtt ^ i
System, central clearing unit ^method for effectuating financial transactions in a virtual environment, electronic commerce system and method, and computer program product
In general, the present inventions relates to cashless payment systems and methods. More particularly, the present invention relates to a system, a central clearing unit and a method for effectuating financial transactions in a virtual environment, as well as an electronic commerce system and method, and computer program product. Due to the rapid development of the computer techniques and the telecommunications, as well as to spreading of the internet, the services based on cashless payment, in particular the online commerce services, have been used to an increasing extent. Because of the misuses and fraudulences experienced in the initial period of the spreading of the online shoppings carried out through public telecommunications networks, in particular the internet, communication offering as high security as possible has been concerned with even higher priority, mainly in applications where effectuating the transaction required the input of sensitive or secret data, for example bank account numbers, unique secret codes. In the field of electronic commerce and the relating online banking services, several solutions have been elaborated to guarantee a mutual security for the business parties in the financial transactions.
Such a solution is disclosed in the patent HU 223885, that relates to a system, in which the vendor and the buyer are both in connection to his own bank through computing devices connecting via a communication interconnection of directed data channels, and through additional interposed communication devices, and the banks themselves are interconnected with each other through an information retransmission network - in a particular case, with also connecting to a common clearing bank. The advantage of the afore-mentioned solution is that during completing the sale action, it is not necessary to exchange the confident or secret data of the buyer and the vendor for the preparation and the execution of the financial transaction, and additionally, within a short time period prior to the transaction, a mutual verification and authentication may be carried out, which increases the feeling of safety of both the vendor and the buyer to a great extent. A serious drawback of the above mentioned system is that the parties still entrust their own bank directly to effectuate the transaction, which results in a significant amount of extra cost for the clients in case of money transfers of small amount or internet shoppings of small amount. The object of the present invention is to eliminate the drawbacks of the aforementioned systems and other similar systems and to provide a system and a method for effectuating the shoppings or financial transactions of small amount, like money transfers, in an electronic way that incurs lower costs and allows higher efficiency and security than before.
The present invention is based on the recognition that if the transactions of small amount are effectuated in the virtual space, between virtual wallets managed by a separate, independent central clearing unit, rather than between real bank accounts, and the balance of the virtual wallets are carried over to the associated bank accounts only at predetermined times or under predetermined conditions, than the total cost of effectuating of said transactions of small amount will significantly reduce both at the system level and at the user level. Nowadays, the online commerce, in particular the internet shopping, provide several platforms allowing to effectuate financial transactions in the virtual space without the need of a direct participation of banks, but with information and financial co-operation with the banks.
These and other objects are achieved by providing a system for effectuating financial transactions in a virtual environment, wherein each of the users has at least one virtual wallet and each of the wallets is associated with a bank account. The system further comprises at least one pay-on-demand client application adapted for accessing to a virtual wallet associated with a bank account to be debited through a communication interconnection; at least one second pay-on-demand client application adapted for accessing to a virtual wallet associated with a bank account to be credited through a communication interconnection; a communication interconnection between the at least one first pay-on-demand client application and the at least one second pay- on-demand client application; at least one bank computer for managing the bank accounts associated with the virtual wallets; and a central clearing unit communicating with the at least one first pay-on-demand client application, the at least one second pay-on-demand client application and the at least one bank computer.
The central clearing unit comprises means for storing the associations between the virtual wallets and the respective bank accounts; a client communication interface for communicating with the at least one first pay-on-demand client application and the at least one second pay-on-demand client application; a bank communication interface for communicating with the at least one bank computer; and a processing unit for managing the balances of the virtual wallets according to instructions received form the at least one first pay-on-demand client application, the at least one second pay-on- demand client application and the at least one bank computer. The above objects are further achieved by providing an electronic commerce system based on virtual payment, in particular for use in internet shopping, wherein each of the buyers and the users has at least one virtual wallet and each of the wallets is associated with a bank account. The system comprises at least one web application to allow for a buyer to select a product or service to be merchandized electronically; and at least one web server for operating the web pages containing the products and/or services that can be purchased in electronic way; wherein each of the products and/or services has a web page where a virtual payment for a selected product or service may be initiated. This system further comprises at least one pay-on-demand client application adapted for accessing by a buyer to his virtual wallet through a communication interconnection; at least one second pay-on-demand client application adapted for accessing by a merchant to his virtual wallet through a communication interconnection; at least one bank computer for managing the bank accounts associated with the virtual wallets of the buyer and the merchant; and a central clearing unit communicating with the at least one first pay-on-demand client application, the at least one second pay-on-demand client application and the at least one bank computer, said unit forming a component of a system capable of effectuating virtual financial transactions in a virtual environment.
Preferably, the client side communication interconnections are established through the internet, a landline telephone network, a mobile telephone network, a cable television network or other digital data transmission system or any combination thereof.
Preferably, the bank side communication interconnection is established through a landline telephone network, other dedicated data transmission line or a combination thereof. It is preferred that one or more virtual sub-purse is associated with at least one virtual wallet serving as a main virtual wallet, and the processing unit is adapted for managing the balances of the virtual sub-purse belonging to the respective main virtual wallets. In this case it also preferred that that the processing unit further comprises means for filling up a virtual sub-purse with a specified virtual fund by debiting the associated main virtual wallet, and means for carrying over the specified fund from the virtual sub-purse to the bank account associated with the respective main virtual wallet through the main virtual wallet.
In case effectuation of a payment transaction requires an additional approving mechanism, the central clearing unit preferably further comprises means for sending, to the first pay-on-demand client application, a request for approval of effectuating a virtual financial transaction initiated by the first pay-on-demand client application, and for receiving, from the first pay-on-demand client application, a response containing a permission or a prohibition of effectuating the virtual financial transaction.
Preferably, the central clearing unit further comprises means for notifying at least the second pay-on-demand client application, more preferably both the first pay- on-demand client application and the second pay-on-demand client application, regarding the financial transaction effectuated in the virtual space.
The above mentioned objects are also achieved by providing a method for effectuating virtual transactions in a virtual environment, wherein each of the users has at least one virtual wallet. The method comprises the steps of associating the bank account of each virtual wallet, and storing the associations between the virtual wallets and the respective bank accounts; operating at least one pay-on-demand client application adapted for accessing to a virtual wallet; sending a request, from a first pay- on-demand client application to a second pay-on-demand client application, for debiting the virtual wallet associated with the first bank account with a specified amount and for crediting said amount in a second virtual wallet associated with a second bank account; sending a request, from the second pay-on-demand client application receiving the request to a central clearing unit, for effectuating said transaction; checking whether the requested transaction can be effectuated in view of the balance of the first virtual wallet; if the requested transaction can be effectuated, effectuating the virtual financial transaction in the central clearing unit by decreasing the balance of the first virtual wallet by the specified amount and increasing the balance of the second virtual wallet by the same amount; and sending an acknowledgement message from the central clearing unit to at least the second pay-on-demand client application with respect of the successful effectuation of the virtual financial transaction; or if the requested transaction cannot be effectuated, leaving the balances of the first and second virtual wallets unchanged, and sending a notification from the central clearing unit to at least the second pay-on-demand client application with respect to the unsuccessful effectuation of the virtual financial transaction.
From the point of view of the secure operation of the system, it is preferred that the method further comprises the steps of sending a request, from the central clearing unit to the first pay-on-demand client application, for an approval of effectuating the virtual financial transaction initiated by the first pay-on-demand client application; sending a response from the first pay-on-demand client application to the central clearing unit, said response containing either a permission or a prohibition of the effectuation of the virtual financial transaction; and additionally examining the content of the approval message received from the first pay-on-demand client application when checking whether the virtual financial transaction can be effectuated. Preferably the acknowledgement message with respect to the successful effectuation of the virtual financial transaction or the notification with respect to the unsuccessful effectuation of the virtual financial transaction is sent to both the first pay- on-demand client application and the second pay-on-demand client application. If one or more virtual sub-purse is associated with at least one virtual wallet serving as main virtual wallet, it is preferred that the balances of the virtual sub-purses associated with the respective main virtual wallets are managed separately.
Preferably, the virtual sub-purse is filled up with a virtual fund by debiting the main virtual wallet with said fund, and the entire balance of the virtual sub-purse or a portion thereof is carried over to the bank account belonging to the main virtual wallet through the main virtual wallet.
The above objects are further achieved by providing a method of electronic commerce based on virtual payment, in particular for use in internet shopping. The method comprises the steps of: operating at least one web application to allow a buyer to select a product or service to be merchandized in electronic way; operating at least one web server to manage the web pages containing the products and/or services that can be purchased in electronic way, wherein each one of the products and/or services has a web page where a virtual payment may be initiated in connection with the selected product or service. In this method, the counter value of a product or service selected by the buyer is settled by means of the above mentioned virtual payment transaction.
Finally, the above objects are achieved by a computer program and a computer program product stored on a computer readable data storage medium that comprise instructions which, when executed in one or more computer or processor device, carry out any embodiment of the methods according to the invention.
The systems and the methods according to the invention allow payments in a virtual environment supported by the banks and using the internet, a mobile telecommunications network or other digital technology platforms, without the use of bank cards. The systems according to the invention, as business partners of the banks, offer services for the clients of the banks in cooperation with the banks. The solution according to the inventions has the further important features: it provides a quasi anonymity for the clients, e.g. buyers on the internet, it is dynamic in terms of time, and it allows a secure shopping in a virtual environment, typically on the internet or through mobile telecommunications networks, in a physically different way from the use of the conventional banking means, in particular the bank cards.
The invention will now be described in more detail with reference to the drawings. In the drawings: - Figure 1 is a schematic block diagram of the system for effectuating financial transactions in the virtual space, according to the invention;
- Figures 2. a and 2.b illustrate the schematic block diagrams of two embodiments of the electronic commerce system according to the invention; - Figure 3 is a flow diagram of the method for effectuating financial transactions in the virtual space, according to the invention; and
- Figure 4 illustrates the steps of the electronic commerce method according to the invention in a topological aspect by presenting message exchanges between a buyer, a vendor and a central clearing unit. Figure 1 illustrates the schematic block diagram of a system 100 for effectuating financial transactions in a virtual environment, according to the invention. In the system 100, each of the users has one or more virtual wallet 110, 112, each of which is associated to a bank account 141 , 143 in a one-to-one relationship. The bank accounts are managed by bank computers 140, 142 of the respective banks 144, 146 of the users. From the point of view of the system, it is preferred that a bank account associated with a virtual wallet 110, 112 is a sub-account of a bank account of the user, wherein said sub-account is established definitely for the purposes of using it in the system according to the invention. Although there are only two banks illustrated in the drawings, it is obvious that the system 100 may comprise any number of banks. The system 100 comprises at least one first pay-on-demand client application 120 that in course of the financial transaction, allows for the owner of a virtual wallet 110 to access to the virtual wallet 110 associated with the bank account to be debited, i.e. in this particular case, the bank account 141 , through a communication interconnection 130. Preferably, the pay-on-demand client application 120 is a thin client application. The system 100 further comprises at least one second pay-on-demand client application 122 through which, in course of the financial transaction, the owner of the virtual wallet 112 can access to the virtual wallet 112 associated with bank account to be credited, i.e. in this particular case, the bank account 143, through a communication interconnection 132. In the course of the virtual financial transaction, the first pay-on- demand application 120 and the second pay-on-demand client application 122 can establish a connection with each other through a communication interconnection 131.
Typically, the pay-on-demand client applications run on computers, but they may be adapted for running on a mobile telephone set, PDA, a game paddle or any other portable device having communications capability. When a client application is running on a computer or a public terminal used for this purpose, it is obvious that a plurality of users can access to their virtual wallets through the particular client application. In the system 100 according to the invention, the virtual financial transactions between the virtual wallets 110, 112 are effectuated by a central clearing unit 150 that is capable of communicating with the at least one first pay-on-demand client application 120 through the communication interconnection 130, with the at least one second pay- on-demand client application 122 through the communication interconnection 132 and with the bank computers 140, 142 of the banks 144, 146 through the communication interconnections 134, 136. Said client side communication interconnections 130, 131 , 132 are typically established via the internet, although a landline telephone network, a mobile telephone network, a cable television network, any other digital data transmission system or any combination thereof may be used for this purpose. Preferably, the bank side communication interconnections 134, 136 are formed of dedicated lines of high security, but wired telephone lines may also be used for them. The central clearing unit 150 communicates with the client applications 120, 122 through a client communication interface 151 , while as with bank computers 140, 142 through a bank communication interface 152.
The one-to-one relationships between the virtual wallets 110, 112 and the associated bank accounts 141 , 143 are stored within the central clearing unit 150 in a data storage means 155, preferably in a data base. The central clearing unit 150 further comprises a processing unit 153 for managing the balances of the virtual wallets 110, 112 in response to instructions received from the at least one first pay-on-demand client application 120, the at least one second pay-on-demand client application 122 and the at least one bank computer 140, 142. Accordingly, the processing unit 153 fills up the virtual wallets from the respective bank accounts 141, 143; it carries over a given amount from those to the respective bank accounts 141 , 143; and in the course of the virtual financial transactions, it effectuates the debiting or crediting actions with respect to the virtual wallets 110, 112 participating in the transaction. Operation of the processing unit 153 will be introduced in detail later on.
In Figures 2. a and 2.b, the schematic block diagram of an internet shopping system 200 based on virtual payment is illustrated that uses the virtual payment system described above. For the sake of better understanding, components illustrated in Figures 2. a and 2.b which are also shown in Figure 1 , are referred to by the same reference numbers as shown in Figure 1.
The system 200 comprises at least one web application 160 allowing a first user playing the role of a buyer to select a product or service to be merchandized in electronic way, and at least one web server 162 for operating the web pages including the products and/or services that can be electronically purchased. In the system 200, each of the products and/or services has a web page where a virtual payment may be initiated with respect to a product or service selected by the buyer. In the system 200 it is preferred that the communication interconnection 133 between the web application 160 and the web server 162 is established via the internet. In this system typically, the pay-on-demand application 120 of the first user, i.e. the buyer, and the web application 160 both run on the same computing device 121 (illustrated with dashed line in Figures 2.a-b), such as a computer connected to the internet. It is obvious, however, that the two buyer side applications may run even on two different devices; for example the pay-on-demand client application 120 may run on a computer, whereas the web application 160 may run on a mobile telephone set, although in this case an additional communication line is to be provided between the two different devices.
In the system 200, the pay-on-demand client application 120 of the buyer and the pay-on-demand client application 122 of the vendor communicates with each other through an intermediate web service. Accordingly, in one embodiment of the system 200 in question, as illustrated in Figure 2. a, the pay-on-demand client application 120 of the buyer establishes a connection with the pay-on-demand client application 122 of the vendor through the buyer side web application 160 and the web server 162 operating the web pages of the vendor. The communication interconnection 133 between the web application 160 and the web server 162 is established via the internet. In an other embodiment of the system 200 (not shown in the drawings), the pay-on-demand client application 120 of the buyer establishes a direct connection with the web server 162, and communicates with the merchant side pay-on-demand client application 122 therethrough.
As shown in Figure 2.b, the system 200 may also be configured in such a way, that there is no pay-on-demand client application 122 installed for the merchant. Although in this case integration of the merchant may be carried out in a more efficient way, however, the merchant can effectuate several orders of magnitude less financial transaction through the central clearing unit 150 since the system of the merchant should authenticate every financial transaction separately (for example by using digital signature) for the central clearing unit 150. Hereinafter, operation of the virtual wallets will be described in detail. In the systems according to the invention - also referred to as POD (Pay-On-Demand) systems -, a distinction is made between a merchant type virtual wallet and a non- merchant type virtual wallet, depending on the manner of their use. A merchant type virtual wallet is used only in electronic applications, like in the system 200 shown in Figures 2.a-b, for a "merchant" user, i.e. a user merchandizing his products or services online. In all other cases, the users, i.e. typically the users participating in the electronic commerce as buyers, or the users participating in other virtual financial transactions, e.g. in a money transfer between virtual wallets, have a "non-merchant" type virtual wallet.
The non-merchant type virtual wallet should be registered in the POD system by a non-merchant user prior to its use, which can be performed either directly through a pay-on-demand client application being used by himself or through the electronic channels of the bank.
In case of registration of the virtual wallet on the merchant's side, the registration may be initiated on the web page of any virtual merchant accepting the virtual wallet by means of an interface adapted for this function. In a preferred embodiment of the POD system according to the invention, a window on the web page of the merchant may be used for this purpose, wherein upon selecting said window, the user is linked to the official web page of the organization operating the system according to the invention. A non-merchant user can register on this web page, and he can download the pay-on-demand client application for himself from this site. The pay- on-demand client applications are applications each having a unique identifier. From the point of view of security of the system, it is essential that each of the pay-on- demand client applications, as well as the user names and the passwords of the users logging in through such applications be identifiable. In a preferred embodiment of the POD system according to the invention, the user name and the password are provided by the user itself during the registration procedure.
Alternatively, the registration may be completed directly by using a pay-on- demand client application previously downloaded or installed on the users computer in any other way, through the user interface of the client application adapted for this purpose. After the identifiers selected by the user (for example user name, password) have been provided, the user receives a unique identification code as a response, that will be automatically stored also in his virtual wallet. After a successful registration, the user can access to his virtual wallet at any time by using a web application, e.g. a browser, or a pay-on-demand client application. The user may initiate the registration procedure from the bank side as well, in which case the user communicates with the selected bank through a dedicated electronic channel connecting to the bank. After the user has indicated his intention for the registration and provided the required identifiers to be registered through an interface to the bank, the request is forwarded by the bank to the POD system which, after checking accessibility and validity of the identifiers, generates a long-term POD identification code. This POD identifier is sent by the POD system to the bank which, in turn, forwards it to the user. Also in this case, the pay-on-demand client application may be downloaded by the user from the web page of the POD system or it can be installed on the computer in any other way. The user is allowed to modify the data provided in the registration procedure (e.g. user name, password) on the web page of the POD system or through the user interface of the pay-on-demand client application.
The virtual wallet of a non-merchant user is to be activated subsequently to the registration so that it will be capable of effectuating a virtual financial transaction. In a preferred embodiment of the system according to the invention, a non-merchant user can activate his virtual wallet only through a given electronic channel of his bank (e.g. internet, wired telephone line, mobile telephone line, ATM, POS-terminal).
Theoretically, a virtual wallet may be filled up from its associated bank account at any time if the bank makes it possible (e.g. e-banking, mobile banking). It is preferred that the financial transactions relating to a virtual wallet are passed to the bank in a collection, preferably once a day, so as to update the balance of the bank account associated with the particular virtual wallet. In this preferred case, there is no online data link between the bank and the POD system.
In the activation procedure of a virtual wallet, the virtual wallet managed by the POD system and the associated bank account are assigned to each other by a one-to- one relationship by using a numeric identification code. Since besides the POD identification code no other user identifier (e.g. user name, password, transaction code, etc.) used in the POD system is known for the bank, and besides the bank no one else knows the client of which bank a particular user of the POD system is in fact, and which bank account belongs to him, the POD system according to the invention provides a quasi anonymity for the users, which is a feature of particular importance of the system from the point of view of its applicability.
Now various procedures of filling up a virtual wallet with a virtual amount will be described. Depending on the agreement between the user and the bank, a virtual wallet may be a debit based or a credit based wallet.
In case of filling up a debit based virtual wallet, the procedure of filling up is initiated by the user through a predetermined electronic channel of the bank. After identifying oneself towards the bank, the user should enter his POD identification code that is forwarded to the POD system by the bank. Based on the POD identification code received from the bank, the POD system selects the virtual wallet that will be the recipient of the filling up transaction. Together with the POD identification code, the amount of filling up is also forwarded by the bank to the POD system.
One of the important characteristics of the POD system according to the invention is that any user is allowed to fill up the virtual wallet of any other user. To this end, the user performing the filling up procedure should provide the POD identification code of another user as the recipient of the filling up transaction on the bank side, and not his own default POD identification code. In a preferred embodiment of the POD system according to the invention, filling up a virtual wallet through a corresponding electronic channel of the bank may be done even in the case where the user performing the filling up procedure has no own virtual wallet in the POD system.
A user can use a credit based virtual wallet in the POD system only in the case where the bank defines a credit line with respect to it. It is preferred that for a credit based virtual wallet any financial transaction can be effectuated only by applying a strong identification. For a credit based virtual wallet, the bank may define a credit line for unrestricted use and/or it may define a separate credit line for product groups (trade credit). A credit based virtual wallet may be used to effectuate financial transactions similarly to the credit cards, but with the restriction that the access to such a virtual wallet can be preferably allowed upon a strong identification. One of the important characteristics of the POD system according to the invention is that it allows to create virtual sub-purses. The user can assign virtual sub- purses to a virtual wallet, i.e. to a main virtual wallet in this case, on the POD system side. For any one of the main virtual wallets, one or more virtual sub-purse may be established, the balance of which is preferably allowed to be both positive and negative. A virtual sub-purse may be filled up only from the respective main virtual wallet, and from a virtual sub-purse, an effective fund may be carried over to a selected bank account only through its main virtual wallet. The processing unit of the central clearing unit of the POD system comprises additional means (typically corresponding program modules) for managing the balances of the virtual sub-purses, for filling up the virtual sub-purses and for carrying over their balances to the respective bank account.
Carrying over a fund from a virtual wallet to the associated bank account and settlements between the POD system and the bank may be initiated at any time. The settlements may be done once a day, at a predetermined time or in real time as well. A transaction of carrying over/settlement may be initiated by the user either from the POD system side or the bank side. In case of initiating the transaction of carrying over/settlement from the POD system side, the fund of the (positive) balance or a portion of the balance of the virtual wallet may be transferred by the user only to the bank account belonging to his virtual wallet. In case the user does not wish to carry over the entire fund of his virtual wallet to his bank account, the amount to be carried over should be specified.
In a preferred embodiment of the POD system, it is allowed for the user to preset that the transaction of carrying over from the virtual wallet be effectuated automatically after the expiration of a predetermined inactive period and/or when exceeding a predetermined limit of amount.
When the transaction of carrying over/settlement is initiated from the bank side, the user can carry over the balance of his virtual wallet or a portion thereof to his bank account through a given electronic channel of the bank.
In every case where the user wishes to carry over the entire fund from his virtual wallet to his bank account, the POD system stops all debiting transactions being in process and does not allow any further transaction with respect to the particular virtual wallet of the user. The POD system will perform the transaction of carrying out of the entire fund only after that. The fund carried over is credited in the bank account by the bank preferably at the daily settlement or in real time.
In case the user does not wish to requisition the services of the POD system any longer, he has the possibility of terminating the virtual wallet together with the associated bank account. Termination of a virtual wallet and the associated bank account may be initiated only through a dedicated electronic channel of the bank and it is completed by the bank only if the balances thereof are zero. In case the user wishes to terminate a virtual wallet having a positive balance, the balance of the virtual wallet is carried over to the bank account by the POD system automatically. In case of negative balance, this information is passed from the POD system to the bank and the bank will carry over the negative balance to the bank account. Subsequently, the virtual wallet and the associated bank account may be actually terminated. When these means become terminated, the POD system also cancels the POD identification code, which, for security reasons, will not be ever re-used.
The transactions in connection with the virtual wallets are stored by the POD system in analytical breakup and preferably once a day, the difference between the actual balance and the balance of the preceding settlement for each virtual wallet is sent to the corresponding bank. Normally, the banks receive only data relating to changes in the balances of the virtual wallets and data relating to the charged transaction fees and commissions from the POD system, thus the banks cannot access to any information with respect to the type of the transaction effectuated by the users and to the identity of other users participating in the transaction.
Now, the main features of a merchant type virtual wallet will be described. Since in several terms, a merchant type virtual wallet has the same functions as a non- merchant type virtual wallet has, only the differences of particular relevance will be described hereafter.
The technical configuration of the merchant type virtual wallets is made independently of making the commercial systems suitable for cooperation with the POD system. In terms of time, configuration, registration and activation of the merchant type virtual wallets are preferably completed simultaneously with matching the merchants' system to the POD system.
The merchant type virtual wallets are registered and activated after making a contract with the bank. In the POD system, the merchants are provided with a unique user name, a freely defined password and a unique POD identification code. From the side of the merchant's system, the POD system can be operated preferably with a strong identification (for example, by using a hardware key). An additional requirement is that the non-merchant users be capable of unambiguously deducing the identity of the merchant from the user name of the merchant.
A merchant type virtual wallet, which can be accessed to also through a POD client application, has more function relative to a non-merchant type virtual wallet (e.g. transaction reversion, electronic storage of accounts, etc.), although some functions are not supported therein (e.g. transfer of a fund to another virtual wallet). A merchant type virtual wallet is preferably accessible only by a strong identification (e.g. hardware key, token) and a merchant type virtual wallet can participate in a financial transaction only as a recipient.
An occasional carrying over between the merchant type virtual wallet and the merchant's bank account is not allowed since a regular settlement is made every day. The entire fund of the merchant type virtual wallet is credited on the merchant bank account once a day. Accordingly, at an other time or in an other way rather than the regular settlement, the merchant cannot initiate transaction of carrying over between his merchant type virtual wallet and his bank account. The aggregate prepared by the POD system with respect to a merchant type virtual wallet at the daily settlement and forwarded then to the bank includes not only the credits in the merchant type virtual wallet but also the transaction fees, the commissions and the amounts of the occasionally reversed transactions.
Now the method for effectuating a financial transaction in a virtual environment, according to the invention, will be described with reference to Figure 3 which illustrates a flow diagram of the basic steps of the method.
For the execution of the method according to the invention, each of the users is assumed to have at least one virtual wallet to which he can access through a pay-on- demand client.
In step S300, a bank account is associated with each of the virtual wallets by a on-to-one relationship and the one-to-one mappings between the virtual wallets and the associated bank accounts, i.e. the POD identification codes, are stored in a central clearing unit. In step S302, a request is sent from a first pay-on-demand client application to a second pay-on-demand client application for debiting a first virtual wallet associated with the first bank account with a specified amount and for crediting said amount in a second virtual wallet associated with a second bank account. Hence, in this case the first virtual wallet will play the role of the virtual wallet to be debited, whereas the second virtual wallet will be regarded as the virtual wallet to be credited in the virtual transaction, wherein crediting said amount is requested with respect to the latter one.
In step S304, the request for effectuating said transaction is forwarded from the second pay-on-demand client application to the central clearing unit. In step S306, it is checked whether the requested transaction can be effectuated on the basis of the balance of the first virtual wallet, and if so, the virtual financial transaction is effectuated by the central clearing unit in step S308, wherein the balance of the first virtual wallet is decreased by the specified amount, whereas the balance of the second virtual wallet is increased by the same amount, then in step S310, an acknowledgement message concerning the successful effectuation of the virtual financial transaction is sent from the central clearing unit to at least the second pay-on-demand client application.
If it is determined in step S306 that the requested transaction cannot be effectuated, the balance of the first and the second virtual wallet will be left unchanged in step S312, and then in step S314, a notification regarding the failure to effectuate the virtual financial transaction will be sent from the central clearing unit to at least the second pay-on-demand client application.
In a preferred embodiment of the method according to the invention, in a further step, a request for approval of effectuating the virtual financial transaction initiated by the first pay-on-demand client application is sent from the central clearing unit to the first pay-on-demand client application, and a response including a permission or a prohibition of the effectuation of the virtual financial transaction is sent from the first pay-on-demand client application to the central clearing unit. Accordingly, when determining whether the virtual financial transaction can be effectuated (S306), the content of the approving message received from the first pay-on-demand client is also examined.
In a preferred embodiment of the method according to the invention, in step S310, an acknowledgement message concerning the successful effectuation of the virtual financial transaction, or in step S314, a notification regarding the failure of effectuation of the virtual financial transaction is sent to both the first pay-on-demand client application and the second pay-on-demand client application. In an alternative embodiment of the method according to the invention, in a further step one or more virtual sub-purses associated with a virtual wallet, also referred to as a main virtual wallet, wherein the balances of the virtual sub-purses associated with the main virtual wallets are managed separately. At filling up a virtual sub-purse, it is filled up by a virtual fund preferably by debiting the main virtual wallet. Alternatively the entire (positive) balance or a portion of the balance of the virtual sub- purse is carried over through the main virtual wallet to the bank account associated with the main virtual wallet.
After having successfully accessed to a virtual wallet, identification of a financial transaction - typically a virtual payment transaction - is carried out preferably in a dynamic way, i.e. the users should not be identified in each of the transactions due to the pay-on-demand client applications. In this way, for example, the internet shopping becomes much more efficient than before, since at the selection of the product to be purchased, the payment may take place in the background even automatically. For example, in case of downloading a digital content, the virtual payment transaction may be effectuated automatically, once or several times after a predetermined amount of data have been downloaded or a digital content of a predetermined duration has been played, without the need of an additional action of the buyer.
In an alternative embodiment of the first method according to the invention, a request for effectuating a virtual financial transaction is sent from the first pay-on- demand client application to several second pay-on-demand client applications one after the other, and the virtual financial transaction is effectuated with respect to at least two virtual wallets of those ones associated with the second pay-on-demand client applications receiving the requests. This embodiment of the method may be used advantageously, for example in file sharing systems or in grid computing systems, where between a virtual wallet to be debited and a plurality of virtual wallets to be credited, a plurality of logically depending elementary virtual financial transaction are effectuated automatically.
Now the second method according to the invention is described in detail with reference to Figure 4, in which the basic steps of an electronic commerce method based on financial transactions are effectuated in a virtual environment by performing message exchanges between a buyer 400, a merchant 402, and the POD system 404. In the method that will be described below it is assumed that the buyer 400 is provided with a web application, e.g. a web browser, that allows him to learn the products or services to be purchased electronically and therefore presented on the web page of. the merchant 402, and to select any one of the products or services. The web page of the merchant 402 is operated by a web server. In the merchant's system cooperating with the POD system, each of the products and/or services has a web page where a virtual payment can be initiated with respect to the selected product or service.
In a virtual commercial environment, for example at the internet shopping, the buyer 400 can pay for the selected product or service on the web page of any merchant 402, which is capable of cooperating with the POD system 404. The counter value of the selected product or service is transferred to the virtual wallet of the merchant 402 by debiting the virtual wallet of the buyer 400 managed by the POD system 404.
The virtual payment becomes achievable in such a way that the merchant 402 integrates a module into the virtual commercial space, i.e. into the web page presenting the products or services, said module allowing for the buyer side pay-on-demand (POD) client application to interpret the interaction between the space of the buyer 400 and the commercial space of the merchant 402.
When selecting (or pointing by the cursor to) a product or service presented on the web page of a merchant 402, the buyer 400 can learn, inter alia, the exact name, the identification code, the price or pricing structure thereof (e.g. unit price per time, per size or per piece), as well as other pieces of information required for possible invoicing, like sales tax or other taxes included. This piece of information has a size of at most 1kB since said piece of information should necessarily be forwarded to the POD system 404 as well, if the buyer 400 intends to purchase the product or service.
The process of purchase is based on the so called continuous triangulation and proceeds as follows. Basically each of the transactions is effectuated online, in real time.
First, in step S410, the buyer 400 logs in to his virtual wallet through his own POD client application. The process of purchase can be initiated only if the buyer 400 is provided with a POD client application, since only such an application is capable of communicating with the system of the merchant 402.
After the first transaction (e.g. selection of a product or service) in the course of the buyers 400 browsing in the commercial space of the merchant 402, when the merchant 402 is to contact the POD client application of the buyer 400, the merchant's system determines whether the buyer 400 has an active POD client application. If so, the POD client application of the merchant's system establishes a bilateral connection to the POD client application of the buyer 400. Preferably, this session has a standard format so that the POD system 404 be capable of identifying the buyer 400 on the basis of the information received from the merchant 402.
In case the buyer 400, after selecting a product or service, specifies the mode of payment in the commercial space of the merchant 402 as a virtual payment through the POD system, the POD client of the buyer 400 sends a request, in step S412, to the POD client of the merchant 402 through the previously established connection, said request indicating a purchase with debiting the virtual wallet of the buyer 400.
Subsequently, in step S414, the merchant 402 sends a debit request containing valid identification data of the buyer 400 to the POD system 404, with respect to debiting the virtual wallet of the buyer 400.
In an alternative embodiment of the method, the buyer 400 may preset that in all cases, his own POD client application should also provide an approval of the purchase (active approval), or it should only watch the debiting transactions without sending an additional approval (passive approval). In the former case, in step S416, the POD system 404 sends a request to POD client application of the buyer 400 for the approval of debiting the virtual wallet of the buyer 400. In step S418, the buyer 400 replies to the POD system 404 by sending a response containing a permission (or a prohibition) of debiting. Obviously, in case of the passive approval, steps S416 and S418 are omitted or the responses thereto are sent from the POD client application automatically, without an additional interaction of the buyer. Settings with regard to the automatic approval may be stored in the POD system 404 and/or in the POD client application of the buyer 400.
After each debiting transaction, the POD client application of the buyer 400 receives a new transaction identifier form the POD system 404 so that the merchant 402 may not be able to initiate a debiting transaction by using the identifiers of the buyer 400, which transactions are not accepted by the buyer 400 either in the passive or in the active manner. Besides the afore-mentioned transaction identifiers, all other identifiers remain constant during the period of the session. If the balance of the virtual wallet of the buyer 400 exceeds the requested amount of debit and no other conditions hinder debiting of the virtual wallet either, the POD system 404 will effectuate the virtual payment transaction, i.e. it will debit the virtual wallet of the buyer 400 with the specified amount, while crediting said amount in the virtual wallet of the merchant 402. However, if the virtual wallet of the buyer 400 cannot be debited for some reason, the virtual payment transaction will fail and the balance of the respective virtual wallets will remain unchanged.
In step S420, the POD system 404 sends a notification to the merchant 402 with respect to the successful effectuation or the refusal of the payment transaction. In a preferred embodiment of the method, the notification on the successful effectuation or the refusal of the payment transaction is sent by the POD system 404 to the buyer 400 as well, in step S422. Next, in a preferred embodiment of the method, the system of the merchant 402 should allow the use of the paid up product or service, which, for example, in case of providing digital contents or electronic services, may include even the immediate performance thereof. In an alternative embodiment of the electronic commerce method according to the invention, in respect of a particular product or service, a plurality of requests for a payment transaction is received by the POD system 404 from a plurality of buyers 400 through a particular merchant 402, and according to predetermined conditions, one of the received requests is selected, and finally, the virtual payment transaction is effectuated only between the virtual wallet of the buyer 400 sending the selected request for the payment transaction and the virtual wallet of the merchant 402 offering the particular product or service. This embodiment of the method may be beneficial for the internet auction shoppings.
Now some further common features of the methods according to the invention will be described.
Under predetermined security conditions, a direct money transfer may be effectuated between the virtual wallets without a payment transaction relating to shopping. The recipient of the money transfer is preferably a user who is registered as a possible recipient after a strong identification in the POD system. To effectuate a money transfer between the virtual wallets, a non-merchant user selects another user, by using his POD client application, to whom he intends to transfer money, and he inputs the amount to be transferred. Occasionally, he may also link a notice to the financial transaction, wherein, if required, said notice can be seen only by himself when querying his own transactions. The money transfer transactions are managed by the POD system which informs the banks thereon separately in the settlements prepared for the banks.
In a preferred embodiment of the method according to the invention, one or more bank allows for the POD system to send SMS messages to the users in connection with the use of the system. This allows for the POD system to send certain messages (e.g. notifications, settlements, etc.) to the users to their mobile telephone set rather than through the internet, which further increases the security of the system. From a technical point of view, it is important that in order to send an SMS, the bank provides only the infrastructure for the POD system (including storing the mobile telephone numbers of the users), but the content of the SMS messages are generated and assigned to the respective POD identification codes within the POD system.
The methods and systems according to the invention may also be applied in other fields of application different from the application fields mentioned above, these other fields including, for example, auction shopping, operating bonus based systems, etc. and such systems do also fall in the scope of the invention.
For the sake of simplicity, the above embodiments of the systems and methods according to the invention have been described usually in terms of their normal operating modes, however, for a person skilled in the art it, is obvious from the description, what else means or measurements may be used to manage the fault operation of those systems or methods.
The present invention also relates to a computer program comprising instructions which, when executed in one or more computer or processor device, carries out any one of the methods according to the invention. The invention further relates to a computer program product stored on a computer readable data storage medium comprising instructions which, when executed in one or more computer or processor device, carries out any one of the methods according to the invention.

Claims

We claim:
1. A system for effectuating financial transactions in a virtual environment, wherein each of the users has at least one virtual wallet (110, 112), characterized in that
- each of the wallets (110, 112) is associated with a bank account (141 , 143), and
- said system (100) further comprising: - at least one pay-on-demand client application (120) adapted for accessing to a virtual wallet (110) associated with a bank account (141) to be debited through a communication interconnection (130);
- at least one second pay-on-demand client application (122) adapted for accessing to a virtual wallet (112) associated with a bank account (143) to be credited through a communication interconnection (132);
- a communication interconnection (131 ) between the at least one first pay-on-demand client application (120) and the at least one second pay-on- demand client application (122);
- at least one bank computer (140, 142) for managing the bank accounts (141 , 143) associated with the virtual wallets (110, 112); and
- a central clearing unit (150) communicating with the at least one first pay-on-demand client application (120), the at least one second pay-on- demand client application (122) and the at least one bank computer (140, 142), said central clearing unit (150) comprising: - means (155) for storing the associations between the virtual wallets (110, 112) and the respective bank accounts (141, 143);
- a client communication interface (151) for communicating with the at least one first pay-on-demand client application (120) and the at least one second pay-on-demand client application (122); - a bank communication interface (152) for communicating with the at least one bank computer (140, 142); and
- a processing unit (153) for managing the balances of the virtual wallets (110, 112) according to instructions received form the at least one first pay-on-demand client application (120), the at least one second pay-on-demand client application (122) and the at least one bank computer (140, 142).
2. The system of claim 1, characterized in that the client side communication interconnections (130, 131 , 132) are established through the internet, a landline telephone network, a mobile telephone network, a cable television network or other digital data transmission system or any combination thereof.
3. The system of claim 1 or 2, characterized in that the bank side communication interconnection (134, 136) is established through a landline telephone network, other dedicated data transmission line or a combination thereof.
4. A central clearing unit for the system according to any one of claims 1 to 3, said central clearing unit (150) having a communication interconnection with at least one first pay-on-demand client application (120), at least one second pay-on-demand client application (122) and at least one bank computer (140, 142), characterized in that said unit further comprises: - means (155) for storing the associations between the virtual wallets (110, 112) and the respective bank accounts (141 , 143);
- a client communication interface (151) for communicating with the at least one first pay-on-demand client application (120) and the at least one second pay-on- demand client application (122); - a bank communication interface (152) for communicating with the at least one bank computer (140, 142); and
- a processing unit (153) for managing the balances of the virtual wallets (110, 112) according to instructions received form the at least one first pay-on-demand client application (120), the at least one second pay-on-demand client application (122) and the at least one bank computer (140, 142).
5. The central clearing unit of claim 4, characterized in that
- one or more virtual sub-purse is associated with at least one virtual wallet (110, 112) serving as a main virtual wallet, and - the processing unit (153) is adapted for managing the balances of the virtual sub-purse belonging to the respective main virtual wallets.
6. The central clearing unit of claim 4 or 5, characterized in that said processing unit (153) further comprises: - means for filling up a virtual sub-purse with a specified virtual fund by debiting the associated main virtual wallet, and - means for carrying over the specified fund from the virtual sub-purse to the bank account associated with the respective main virtual wallet through the main virtual wallet.
7. The central clearing unit of any one of claims 4 to 6, characterized in that the unit further comprises means for sending, to the first pay-on-demand client application, a request for approval of effectuating a virtual financial transaction initiated by the first pay-on-demand client application (120), and for receiving, from the first pay- on-demand client application (120), a response containing a permission or a prohibition of effectuating the virtual financial transaction.
8. The central clearing unit of any one of claims 4 to 7, characterized in that the unit further comprises means for notifying at least the second pay-on-demand client application (122), but preferably both the first pay-on-demand client application (120) and the second pay-on-demand client application (122), regarding the financial transaction effectuated in the virtual space.
9. The system of any one of claims 1 to 3, in particular for use in internet shopping, characterized in that, the system (200) further comprises: - at least one web application (160) for selecting a product or service to be merchandized electronically; and
- at least one web server (162) for operating the web pages containing the products and/or services that can be purchased in electronic way, wherein each of the products and/or services has a web page where a virtual payment for a selected product or service may be initiated; and
- wherein the communication interconnection (131) between the first and the second pay-on-demand client applications (120, 122) is established through the web application (160), the web server (162) and the communication interconnection (133) therebetween.
10. The system of claim 9, characterized in that the web application (160) is a web browser.
11. The system of claim 9 or 10, characterized in that the communication interconnection (133) between the web application (160) and the web server (162) is established through the internet.
12. A method for effectuating virtual transactions in a virtual environment wherein each of the users has at least one virtual wallet, characterized in that said method comprises the steps of:
- associating the bank account of each virtual wallet, and storing the associations between the virtual wallets and the respective bank accounts (S300);
- operating at least one pay-on-demand client application adapted for accessing to a virtual wallet;
- sending a request, from a first pay-on-demand client application to a second pay-on-demand client application, for debiting the virtual wallet associated with the first bank account with a specified amount and for crediting said amount in a second virtual wallet associated with a second bank account (S302);
- sending a request, from the second pay-on-demand client application receiving the request to a central clearing unit, for effectuating said transaction (S304);
- checking whether the requested transaction can be effectuated in view of the balance of the first virtual wallet (S306);
- if the requested transaction can be effectuated, effectuating the virtual financial transaction in the central clearing unit (S308) by decreasing the balance of the first virtual wallet by the specified amount and increasing the balance of the second virtual wallet by the same amount; and sending an acknowledgement message from the central clearing unit to at least the second pay-on-demand client application with respect of the successful effectuation of the virtual financial transaction (S310); or
- if the requested transaction cannot be effectuated, leaving the balances of the first and second virtual wallets unchanged (S312), and sending a notification from the central clearing unit to at least the second pay-on-demand client application with respect to the unsuccessful effectuation of the virtual financial transaction (S314).
13. The method of claim 12, characterized in that the method further comprises the steps of:
- sending a request, from the central clearing unit to the first pay-on-demand client application, for an approval of effectuating the virtual financial transaction initiated by the first pay-on-demand client application,
- sending a response from the first pay-on-demand client application to the central clearing unit, said response containing either a permission or a prohibition of the effectuation of the virtual financial transaction, and - additionally examining the content of the approval message received from the first pay-on-demand client application when checking whether the virtual financial transaction can be effectuated.
14. The method of claim 12 or 13, characterized in that the acknowledgement message with respect to the successful effectuation of the virtual financial transaction or the notification with respect to the unsuccessful effectuation of the virtual financial transaction is sent to both the first pay-on-demand client application and the second pay-on-demand client application.
15. The method of any one of claims 12 to 14, characterized in that the method further comprises the steps of associating one or more virtual sub-purse with at least one virtual wallet serving as main virtual wallet, and managing the balances of the virtual sub-purses associated with the respective main virtual wallets separately.
16. The method of any one of claims 12 to 15, characterized in that the method further comprises the steps of filling up a virtual sub-purse with a virtual fund by debiting the main virtual wallet with said fund, and carrying over the entire balance of the virtual sub-purse or a portion thereof to the bank account belonging to the main virtual wallet through the main virtual wallet.
17. The method of any one of claims 12 to 16, characterized in that the method further comprises the steps of:
- sending a request for effectuating a virtual financial transaction from the first pay-on-demand client application to a plurality of second pay-on-demand client applications one after the other, and
- effectuating the virtual financial transaction in respect of at least two virtual wallets among those belonging to the second pay-on-demand client applications that received the request.
18. A method of electronic commerce based on virtual payment, in particular for use in internet shopping, the method comprises the steps of: - operating at least one web application to allow a buyer to select a product or service to be merchandized in electronic way;
- operating at least one web server to manage the web pages containing the products and/or services that can be purchased in electronic way, wherein each one of the products and/or services has a web page where a virtual payment may be initiated in connection with the selected product or service, characterized in settling the counter value of a product or service selected by the buyer by means of a virtual payment transaction with executing the steps of the _
25 method of any one of claims 12 to 17, wherein the amount of payment is debited in the virtual wallet of the buyer, while said amount is credited in the virtual wallet of the vendor of the selected product or service.
19. The method of electronic commerce of claim 18, characterized in that the method further comprises the steps of:
- receiving a plurality of requests for payment transaction with respect to a particular product or service;
- according to predetermined conditions, selecting one of the incoming requests; and
- effectuating the virtual payment transaction for the virtual wallet of the buyer that has sent the selected payment transaction and the virtual wallet of the user merchandizing the particular product or service.
20. Computer program product stored on a computer readable data storage medium, characterized in that it comprises instructions which, when executed in one or more computer or processor device, carry out the method of any one of claims 12 to 17.
PCT/HU2008/000077 2007-06-29 2008-06-27 System, central clearing unit and method for effectuating financial transactions in a virtual environment, electronic commerce system and method, and computer program product WO2009004393A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
HU0700450A HU227651B1 (en) 2007-06-29 2007-06-29 System and method of virtual financial transactions, electronic sale system and method, as well as computer program and computer program product
HUP0700450 2007-06-29

Publications (1)

Publication Number Publication Date
WO2009004393A1 true WO2009004393A1 (en) 2009-01-08

Family

ID=89987617

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/HU2008/000077 WO2009004393A1 (en) 2007-06-29 2008-06-27 System, central clearing unit and method for effectuating financial transactions in a virtual environment, electronic commerce system and method, and computer program product

Country Status (2)

Country Link
HU (1) HU227651B1 (en)
WO (1) WO2009004393A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130054470A1 (en) * 2010-01-08 2013-02-28 Blackhawk Network, Inc. System for Payment via Electronic Wallet
US11676140B2 (en) 2020-06-17 2023-06-13 Capital One Services, Llc System and method for facilitating transfer of electronic payment information

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11250393B2 (en) 2018-11-09 2022-02-15 Visa International Service Association Rapid transaction settlement using virtual account

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1396805A1 (en) * 2001-06-11 2004-03-10 Sony Corporation Electronic money system
US6873974B1 (en) * 1999-08-17 2005-03-29 Citibank, N.A. System and method for use of distributed electronic wallets
US7096494B1 (en) * 1998-05-05 2006-08-22 Chen Jay C Cryptographic system and method for electronic transactions

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7096494B1 (en) * 1998-05-05 2006-08-22 Chen Jay C Cryptographic system and method for electronic transactions
US6873974B1 (en) * 1999-08-17 2005-03-29 Citibank, N.A. System and method for use of distributed electronic wallets
EP1396805A1 (en) * 2001-06-11 2004-03-10 Sony Corporation Electronic money system

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130054470A1 (en) * 2010-01-08 2013-02-28 Blackhawk Network, Inc. System for Payment via Electronic Wallet
US11676140B2 (en) 2020-06-17 2023-06-13 Capital One Services, Llc System and method for facilitating transfer of electronic payment information

Also Published As

Publication number Publication date
HU227651B1 (en) 2011-10-28
HUP0700450A2 (en) 2009-03-30
HU0700450D0 (en) 2007-08-28

Similar Documents

Publication Publication Date Title
US10984403B2 (en) Systems and methods for brokered authentification express seller links
US8924299B2 (en) Method and system for facilitating payment transactions using access devices
US8010453B2 (en) Method and system for facilitating payment transactions using access devices
RU2438172C2 (en) Method and system for performing two-factor authentication in mail order and telephone order transactions
US20070266131A1 (en) Obtaining and Using Primary Access Numbers Utilizing a Mobile Wireless Device
US20090292619A1 (en) Method for universal electronic payment processing
US20020103753A1 (en) Charge splitter application
US8494962B2 (en) Method and system for secure mobile remittance
CA2557329A1 (en) Transaction system
WO2001035304A9 (en) On-line payment system
US20140258106A1 (en) Payment system, purchasing system, and method for performing a plurality of payment processes
JP2004503018A (en) System and method for managing micropayment processing, and corresponding client terminal and retailer device
CN110088790A (en) Merchant registration for reverse payments
KR20040002928A (en) Micropayment system
WO2009004393A1 (en) System, central clearing unit and method for effectuating financial transactions in a virtual environment, electronic commerce system and method, and computer program product
RU2277723C2 (en) Method for reliable preparation and reliable realization of financial calculation related to sales transaction between purchaser and seller
RU2295771C1 (en) Method for realizing electronic transactions
KR20020073887A (en) A purchasing Method for Goods on the internet by Prior Settlement Way
KR20100061623A (en) System for finance trade using game money and method thereof
KR20080099840A (en) System for e-billing by using virtual mobile devices
KR20070020318A (en) Method for e-billing by using Virtual Mobile Devices
KR20080087053A (en) System and method for providing loan service for creditor object and program recording medium
CA2546433A1 (en) Obtaining and using primary access numbers utilizing a mobile wireless device

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08776243

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION NOT DELIVERED. NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112 EPC (EPO FORM 1205A DATED 10.05.2010)

122 Ep: pct application non-entry in european phase

Ref document number: 08776243

Country of ref document: EP

Kind code of ref document: A1