HU227651B1 - System and method of virtual financial transactions, electronic sale system and method, as well as computer program and computer program product - Google Patents

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

System and procedure for executing financial transactions in virtual environment, electronic sales system and procedure, computer program and computer program rooms

Applies to the procedures found. More particularly, the present invention relates to a system and method for executing financial transactions in a virtual environment, an electronic sales system and method, and a computer program and computer program product.

Due to the rapid development of computing and telecommunications and the spread of the Internet, non-cash commercial services, primarily on-line, are becoming increasingly widespread. Abuses and frauds in the early stages of on-llne purchases on public telecommunication networks, especially the Internet, have begun to increase the focus on safer communication, especially for applications where sensitive or sensitive data such as bank account numbers are unique to the transaction. secret nebulae are required. In the field of e-commerce and related on-line banking services, a number of solutions have been developed to ensure the mutual security of business partners in conducting financial transactions.

such a solution is disclosed, inter alia, in Hü 223885, which relates to a system in which a seller and a buyer are connected to their own bank through their interconnected computing devices and other interconnected communication devices, and banks are linked to one another through an information exchange network, possibly connected to a public settlement bank. The advantage of this solution is that the preparation and execution of the financial transaction does not require the exchange of the buyer's and the artist's confidential or secret information, and that a mutual control and authentication can be implemented in the short term prior to the transaction, which greatly increases the sense of security for both the seller and the buyer. However, the serious disadvantage of this system is that the customers execute the transaction fc * * »*

W fcfc continues to outsource directly to their own bank, which is a significant additional cost for customers, especially for low-value transfers or low-value online purchases.

It is an object of the present invention to overcome the drawbacks of the aforementioned system and other similar systems and to provide a system and a procedure that allows for the purchase of an amount or other financial transactions, e.g. more efficient and secure electronic transfer of remittances, at a lower cost than before.

The present invention has led to the discovery that, when executing virtual transactions between virtual wallets managed by a separate, independent central accounting entity instead of real bank accounts, the virtual wallet balance is transferred to the virtual wallet only at specific times or under certain conditions. bank accounts, the total cost of conducting such a lump sum transaction can be significantly reduced both at system level and at the level of individual users. Online commerce, especially Internet shopping, now provides a number of platforms that allow for financial transactions in the virtual world without the direct involvement of banks, but in IT and financial cooperation with banks.

On the one hand, these objectives are achieved by implementing a system for executing financial transactions in a virtual environment, wherein each user has at least one virtual wallet that stores a virtual balance and each virtual wallet is assigned to a bank account. The system includes at least one first pey ~ on ~ demand client application that allows access to a virtual wallet belonging to a debit account via a client-side communication link; at least one second pay-on-demand client application that allows access to a virtual wallet belonging to a beneficiary's bank account via a client-side communication link; at least one banking computer that manages virtual wallet bank accounts; and a central clearing unit associated with the at least one first paymn-demand client application, the at least one second pay-on-demand client application, and the at least one banking computer.

«4« * ♦ *

The central accounting unit shall comprise at least the following tools: · a means for storing mappings between virtual wallets and their associated bank accounts; a client-side 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-side communication interface for communicating with the at least one banking computer; and a processing unit for managing virtual wallet balances based on instructions from at least one first pay-nn ~ domand client application, at least one second pay-on-demand client application, and at least one banking computer.

On the other hand, the objectives are achieved by implementing a virtual payment based electronic sales system that is particularly advantageous for online shopping, in which each customer and merchant has at least one virtual wallet, each virtual wallet being associated with a bank account and storing a virtual balance. The system includes at least one web application that allows the customer to select a product or service to be sold electronically; at least one web server for operating web pages containing products and / or services that can be purchased electronically, wherein each product and / or service includes a web page for initiating virtual payment for the selected product or service; at least one first pay-on-demand client application allowing the customer to access his virtual wallet via a client-side communication link; at least one second pay-on-demand client application that enables the merchant to access his virtual wallet via a client-side communication link; at least one banking computer for managing bank accounts belonging to the buyer's and merchant's virtual wallets; and a central clearing unit associated 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 banking computer bank communication link capable of executing a financial transaction in a virtual environment. is part of the system.

The client-side communication link is preferably via the Internet, a landline telephone network, a cellular telephone network, a cable television network, or any other digital data transmission system, or any combination thereof.

A. Bank-to-bank communications are preferably through a fixed telephone network, other dedicated data line, or a combination thereof.

Preferably, at least one virtual wallet - as a virtual wallet - is associated with one or more virtual sub-wallets, and the processing unit is configured to manage virtual wallet balances associated with virtual wallets. In this case, the processing unit preferably comprises a device for replenishing the virtual wallet with a specified amount of virtual money from its corresponding virtual wallet and transferring a specified amount from the virtual wallet to the bank account of the corresponding virtual wallet through the virtual wallet device.

Where the execution of a payment transaction is subject to special authorization, the central clearing unit shall conveniently include a request for permission from the first psy-on-demand client application to send and receive a virtual financial transaction initiated by the first pay ~ on ~ demand client application a means to receive or deny a response to a virtual financial transaction.

The central clearing unit preferably includes at least a second pay-on-dernand client application for a financial transaction in virtual space, but preferably a first pay-on-demand client application and a second pay-on-dema /? D client application. notification tool.

The objects are further achieved by a method of executing financial transactions in a virtual environment in which each user has at least one virtual wallet. The point of the procedure is to assign a bank account to each virtual wallet and store the mappings between the virtual wallets and their associated bank accounts; storing a virtual balance in each virtual wallet; operating at least one pay ~ on ~ demand client application through which virtual wallets can be accessed; we send a request from a first pay ~ oa ~ demand client application to debit a first virtual wallet belonging to a first bank account for a specified amount and to credit that amount to a second virtual wallet belonging to a second bank account

pay-on-demand client application; sending, on the second pey-on-dema.no 'client application, a request for execution of said transaction to a central clearing unit; examining whether the balance of the first virtual wallet is capable of executing the requested transaction; if the requested transaction is executed, performing a - virtual financial transaction with the central clearing unit, by reducing the balance of the first virtual wallet by the amount specified and increasing the balance of the second virtual wallet by the same amount; and sending a message from the central clearing unit confirming successful completion of the virtual financial transaction to at least the second pay-or-~ dema /? d client application; if, on the other hand, the requested transaction cannot be executed, leaving the balance of the first and second virtual wallets unchanged and sending the central clearing unit notification of the failure of the virtual financial transaction to at least the second pay-omdemand client application.

It is advantageous for the secure operation of the system that, as a further step of the process, sending an override request from the central clearing unit to execute a virtual financial transaction initiated by the first pay-on-demand client application to the first pay-oo-demand client application; sending a response to the central clearing unit from the first pay-on-demaad client application allowing or denying the execution of the virtual financial transaction; and examining the content of the overlay message received from the first pay-on-demarcation client application when examining the feasibility of the virtual financial transaction.

Preferably, a message confirming the successful execution of the virtual financial transaction and a notification of the unsuccessful execution of the virtual financial transaction are sent to both the first pey-ondemand client application and the second pay-on-demo client application.

If one or more virtual wallets are associated with at least one virtual wallet as a virtual wallet, the balances of the virtual wallets belonging to the virtual wallet are preferably treated separately.

When uploading a virtual wallet, it is advisable to fill the virtual wallet with the virtual wallet and the virtual * *.

χχ «All or part of your Wallet Balance should preferably be transferred to your Virtual Wallet bank account via your virtual wallet.

Further, the objects are achieved by a virtual payment based e-commerce process, in particular an online shopping operation, comprising operating at least one web application that allows a customer to select a product or service to be electronically sold; operating at least one web server for managing web pages containing electronically purchased products and / or services, wherein each product and / or service includes a web page for initiating virtual payment for the selected product or service; and the payment for the product or service selected by the buyer is settled through the aforementioned virtual payment transaction

Finally, the objects are achieved by implementing a computer program or computer program product stored on a computer readable data storage medium which includes instructions executed on one or more computers or processor devices to implement any of the methods of the invention.

The systems and methods of the present invention are provided in a bank-supported virtual environment such as the Internet, mobile telecommunications networks, other digital technology platforms, and the like. make non-credit card painting possible. Other important features of the solution of the invention are to ensure quasi-anonymity for customers, such as Internet shoppers, from time-to-time and from traditional banking devices - especially from credit cards. ~ physically separable, secure shopping in a virtual environment, typically over the Internet and mobile telecommunications networks,

The invention will now be described in more detail with reference to the drawing. In the drawing:

Figure 1 is a block diagram of a system for executing financial transactions in virtual space according to the invention;

Figures 2a and 2b are block diagrams of two possible embodiments of an electronic sales system according to the invention;

* »* X

Figure 3 is a flowchart of a method for executing financial transactions in accordance with the invention in virtual space; and

Figure 4 illustrates the steps of the electronic sales process of the present invention in the form of a message exchange between a buyer, a merchant and a central clearing unit.

Figure 1 is a block diagram of a system 100 capable of executing financial transactions in a virtual environment according to the invention. In system 100, each user has one or more virtual wallets 110, 112, each of which is mutually unambiguously assigned to a bank account 141, 143. Bank accounts are managed by users 'own 144, 146 banks' 140, 142 banking computers). It is advantageous for the system that a bank account belonging to a virtual wallet 110, 112 is a sub-account belonging to a bank current account of a user, which is created specifically for use in the system. Although two banks are shown in the drawing, it is obvious that any of the hare banks can participate in the 100 system. System 100 includes at least one of the first pay-on-demend client applications 120 that allows a debit bank account, in this case virtual wallet 110, to be debited to the owner of the virtual wallet 110 over a communication link 130; through, the 120 pay-on-demand client application is preferably a thin client application,

System 100 also includes at least one second pay-ondernand client application 122 that enables the payee bank account, in this case, the virtual wallet 112 belonging to the bank account 143, to be accessed by the owner of the virtual wallet 112 via a communication link. across. During the virtual payment transaction, the first pay-on-d & maed client application 120 and the second pay-on-diamond client application 122 are able to establish a communication link 131.

Pay-on-demand client applications typically run on a computer, but can also be run on a mobile phone, PDA, game console or other portable communication device. If a client application is run on a computer or a public terminal for this purpose , it is obvious that multiple users can access their own virtual wallets through a given client application.

In the system 100 of the present invention, virtual financial transactions between virtual wallets 110, 112 are executed by a central clearing unit 150 that communicates via communication link 130 with at least one first pay-omdemo client application 120, and via communication link 132 with at least one a second pay-on-demand client application 122 may further establish communication with banks 140, 142 via banks 144, 146 via communication links 134, 138. The aforementioned client-side communication links 130, 131, 132 are typically made over the Internet, but may include a fixed telephone network, a cellular telephone network, a cable television network, other digital data transmission system, or any combination thereof. The communication links 134, 138 on the bank side are preferably made of highly secure, dedicated lines, but may also be landline telephone lines. The central clearing unit 150 communicates with client applications 120, 122 via a client-side communication interface 151, while the banking computer 140, 142 communicates with a client-side communication interface 152.

The central accounting unit 150 stores mutually unambiguous mappings between the virtual wallets 110, 112 and their respective bank accounts 141, 143 in a data storage device 155, preferably a database. The central accounting unit 150 further comprises a processing unit 153 which has at least based on instructions received from a first pay-omo'emand client application 120, at least one second pay-on-dernand client application 122, and at least one of the banking computers 140, 142, manages the balance of virtual wallets 110, 112, transfers from the appropriate 141, 143 bank accounts, transfers a given amount from them to the respective 141, 143 bank accounts and performs debits and credits on the 1 Multiple, 112 virtual wallets participating in the transaction. The operation of the processing unit 153 will be described in further detail below.

Figures 2a and 2b show a block diagram of a virtual payment system 2ÖÖ based on the virtual payment system φ * «X« presented above. For the sake of clarity, of the elements shown in Figure 2a and Figure 2b, the elements shown in Figure 1 are also designated by the reference numerals in Figure 1.

The system 200 includes at least one web application 180 which enables the first user in the role of buyer to select the product or service to be sold electronically, and at least one web server 182 which is a web page containing products and / or services that can be purchased electronically. to operate. In the 200 system, each product and / or service has a web site where virtual payment can be initiated for the product or service selected by the customer. In system 200, communication links 133 between the ISO web application and the web server 162 are preferably provided over the Internet. In the system in question, the first user, that is, the client pay-oodemand client application 120 and the web application 160, typically heats on the same computing device 121, such as a computer connected to the Internet, denoted by a dashed line in Figures 2a-b. However, it is obvious that said two receiver applications can run on up to two different devices; the 12Q pay-oo-demand client application on a computer, for example, and the 180 web application on a mobile phone device, for example, but in this case a communication line must also be provided between the two different devices.

In system 200, the application of the buyer 120 pay-on-demand client and the application of the merchant 122 psy-on-demand client communicate with each other via a webservlce. Accordingly, in one embodiment of the system 200 shown in FIG. 2a, the application of the buyer pay-on-hand client 120 to the merchant payer 122 establishes a connection through the buyer-side web application 180 and the web server 182 that operates the merchant's web pages. using an ondemand client. The communication link 133 between the web application 180 and the web server 182 is established over the Internet. In another version of system 200 - not shown in the drawing - the client 12Q pay-ondemand client application establishes a direct connection to a web server 182 and communicates with the merchant-side pay-on-demand client application 122.

As shown in Figure 2b, system 200 can also be configured without installing 122 pay ~ on ~ demand client applications at the merchant. Although in this case the merchant integration can be done more efficiently, the merchant ♦ * · * β *

X «« * ♦ ♦ ♦ χ «* can execute fewer payment transactions through the central accounting unit 150, since the merchant's system must authenticate each payment transaction separately (eg with a digital signature) to the central accounting unit 150.

Here's how virtual wallets work. In the systems of the invention, hereinafter referred to as Pay-On-Demand (POO) systems, a distinction is made between merchant and non-merchant virtual wallets. The merchant's virtual wallet is exclusively for. 2.a-b in the case of e-commerce use, for example, in relation to the merchant user, that is, the user who sells the goods or services online. In all other cases, that is typically involved in transfers between the participating buyer users, and other virtual financial transaction, such as a virtual wallet users' non-kefeskedő ^w have virtual wallet of electronic commerce.

Before using a non-merchant virtual wallet, the non-merchant user must register with the PÖD system, which can be done either directly through his / her pay-on-defoand client application or via the bank's electronic channels.

When registering a virtual wallet on a merchant site, registration can be started from any virtual merchant web site accepting a virtual wallet through a dedicated interface. In a preferred embodiment of the POD system according to the invention, a window placed on the merchant's web site is provided for this purpose and the user selects it on the official web site of the organization operating the system according to the invention. The non-merchant user can register on this web site and download the pay-ondemand client application from here. Pay-on-demand client applications are applications with unique identifiers. It is essential for the security of the system that you are able to identify each pay-on-demand client application and the username and password of the users logged on through it. In a preferred embodiment of the POO system of the invention, the user name and password are provided by the user himself upon registration,

Registration can also be done directly from the POD system's homepage with the pay ~ on ~ d & mand client previously downloaded or otherwise installed on the user's machine.

Φ ♦ · is is is x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x

After entering the user-selected identifiers (eg username, password), the user receives a unique identification code in response, which is automatically saved in his / her virtual wallet. After successful registration, the user can access his / her virtual wallet at any time through a web application, eg. browser program or a pay-oa-demaad client application.

The user can also start the registration from the banking site, in which case he / she communicates with the bank via a dedicated electronic channel providing connection to the bank of his / her choice. After the user has indicated his registration request and provided the required registrant identifiers in one of the bank clerks, the bank forwards the request to the PÖD system, which, after checking the availability and validity of the identifiers, generates a permanent POD identification code. , which forwards it to the user.

In this case, the pay-on-demaart client application can be downloaded from the POD web site or otherwise installed on your computer. The user can change the information (eg username, password) provided during registration at any time via the PÖD system web site or through the pay-o.o-demand client application interface.

The non-merchant's virtual wallet must be activated after registration in order to be able to execute a virtual financial transaction. In a preferred embodiment of the system according to the invention, the non-retail user can activate his / her virtual wallet only through a specific electronic channel of his / her bank (eg Internet, landline, mobile telephone line, ATM, POS terminal).

In principle, a virtual wallet can be recharged at any time from its associated bank account, provided that the bank does so. However, by collecting the virtual wallet financial transactions, it is advisable to transfer them to the bank once a day to modify the balance of the virtual wallet bank account. Thus, it is expedient that there is no on-line data connection between the bank and the PÖD system.

Jf fc * «» *

During the virtual wallet activation process, the virtual wallet managed by the POD system and its associated bank account are clearly assigned to each other using a numeric identification code.

As no other user ID (eg username, password, transaction codes, etc.) used in the POD system is known to the bank other than the FOD identification code, and no other user of the POD system is known to the bank. In fact, which bank's customer and bank account it belongs to, the POD system of the present invention provides users with quasi-anonymity, which is an extremely important feature of using the system.

Here's how to fill your virtual wallet with virtual money. The virtual wallet may be debit-based or credit-based, depending on the agreement between the user and the bank.

When debit-based virtual wallet is popped up, the user initiates the upload process through a specific electronic channel of the bank. Once the user has identified himself / herself to the bank, he / she must enter the POD identification code which the bank will forward to the POD system. The POD system selects the virtual wallet to be the beneficiary of the reload transaction based on the POD identification code received from the bank. The bank also sends the recharge amount along with the POD identification code to the POD system.

An essential feature of the POD system of the present invention is that any user has the ability to upload another user's virtual wallet. To do this, the uploading user will need to enter the POD ID of another user on the bank's page, not their own default POD ID, as the beneficiary of the upload. In a preferred embodiment of the POD system according to the invention, a virtual wallet can be recharged via the bank's respective electronic channel even if the user making the recharge does not have its own virtual wallet in the POD system.

A credit based virtual wallet can only be used by the user in the POD system if the bank establishes a credit line for it. In the case of a credit-based virtual wallet, it is advisable to carry out any financial transaction only with strong identification. The bank may define a freely available credit line for a credit-based virtual wallet and / or establish a line of credit (merchandise) for specific items. A credit-based virtual wallet may be used to perform financial transactions similar to credit cards, provided that access to such a virtual wallet is expedient. can only be enabled after strong authentication.

An essential feature of the POD system of the present invention is that it provides the ability to create virtual sub wallets. In this case, you can assign a virtual wallet to a virtual wallet - you can assign virtual wallets to the POD system page. One or more virtual sub-wallets can be created for any virtual wallet, for which both positive and negative balances are expedient. You can only replenish your virtual sub-wallets or transfer the actual amount of money from the virtual sub-wallets to the appropriate bank account via the virtual sub-wallet. The central processing unit of the POD system includes separate tools (typically suitable program modules) for managing the balance of the virtual sub-wallets, for replenishing the virtual sub-wallets and for transferring the balance to the corresponding bank account.

You can initiate transfers or settlements from your virtual wallet to its bank account between the POD system and the bank at any time. Settlement can be done once a day at a predetermined time or in real time.

The clearing / settlement transaction can be initiated by the user from the POO system page or from the bank page. When initiating a VAT tracking / clearing transaction from the POD system, the (positive) balance of the virtual wallet or a part of the balance can only be transferred by the user to the bank account of the virtual wallet. If the user does not wish to transfer the entire amount in the virtual wallet to his / her bank account, he / she must specify the amount to be transferred,

A preferred embodiment of the POD system allows the user to configure the virtual wallet to automatically migrate after a predetermined period of inactivity and / or above a predetermined amount.

When initiating the transfer / settlement from the bank's side, the user knows through a specific electronic channel of the bank the "* ί * '* **'" * 'ί "" "" "" "" ··>

♦ ♦ ♦ * »« «« »» ♦♦ balance or part of your virtual wallet to your bank account

In all cases where the user wishes to transfer the entire amount from his / her virtual wallet to his / her bank account, the POD system will terminate any ongoing debit transactions and will not allow any further debit transactions for the user's virtual wallet. Only then will the POD system perform the actual transfer of the total amount. A. The bank should credit the transferred amount to the bank account either daily or in real time.

If the user no longer wishes to use the services of the POD system, he / she may terminate the virtual wallet and the corresponding bank account. The cancellation of a virtual wallet and its associated bank account can only be initiated through a dedicated electronic channel of the bank and will only be executed by the bank if both have a balance of zero. If the user wishes to cancel a virtual wallet with a positive balance, the POD system will automatically transfer the balance to the bank account. In the event of a negative balance, this information will be transferred from the POD system to the bank and the bank will provide for the transfer of the negative balance to the bank account. After that, the virtual wallet and its associated bank account can indeed be terminated. Upon termination of these devices, the POD system will also delete the POD identification code, which will no longer be reassigned for security reasons,

Virtual wallet transactions are analytically stored by the POD system and are preferably passed to the appropriate bank once a day for each virtual wallet balance relative to the previous settlement. Normally, banks will only receive data from the POD on changes in the balance of each virtual wallet, as well as the transaction fees and commissions charged, so that they will not have access to any information about the type of transactions that users make and the other users involved in the transactions,

Here are the main features of a merchant's virtual wallet. Because a merchant virtual wallet has many of the same features as a non-merchant virtual wallet, only the most important differences are described below.

* · '* <.

«« Φ

The technical development of merchant virtual wallets is done independently of making the merchant systems interoperable with the POD system, but in time, the creation, registration and activation of the merchant virtual wallets, preferably in parallel with the integration of the merchant system into the POD system

Merchant virtual wallets are registered ^ and activated following a contract with the bank. In the POD system, merchants are given a unique username and an optional password and unique POD identification code. From the merchant system's point of view, the POD system can be operated with strong authentication (eg using a hardware key). It is also a requirement that non-trader users can clearly infer the trader's identity from the trader's username.

A merchant's virtual wallet, also available through a POD client application, has more functionality than a non-merchant's virtual wallet (eg, transaction reversal, electronic storage of accounts, etc.), while certain features are not available (e.g., money transfer) to another virtual wallet). Merchant virtual wallets are preferably accessed with strong identification (eg, hardware key, token) and merchant virtual wallets can only participate in financial transactions as a payee.

Occasional transfers between the merchant's virtual wallets and the merchant's bank account are not allowed, that is, they are settled daily. The entire amount in the merchant's virtual wallet will be credited to the merchant's bank account once a day. Thus, the merchant cannot initiate a transfer transaction between the merchant's virtual wallet and bank account other than regular settlement. In addition to the credit to the merchant's virtual wallet, the total amount sent by the POD system to the banks for merchant virtual wallets in the course of daily clearing includes, among other things, transaction fees, commissions, and the amount of any reverse transactions.

In the following, the method according to the invention for executing financial transactions in a virtual environment will be described with reference to Figure 3, which shows a flowchart showing the main steps of the process.

«E χ χ ♦ ·» ♦ χχ «« «χχ« «« «· ♦« ♦ *

Μ »Χ X» XX «X«

In carrying out the process of the present invention, it is assumed that each user has at least one virtual wallet accessible through a pay ~ on ~ demand client.

In step S300, a bank account is mutually unambiguously assigned to each virtual wallet and the mutually unambiguous mappings between the virtual wallets and their associated bank accounts, i.e., the PCD identification code, are stored in a central accounting unit.

In step 8302, a request is made from a first pay ~ on-d & mar? D client application to debit a first virtual wallet belonging to a first bank account for a specified amount and to credit that amount in a second virtual wallet belonging to a second bank account. application. In this case, the first virtual wallet in the virtual transaction will act as the virtual wallet to be debited, and the second virtual wallet will be the beneficiary's virtual wallet, for which we will be asked to credit the amount.

In step S3Ü4, the request to execute said transaction from the second pay-on-d & maad client application is forwarded to the central clearing unit.

In step 8306, we examine whether the first virtual wallet balance can be used to perform the requested transaction, and if so, in step 8308, we execute the virtual financial transaction with the central clearing unit, reducing the amount of the first virtual wallet by the amount specified increasing the amount of the second virtual wallet by an amount, and in step 8310, sending a message from the central clearing unit confirming the successful execution of the virtual financial transaction to at least the second pay ~ on ~ d & mand client application.

If it is determined in step S308 that the requested transaction cannot be executed, in step 8312, the balance of the first and second virtual wallets is left unchanged, and in step 8314, the central clearing unit is notified of the failure of the virtual financial transaction. pay-on-demano client application.

In a preferred embodiment of the method according to the invention, a further step is to send an override request from the central clearing unit to execute a virtual financial transaction initiated by the first pay-self-demand client application. sending a response to the central clearing unit for the first pay-on-demand client application, and then for the first pay-on-demand client application to allow or disallow the execution of the virtual financial transaction. Accordingly, when examining the feasibility of a virtual financial transaction (S3Ö8), the content of the over-authorization message received from the first pay-on-demand client application is also examined.

In a preferred embodiment of the method of the invention, a confirmation message of successful execution of the virtual financial transaction in step S310 and a notification of unsuccessful execution of the virtual financial transaction in step -S314 to the first pay-on-demand client application and the second payon-demand client application we send you both,

In one embodiment of the method of the present invention, a further step is to associate at least one virtual wallet - as a virtual wallet - with one or more virtual sub wallets, wherein the balances of the virtual wallets belonging to the virtual wallets are treated separately. When a virtual wallet is broken, the virtual wallet is expediently charged to the virtual wallet, or the entire (positive) balance of the virtual wallet is transferred to the virtual wallet account through the virtual wallet,

After accessing virtual wallets, financial transactions are typically virtual payment transactions - preferably identified dynamically, which eliminates the need for pay-on-denwjd client applications to identify users per transaction. This way, for example, online shopping becomes much more efficient than before, as you can even pay automatically in the background when you choose the product you want to buy. For example, in the case of downloading digital content, a virtual payment transaction may occur several times automatically when a certain amount of data is downloaded, after a certain amount of time during digital content playback, without the customer having to take specific action.

In one embodiment of the first method of the invention, the first pay-ondemand client application is successively sending a plurality of different second pay-ondemand client applications a virtual financial transaction request and at least one of the virtual wallets belonging to the second pay-on-dem & nd client applications receiving the requests we execute a virtual financial transaction for two of them. This variant of the method can be advantageously used, for example, in file-sharing systems or gricf computing systems, where several logically related elementary virtual payment transactions are automatically executed between a virtual wallet to be debited and several different virtual wallets,

The second method of the present invention will now be described in detail with reference to FIG. 4, which illustrates the main steps of an online financial transaction based financial transaction in a virtual environment through message exchange between a receiver 40, a merchant 402 and a POD system 404. In the procedure described herein, it is assumed that the receiver 400 has a web application, e.g. a web browser that allows you to discover the products or services you want to sell electronically on the merchant's 402 website and to select a product or service. The web site of the merchant 402 is hosted by a web server In merchant systems working with the POD system, each product and / or service includes a web site where virtual payment can be initiated for the selected product or service.

When shopping in a virtual trading environment, such as the Internet, the buyer 400 can pay for selected products or services on all 402 merchant websites that can interact with the POD 404 system. The value of the selected product or service is transferred from the buyer 400 to the virtual wallet managed by the POD system 404 and to the virtual wallet of the merchant 402.

Virtual payment is made available by integrating a 402 merchant into the virtual vendor space, a web site containing products and services, that makes it possible for the buyer-side pay-of? ~ Atemartd (POD) client application to understand Interaction between buyer 4 and dealer 402 sales space.

By selecting (or pointing to the cursor) the product or service shown on merchant site 402, customer 400 will find out, among other things, its exact name, identification code, price, and pricing structure (e.g., time, size, or unit price) other information, e.g. sales tax, other tax content. This information should preferably be up to 1kB as this information will also need to be transmitted to the POD 404 system ♦ ♦ * «» if the 400 customers decide to purchase the product or service,

Purchasing is the so called. is based on the principle of continuous triangulation and is implemented as follows. By default, all transactions are made online in real time.

First, in step S41, the receiver 400 logs into its virtual wallet through its own POD client application. The purchase process can only be started if the receiver 400 has a POD client application, since only such an application can communicate with the merchant system 402.

After the first transaction (e.g., selecting a product or service), when the buyer 400 browses the merchant's shopping area 402, when the merchant 402 needs to contact the buyer POD client 400, the merchant system checks whether the buyer 400 has any. active POD client application. If so, the trading system's POD client application is two-way: it builds a connection with the 400 buyer POD client. This relationship (sess / cf?) Is preferably in standard format so that, based on information received from dealer 402, the POD system 404 can identify the receiver 400.

If the 400 customers after selecting the product or service:

Specify virtual payment through the POD system in the vendor space of 402 merchants, and in step -S412, the PÖD client of the buyer 400 sends a request to the \ ht virtual wallet of the buyer 400 to apply the application of the merchant's POD client 402 through a previously established connection .

Thereafter, in step S4i4, the merchant 402 sends a debit request containing valid identification information of the customer 400 to the POD system 404 to the debit of the virtual wallet of the customer 400.

In one variant of the procedure, the 4ÖÖ receiver can pre-set whether to confirm the purchase confirmation (active approval) through its own PÖD client or to monitor debit transactions (passive approval) without specific approval. In the former case, the POD system 404, in step S416, queries the request to use the receiver PÖD client 400 to accept the debit of the receiver 400 virtual wallet. In step S418, the receiver 400 sends the load enable (or deny) response to the PÖD system 404. Obviously, passive approval

steps S416 and S418 are either not executed or responded to from the PÖD client application, without the need for any interaction with the receiving user. Auto Approval settings may be stored in the POÖ 404 system and / or in the application of the 400 receiver POD client.

Applying the client POD client 400 after each load transaction receives a new transaction identifier from the POD system 404 to prevent merchant 402 from initiating load transactions using the 4,000 receiver identifiers that were not accepted by the client 400 even passively. , even in an active way. All identifiers other than the transaction IDs mentioned above are constant during the sess / on Time.

If the balance of the customer's virtual wallet exceeds the amount of the requested debit and other factors prevent the debit of the virtual wallet, the POD system 404 will execute the virtual payment transaction, i.e., debit the customer's virtual wallet with the amount specified, merchant in virtual wallet. However, if for some reason the virtual wallet of the 400 customers cannot be charged, the virtual payment transaction will fail and the balance of the starched purses will remain unchanged. Upon successful execution or rejection of the payment transaction, the POD system 404 notifies the merchant 402 at step S420. In a preferred embodiment of the procedure, the POD system 404 notifies the receiver 400 in step S422 of the successful execution or rejection of the payment transaction.

Subsequently, in a preferred embodiment of the procedure, the merchant's system 402 must permit the use of a paid product or use of a service, which may include instant service for digital content or electronic services, for example.

In one embodiment of the electronic sales process of the present invention, a payment transaction request is also received from a plurality of 400 customers for a given product or service through a POD 404, and one of the insertion requests is selected based on predetermined conditions, executing the selected payment transaction request for the virtual wallet of the 400 buyers and the virtual wallet of the 402 merchants selling the product or service. This version of the procedure can be used advantageously primarily in online auction purchasing systems.

Hereinafter, some other common features of the methods of the invention will be described

There is a direct way of transferring money between virtual wallets, subject to certain security requirements, without the need for a purchase-related payment transaction. The transfer beneficiary should preferably be a user who has been added by the FÖD system to the potential beneficiaries with strong identification. When transferring between virtual wallets, a non-merchant user uses the FÖD client application to select the user to whom he / she wants to transfer and gives the amount to be transferred. If necessary, you can also add a note to the financial transaction, which, upon request, can only be seen by you when you query your own transactions. Remittance transactions are accounted for in the POD system and separately recorded in the accounts with banks.

In a preferred embodiment of the methods of the present invention, one or more banks allow the FOD system to send users SMS messages related to the use of the system. In this way, it is possible for the POD system to provide users with certain messages, such as notifications for settlements, sfb. send it to users' mobile phones instead of the Internet, which further increases system security. It is technically important that the bank provides the POD system with the infrastructure for sending SMS (including the storage of the mobile phone number of the users), but the content of the SMS is generated within the POD system and assigned to the corresponding FOD identification code.

The systems and methods of the present invention may also be used in a variety of other applications than those described above, such as auction buying, operation of bonus-based systems, etc., and such systems or methods are also within the scope of the invention.

For the sake of simplicity, the variants of the systems and methods of the present invention are generally described herein for purposes of simplicity, but it will be readily apparent to those skilled in the art what means or measures may be employed to malfunction in each system or process.

í

Λ. I * * * * ♦ '* 4 »<0 0 0 * 0 * 0 0 0 0 0« 0 ♦ 00 * 0 Χ00 0 * 0 * * «000 0XX« »00 χχ X

The invention also includes a computer program comprising instructions executed on one or more computers or processor devices to execute any method of the invention. Also included in the invention is a computer program product stored on a computer-readable data storage medium and containing instructions executed in one or more computers or processor devices in accordance with any of the methods of the invention.

Claims (24)

Claims A system for executing financial transactions in a virtual environment, wherein each user has at least one virtual wallet (110,112), characterized in that - each virtual wallet (110, 112) is associated with a bank account (141, 143) and stores a virtual balance, and the system (100) includes - at least one first pey-an-demaed client application (120) allowing access to a virtual wallet (110) belonging to a debit bank account (141) via a client-side communication link (130); - at least one second pay-on-demand client application (122) allowing access to a virtual wallet (112) belonging to a beneficiary bank account (143) via a client-side communication link (132); - at least one banking computer (140, 142) for managing bank accounts (141, 143) associated with virtual wallets (110, 112); and - at least one first pay-o / Mfemand client application (120), at least one second pay-on-demand client application (122) and at least one banking computer (140, 142) on a bank-side communication link (134, 136). a central clearing unit (150) associated with said at least one of said means; - a means (155) for storing mappings between virtual wallets (110. 112) and associated bank accounts (141, 143); a client-side 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 banking computer (140, 142); and - virtual wallets (110) based on instructions received from at least one first pay-on-demand client application (120), at least one second pay-on-demand client application (122) and at least one banking computer (140, 142); 112) a processing unit for managing its balance (153). «« »T w« «** ♦» »*> * *« ♦ ♦ Φ «♦ ♦ t> ♦ <* ♦ ♦ ♦ fr '* * <- 9t *** ♦» »« «« The system of claim 1, wherein said client-side communication links (130, 132) are provided over the Internet, a landline telephone network, a cellular telephone network, a cable television network, or other digital data transmission system, or any combination thereof. System according to claim 1 or 2, characterized in that the bank-side communication link (134,136) is provided over a fixed telephone network, other dedicated data transmission line, or a combination thereof. 4. A system according to any one of claims 1 to 3, characterized in that - associated with at least one virtual wallet (110, 112) as a virtual wallet, one or more virtual sub-wallets, and - the processing unit (153) is adapted to manage the balances of the virtual sub-wallets belonging to the virtual master wallets. 5. System according to any one of claims 1 to 3, characterized in that the processing unit (153) - a device for replenishing a virtual wallet with a specified amount of virtual money from the corresponding virtual wallet, and - a means for transferring a specified amount from the virtual wallet to the bank account of its respective virtual wallet through the virtual wallet. 6. A system according to any one of claims 1 to 5, wherein the central clearing unit (150) has an authorization request from the first pay-on-demand client application (120) to execute a virtual financial transaction initiated by the first pay-on-demo client application (120). the sender and the receiving device either accepting or denying a virtual financial transaction. 7. System according to any one of claims 1 to 3, characterized in that the central clearing unit (150) has at least a second psy-on-demand client application (122) for the financial transaction in virtual space, but preferably the first psy-omdemand client application (120) and and means for notifying a second pay-ondemand client application (122). 8. Virtual payment electronic sales system (2o), especially for online shopping, where each buyer and merchant has at least one virtual wallet (110,112), characterized in that: each virtual wallet (110, 112) is assigned to a bank account (141, 143) and stores a virtual balance, and the system (200) includes - at least one web application (160) allowing the customer to select a product or service to be sold electronically; - at least one web server (162) for operating web pages containing products and / or services that can be purchased electronically, wherein each product and / or service includes a web page that has at least a first pay- virtual payment for the selected product or service; an on-demand client application (120) allowing the customer to access his virtual wallet (110) via a client-side communication link (130); At least one second pay ~ or? Demand client application (122) allowing the merchant to access his virtual wallet (112) via a client-side communication link (132); - at least one banking computer (140,142) for managing bank accounts (141, 143) associated with the buyer's and merchant's virtual wallets (110, 112); and - at least one first pay-on-diamond client application (120), at least one second pay-on-demand client application (122) and at least one banking computer <140, 142) on a bank-side communication link (134, 136). a central accounting unit (150) associated with said system, comprising at least the following means: - a means (155) for storing mappings between virtual wallets <110, 112} and associated bank accounts 143); X »χ ♦ ♦« «Μ • χ χ» • »9 ♦ X * ** Φ Χ Χ» φ iens ~ client-side communication interface (151) of at least one of the first payon- communicating with the demaob client application (120) and the at least one second pay-onfema / wf client application (122); a bank-side communication interface (152) for communicating with the at least one banking computer (140, 142); and - based on instructions from at least one first pay-on-e / emand client application (120), at least one second pay-on-de.mand client application (122) and at least one banking computer (140, 142); a processing unit (153) for managing the wallet balance (110, 112). The system of claim 8, wherein the web application (180) is a web browser program The system of claim 8 or S, wherein the client-side communication link (130, 132/433} over the Internet, landline, cellular network, cable television or other digital data transmission system, or any combination thereof. through System according to any one of claims 3 to 10, characterized in that the bank-side communication link (134, 133} is established over a fixed telephone network, other dedicated data transmission line, or a combination thereof. System according to any one of claims 8 to 11, characterized in that - at least one virtual wallet (110, 112) is associated with one or more virtual wallets as a virtual wallet, and - the processing unit (153) is adapted to manage the balances of the virtual wallets belonging to the virtual wallets. 13. 3-12. System according to any one of claims 1 to 3, characterized in that the processing unit (153) - a device for replenishing the virtual wallet with a specified amount of virtual money from the corresponding virtual wallet, and »* X» ♦ # ♦ 9 · '* «X« Χχχ 9 9 V 9 9 9 9 9 X »* * '♦ XX 9 9 9 9 9 - transfer a specified Amount through the virtual master wallet to a bank account belonging to the corresponding virtual wallet 14. In Figures 8-13. A system according to any one of claims 1 to 6, characterized in that the central clearing unit (150) requests an override request for the use of the customer pay-oo-omand client (120) to execute a virtual financial transaction initiated by the application of the customer's psy-on-demand client (120). the sender and the receiving device either accepting or denying a virtual financial transaction. 15. System according to any one of claims 1 to 3, characterized in that the central clearing unit (150) uses at least the merchant pay-on-tandem client application (122) for the financial transaction in virtual space, but preferably the merchant pay-on-demaed client application (122). and means for notifying the customer of the application (120) of the pay-on-diamond client. 18. A method for executing financial transactions in a virtual environment, wherein each user has at least one virtual wallet, characterized in that: - assigning a bank account to each virtual wallet and storing mappings between the virtual wallets and their associated bank accounts (8380); ~ storing a virtual balance in each virtual wallet; - operating at least one pay-o / bdamancf client application through which virtual wallets can be accessed; - requesting a second pay-ondernand client application (8302) to charge a first virtual wallet from a first pay-on-demand client application to the first virtual wallet belonging to a first bank account and to credit that amount to a second virtual wallet belonging to a second bank account; - sending a request to a central clearing unit (8304) to execute said transaction from the second pay-or-end client application receiving the request; • fcfcfc. fcfc fcfc «fc * fc fc fc fc X fcfc * fc fc fcfcfc« X X * * * fc fc fcfc ·· * fcfc · * fcfc fc - examining whether the requested transaction can be executed based on the balance of the first virtual wallet (S308); - if the requested transaction is executed, performing the virtual financial transaction (S3Ö8) with the central clearing unit, by reducing the amount of the first virtual wallet by the amount specified and increasing the amount of the second virtual wallet by the same amount; and sending a message from the central clearing unit confirming the successful execution of the virtual financial transaction to at least the second pay ~ on ~ d & mand client application (S310); if, however, the requested transaction cannot be executed, leaving the balance of the first and second virtual wallets unchanged (S312) and notifying the central clearing unit of the failure to execute the virtual financial transaction to at least the second pay-on ~ demo client application (S314) . The method of claim 16, further characterized. to take another step - sending an unconditional request from the central clearing unit for executing the virtual financial transaction initiated by the first psy-on-demo client application to the first pay-on-demand client application, - sending from the first pay-o.o-demand client application a response to the Central Clearing Unit allowing or denying the execution of the virtual financial transaction, and - when examining the feasibility of a virtual financial transaction, the content of the over-authorization message received from the first pay-on-demand client application is also examined. 13. A The method of claim 18 or 17, wherein the message confirming the successful execution of the virtual financial transaction or the notification of the unsuccessful execution of the virtual financial transaction is sent to both the first pay ~ oa ~ damaad client application and the second pay-omdemand client application. . 19. A 16, -18. A method according to any one of claims 1 to 6, characterized in that at least one virtual wallet, as a virtual wallet, is associated with one or more virtual wallets, the balances of the virtual wallets belonging to the virtual wallets being treated separately. fcfc * »♦ * ·« «*« «» »*« it «« «Μ» «*« K »φτΚ lf * χ« * »8 * V 0 ** '* Μ * ♦ * φφ ψ 20. Α 16.-19. A method as claimed in any one of claims 1 to 4, characterized in that, when the virtual sub-wallet is overpaid, the virtual sub-wallet is charged to the virtual wallet with a virtual sum, and all or part of the virtual sub-wallet balance is transferred from the virtual wallet to the main bank. 21. A 16-20. A process according to any one of claims 1 to 3, characterized in that sending successive requests for virtual financial transactions from the first pay-on-demand client application to a plurality of different second pay-on-demand client applications; and performing a virtual financial transaction for at least two of the second wallet of the second pay-on-dernand client applications receiving the requests. 22. A procedure for virtual payment based electronic sales, in particular for online shopping, in which - operating at least one web application that allows a customer to select a product or service to be sold electronically; - operating at least one web server that manages web pages containing products and / or services that can be purchased electronically, wherein each product and / or service has a web page on which virtual payment can be initiated for the selected product or service, the payment for the product or service selected by the buyer is settled by a virtual payment transaction in accordance with Figs. 16, -21. The steps of the method of any one of claims 1 to 6, wherein the amount payable is debited to the buyer's virtual wallet and to the benefit of the seller of the selected product or service's virtual wallet 23. The electronic selling method of claim 22, wherein: - receiving multiple payment transaction requests for a particular product or service; «/ 9 ♦ ♦ ♦ ** * · ♦ *» ♦ »* * * Vtt '♦' · φ * ♦ * ♦ X * * X> C «« φ «Φ φΚ M - selecting one of the nested requests based on predefined conditions; and - we execute the virtual payment transaction only with respect to the virtual wallet of the buyer sending the selected payment transaction request and the virtual wallet of the user selling the given product or service. 24. A computer program comprising instructions that are executed on one or more computers or processor devices in accordance with claims 16 to 23. A method according to any one of claims 1 to 6. 25. A computer program product stored on a computer-readable data storage medium comprising instructions executed on one or more computers or processor devices in accordance with claims 16 to 23. A method according to any one of claims 1 to 6.