DE69622594T2 - Method and system for performing electronic money transactions - Google Patents

Description

The present invention relates generally to electronic money systems and, more particularly, to measures for simplifying their use for an average user.

A typical Internet Service Provider (ISP) system is shown in Figure 1. The basic function of an ISP is to transfer data from one network, such as the Internet, to another network, such as the conventional telephone network, and vice versa. A user can connect to the Internet network 116 using his computer 100 and a modem 102 over the conventional telephone network, as shown in Figure 1, through the user's local exchange 104 and through the ISP system 105. A typical ISP system 105 includes a call control point 106 that receives the calls and routes them to terminal servers 112. The terminal servers 112 basically perform a conversion of the data signals from the form used in the usual telephone network to the form used in the network 116 to which the ISP system 105 is connected, and vice versa.

A typical ISP system 105 further includes a router 114 which receives data signals from terminal servers 112 and sends them to the network 116, and conversely receives data signals from the network 116 and, based on the destination addresses specified in the data signals, causes each signal to be forwarded to the correct terminal server 112. A typical ISP system 105 also includes a proxy unit 118 which functions as an intermediary between the ISP's users and third parties on the network 116. A proxy unit typically caches in its mass storage the most recent documents, that the ISP's users retrieve from the network. When a user submits a request for a document that was immediately previously accessed by the ISP and is thus cached in the proxy unit's memory, the proxy unit sends the user a copy of the document from its memory to reduce the load on the network 116 and speed up the service experienced by the user.

The data signals are transmitted on the Internet using the TCP/IP protocol, which is described in detail in the RFC 791 and RFC 793 standards. Access to World Wide Web (WWW) documents is possible from WWW servers on the Internet using the HTTP protocol, which - among other things - defines a standard format for requesting a specific document on a given WWW server. Version 1.0 of the HTTP protocol is defined in the RFC 1945 standard. The TCP/IP protocol and the HTTP protocol are well known to those familiar with the art and require no further explanation.

Fig. 2 shows the configuration of a second type of telephone network service, in particular a voice service provider system 210, which is used for example for automated order services. Fig. 2 shows an example of how a telephone exchange according to an intelligent network (IN) can be used to produce an automated service. The voice service system 210 has a service switching point (SSP) 104 according to the IN, a service control point (SCP) 110 for controlling the SSP and a database with voice output 212. The task of the SSP is basically to connect the callers to the outputs of the database 212. The user can, for example, order tickets from such a service by pressing the number keys on his telephone, while the ICP guides the user using the messages in the database 212. Intelligent grid characteristics and the capabilities of various IN components such as the CCP, the SCP and the SSP are described in several CCITT Recommendations, such as Recommendations Q.1201, Q.1202, Q.1203, Q.1204, Q.1205, Q.1211, Q.1213, Q.1214, Q.1215, and Q.1218.

Several versions of electronic money are available and currently under development. An overview of major versions of electronic money is provided in the cover story and related articles of the June 1996 issue of Byte magazine. In one system, a user can receive electronic cash from an electronic cash provider, who provides the user with electronic symbols representing the amount of money the user is paying. The user typically stores these symbols in his computer using an electronic wallet program, and later uses the symbols to pay for various services or goods over a telecommunications network, such as the Internet. After the transaction, the merchant can send the received symbols to the electronic cash provider and convert them into real money. Such an electronic cash system is described in detail, for example, in European patent application EP 542 298 and the references therein. An electronic money system based on the use of credit cards or similar means of payment is currently being developed by the major credit card companies. A similar system based on credit cards is described in the RFC 1898 standard.

A conventional payment system (for paying for the products with a credit card) between the user and the merchant is disclosed in WO 96/08783, which document discloses a payment system for enabling a first Internet user to make a payment to a second Internet user for makes a purchase of an information product deliverable over the Internet. In the system, the seller sends the information product over the Internet to the buyer at almost the same time as the seller sends a transfer request message over the Internet to the payment system. The payment system sends a transfer inquiry message to the buyer indicating, for example, the transfer amount in the preferred currency associated with the buyer's cardholder account. The buyer can then respond by sending a transfer response message to the payment system over the Internet.

All currently existing electronic money systems have in common that they are cumbersome from the user's perspective. The user must first receive the electronic money before he is able to pay for services or goods over a communications network such as the Internet. Furthermore, the user typically needs a special electronic wallet program. One of the basic electronic money systems based on a credit card requires the user to receive an electronic identification certificate to identify him as the rightful owner and user of his credit card.

These requirements place a burden on the user and require the average user to know the details of numerous forms of electronic money and to learn how to obtain and use such electronic money. The symbols representing electronic money are typically stored on the hard disk of a user's computer and are vulnerable to accidental deletion or hard disk malfunction. Accordingly, the user should take good care of the electronic cash and make backup copies of the symbols representing the money. Although electronic money systems provide a replacement for accidentally lost electronic money, the replacement procedure represents a burden for the user. Furthermore, due to the fact that more than one type of electronic money has been developed, the user must obtain all the main types of electronic money if he does not want to be limited in his purchasing options, since it is very likely that not all merchants will accept all forms of electronic money.

One object of the invention is to simplify the payment process with electronic money for a user. Another object of the invention is to implement a system with which Internet service providers and similar services can provide a simple way of using electronic money for their users.

According to a first aspect of the present invention there is provided an electronic payment transaction system in a node connecting a first telecommunications network and a second telecommunications network, the system comprising an electronic payment interceptor arranged to:

to intercept a request for payment messages corresponding to electronic money in a first form, arriving from the first telecommunications network and addressed to a user in the second telecommunications network;

to convert the request for payment messages into messages corresponding to electronic money in a second form; and

to send the converted request for payment messages to the user.

The monetary conversion performed by embodiments of the present invention typically requires the intervention of the ISP in the transmissions between a user and a third party; ie, interception of the requests for electronic payment sent to a merchant.

The ISP can take care of all the technical details necessary for obtaining different forms of electronic money in a centralized manner, and all users of the ISP can use the electronic money obtained through the ISP simply by allowing the ISP to forward payment requests to the user in a unique predefined monetary form. Furthermore, the ISP can receive all major forms of electronic money, whereupon a user can select the most economical payment method if a merchant accepts payments in more than one form of electronic money.

The preferred system includes an interceptor that examines the incoming traffic. If the interceptor notices that a transmission contains a request for payment with electronic money, it performs a conversion of the money form. The system may further include a means for controlling and optionally initiating the payments. For example, the user may set an acceptance policy or accept or reject individual payments via a separate connection to a network address managed by the system.

According to a second aspect of the present invention there is provided a method for performing electronic money transactions in a node connecting a first telecommunications network and a second telecommunications network, the method comprising:

intercepting a request for payment messages corresponding to electronic money in a first form, arriving from the first telecommunications network and addressed to a user in the second telecommunications network;

Converting the request for payment messages into messages corresponding to electronic money in a second form; and

Sending the converted request for payment messages to the user.

Numerous embodiments of the invention are described in detail below, by way of example only, with reference to the accompanying drawings, in which:

Fig. 1 shows the manner in which a user can connect to a network, such as the Internet, according to the prior art;

Fig. 2 shows an example of a voice service provider system using an IN-capable telephone switch;

Fig. 3 shows a basic example of a system according to the invention;

Fig. 4 shows another example of a system according to the invention;

Fig. 5 shows an embodiment of the invention in which the interceptor 120 outputs the redirected traffic via the same output as the rest of the traffic;

Fig. 6 shows an example according to which the system according to the invention is implemented in a system connected to a mobile radio network;

Fig. 7 shows an advantageous embodiment of the invention in which the interceptor 120 is implemented in a proxy unit 118; and

Fig. 8 shows an example of a particular implementation of the system according to the invention.

Figures 1 and 2 were previously described in connection with the description of the prior art.

Fig. 3 shows an electronic payment system. In this example, the user is in contact with a merchant 130 using his computer 100 and modem 102 or an ISDN adapter 103 via the local exchange 104, the Internet service provider (ISP) system 105 and the network 116. In the system according to the invention, the ISP system 105 additionally contains an interceptor 120. The interceptor 120 redirects the payment requests that originate from the network to the control unit 122 of the ISP system 105. When the user makes a request for a service or a product, the merchant's system 130 responds with a payment request. The interceptor 120 redirects the request to the control unit 122 which sends usual billing signals according to the payment via the SSP 106 to the user's local exchange 104, where the corresponding amount is added to the user's telephone bill. After sending the billing signals, the control unit 122 sends the electronic money to the merchant 130 via the network 116. After receiving the electronic money, the merchant 130 continues the production of the requested services or goods.

The controller may send the electronic money or other messages to the merchant via the interceptor 120, as in the embodiment of Figure 3, or beyond the interceptor 120, for example via a router included in the ISP system.

The control unit can debit the user's telephone account at any appropriate stage of the payment procedure , ie not only at the beginning of the procedure. Of course, it may be desirable for the ISP to effect the debiting at the latest before a point in the payment procedure after which the payment cannot be cancelled if the debiting is unsuccessful for some reason.

In an advantageous embodiment of the invention, the control unit 122 contains, in addition to the functionality required for using the electronic money, also the functionality of a standard IN-compliant service control point.

In the embodiment of Fig. 3, the electronic wallet device, i.e. the electronic money transaction device, is located in the control unit 122 or a similar functional unit. The wallet and its contents are supervised by the ISP, which receives more electronic money from an electronic money provider when needed. The ISP can receive all major forms of electronic money from the major electronic money provider, after which the user does not have to take note of which merchants require which type of electronic money.

An important aspect of electronic money is the possibility for the user to accept or reject any payment request. In the system according to the invention this can be implemented in several ways. An advantageous embodiment is shown in Fig. 4. The control unit 122 is connected to the router 114, the user can establish a connection to a payment control device 122a in the control unit 122. This payment control device 122a can for example be in the form of a World Wide Web (WWW) document at a certain network address managed by the control unit 122. The router 114 directs all communication from the user to this network address directly. to the control unit. The user may open a connection to the network address of the payment control device in the same usual manner as any user address in the network 116. The control unit 122 may recognize the user connecting to it via the network 116 based on the user's network address, since the control unit 122 knows the network addresses assigned to the users of the ISP system 105. Once the user has opened a connection to the network address of the control unit 122, the control unit 122 may inform the user of any incoming payment request via the opened connection and ask for confirmation.

The payment control device and the other control device described later in this application could be directly connected to the network 116. In this case, the communication from the user to the control device would be routed over at least part of the network 116. However, such a configuration would be more vulnerable to external attacks, since the important information for determining the acceptance of payments would flow briefly outside the ISP system. The configuration shown in Fig. 4 is more secure, since the communication between the user and the control device takes place only within the usual telephone network and in the ISP system.

As in the case of conventional electronic money, the user can incorporate a default policy on payment requests and instruct the ISP to handle incoming payment requests accordingly. The policy can, for example, contain the following options:

- Allowing payments below a certain limit,

- Allowing all payments until a certain total is reached within a specified time period,

- Allowing all payments to be made to a specific merchant or a number of merchants,

- Prohibit all payments to a specified merchant or a number of merchants,

- any possible combination of the preceding options, or

- Prohibit all payments.

The user can set the policy with the ISP in a number of ways, such as by reaching a separate agreement with the ISP. The ISP can also provide a default policy to which the users agree when they start using the ISP's services. According to an advantageous embodiment of the invention, the control unit 122 includes a policy control device 122b, and the user can control and adjust the payment acceptance policy by connecting to the control unit 122 via the network as described above, and by instructing the control unit 122 using the policy control device 122b. The control unit 122 can determine which user policy information to make a change to by recognizing the user in the same way as previously described.

Another aspect of electronic money, in particular the voluntary sending of an amount of electronic money, can be implemented in a similar manner. According to an advantageous embodiment of the invention, the control unit 122 includes a payment sending device 122c to which the user can connect to a specific network address, as previously described. After connecting to the payment sending device 122c, the user can instruct the payment sending device 122c to send an electronic payment to a desired network address. After receiving the command to send a payment, the payment sending device preferably sends accounting signals to the user's switch 104 to add the amount to be sent to the user's telephone bill, after which the payment sending device 122c sends the instructed amount to the user's telephone bill. electronic money to the desired address, indicating the user as the sender of the money. It is also possible that a user wishes to send an anonymous donation. Accordingly, the payment sending device 122c preferably also includes a control device that enables the user to instruct the payment sending device 122c not to indicate him or any other person as the sender of the payment. The user may also use any of the known methods for concealing the identity of the sender of a message, for example by sending the payment via a special anonymous server.

In some electronic money systems, the user may be required to initiate a payment procedure himself. In the system, the user may initiate the payment, for example, with the payment sending device 122c or a similar control device.

In an advantageous embodiment of the invention, the payment control device 122a, the policy control device 122b, the payment sending device 122c and any other control devices described in this specification are combined into a general control device to enable the user to control all aspects of electronic money with a single connection. It is also possible to implement any combination of the control unit 122 and any control devices described in this application.

In a further advantageous embodiment of the invention, the system according to the invention enables a further aspect of electronic money systems, in particular the receiving of payments. In this embodiment, the system according to the invention receives and processes the payment in the manner specified by the electronic payment system in question. After receiving the payment, the system transfers a assigned credit amount to the user. The transfer can be carried out, for example, in one of the following ways:

- For example, the system may credit the amount if the basic network through which the user is connected to the ISP allows crediting the user's account;

- the ISP may maintain internal accounts for users, and in this case the payment will be added to the account; or

- the ISP can initiate an automated bank transfer to the user's bank account if the user has informed the ISP of his bank and bank account.

Alternatively, the system according to the invention may employ any of the prior art methods for crediting an account, such as is the case in connection with many services, subject to an extra charge above the normal call charge. Preferably, the system according to the invention may be instructed by a user to accumulate payments in an internal account until a specified minimum amount is reached before the accumulated credit is transferred to the user.

The control unit 122 may include details of each payment in the accounting information sent to the user's telephone exchange 104 to enable a detailed listing of goods and services paid for on the user's telephone bill if the backbone network with the telephone exchange 140 supports a detailed listing of the telephone bill. This type of reporting may also be achieved by sending a separate information letter or email to the user or by using some other means of informing a user.

The requested payments may not be an exact multiple of the payment unit of the telephone network through which the user is connected to the ISP system 105. The requested payments may even be significantly smaller than the usual debit units, since many electronic money systems are designed for very small payment transactions, referred to as micropayments. The system according to the invention may include means for maintaining accounts for amounts below a payment unit, and wait until the total size of the payment transactions exceeds a payment unit before sending billing signals to the user's local exchange to add a billing unit to the user's telephone bill. The invention does not limit the billing practices of the ISP system in any way. For example, the ISP may add an additional charge for each electronic payment made using the system according to the invention.

In an advantageous embodiment of the invention, the ISP sends the user a separate invoice instead of charging it to his telephone bill. The ISP may collect a number of payment transactions in an internal account until a first predetermined amount is reached after which the ISP sends a bill. If a payment is larger than a second predetermined amount, the ISP may send a bill to cover that particular payment. The ISP may also require the user to deposit a sum before the user is allowed to use the ISP's electronic money, i.e. it may request a payment transaction before use. Of course, any of the usual billing methods may be used.

The system according to the invention can use any electronic money system, even money systems based on credit cards. The system can provide the merchant with the credit cards issued to the ISP, after adding the allocated amount to the user's telephone bill. The ISP can obtain all the necessary electronic identification certificates and programs required to use a particular type of credit card-based electronic money, thereby reducing the burden on the ISP's users.

The basic functions performed by the interceptor 120 include, but are not limited to, the following:

- The interceptor 120 inspects each incoming data packet,

- if the data packet does not contain any electronic money transfer, the data packet is forwarded to the user in the normal way,

- if the data packet contains electronic money transactions, the interceptor device 120 forwards it to the electronic money transaction device.

The method for detecting electronic money traffic as distinct from other traffic may vary in accordance with the actual protocol used to transfer money. In currently used electronic money systems, the two main approaches for transmitting electronic money information are as follows:

1) electronic money transfer is directed to a specific port according to the TCP/IP protocol,

2) the electronic money information is contained in special fields of the HTTP protocol.

Preferably, the system according to the invention is designed to handle both types of electronic money information. For the sake of clarity, cases 1) and 2) are discussed separately in the following paragraphs.

In the case that the electronic money traffic is directed to a specific TCP port, the basic function of the interceptor 120 for redirecting the electronic money traffic to the control section 122 can be implemented in numerous ways, including at least the following:

1a) The interceptor 120 can redirect the packets containing electronic money to a different exit compared to the rest of the traffic, as shown in Fig. 4.

1b) The interceptor 120 may treat a packet of electronic money as a piece of data and pack it into one or more IP packets addressed to the controller 122 and route the new packets to the same output as the rest of the traffic, after which the router 114 of the ISP system switches the new packets to the controller 122.

1c) The interceptor 12C) may rewrite the packet, replacing the user's address with the address of the controller 122 in the destination address field of the packet, encoding the user's address in other fields of the packet, or by adding a source routing option to enable the controller 122 to identify which user the packet was originally addressed to. After overwriting, the interceptor 120 forwards the overwritten packet to the same output as the rest of the traffic, after which the router 114 of the ISP system 115 routes the new packets to the controller 122.

The configuration of the embodiment shown in Fig. 5 is suitable for use in the context of implementation approaches 1b) and 1c). In this embodiment, the interceptor 120 redirects the packets by redirecting them to the control unit 122. The router 114 then forwards all packets to their specified destination address, after which the redirected packets reach the control unit 122.

The exact TCP port designated for electronic money transfer may vary depending on the provider of the electronic money. In this case, the interceptor 120 may check whether the TCP port number in the destination port field of the packet corresponds to any of the port numbers in a predetermined group of port numbers.

In an advantageous embodiment of the invention, the interceptor 120 redirects the electronic money addressed to only some users and it passes the electronic money addressed to the other users without redirecting. In this embodiment, if the data packet contains electronic money, the interceptor 120 determines the destination of the packet. If the packet destination is not one of the users in a certain category, the packet is routed normally to the end user. In this embodiment, the ISP users take care of the electronic money themselves according to the manner known in the art, if they do not wish to pay for any services or goods via the telephone bill. Such an option would be useful, for example, for employees of a small company who use the company's account with the ISP to access the network and who may wish to pay for the services or goods themselves. The interceptor may also provide for redirection of payment requests for only certain types of electronic money, and forward payment requests for other types of electronic money without redirection. These features may preferably be controlled by a controller similar to the controllers 122a, 122b and 122c described above.

The above case 2) is somewhat more complicated, ie when electronic money information is stored in additional fields of a HTTP request according to the HTTP protocol. An HTTP request may be sent over a network in one or more transmission units such as TCP packets, depending on the size of the request and the size of a single transmission unit of the network. Accordingly, re-engineering of the HTTP request sent by transmission units may be required before the interceptor 120 can inspect whether or not the request contains electronic money information.

The HTTP protocol allows the transmission of numerous data fields, ahead of the payload of a single transmission, such as an HTTP request. The HTTP protocol itself defines and uses some fields, and electronic money systems may define other fields.

These electronic money systems can use at least the following formats in a single HTTP transfer:

2a) The transmission contains only electronic money information in one or more fields,

2b) the transmission contains the electronic money information in one or more fields and as the payload data of the transmission, or

2b) the transmission contains the electronic money information in one or more fields, and a document.

In fields 2a) and 2b) above, the transmission contains only electronic money information in various forms. In these cases, the interceptor 120 causes the transmission to be redirected to the control unit 122, which can subsequently act as requested by the electronic payment protocol in question and as described above in connection with the description of Fig. 3.

The above case 2c) is more complicated. As above, the interceptor 120 causes the transmission to be redirected to the control unit 122. In this case, the control unit 122 must decide whether the user must receive the document contained as payload data of the transmission. If the control unit 122 can determine that the user does not have to receive the document, the system can operate as described above in points 2a), 2b). The determination is possible if the electronic payment protocol in question has standardized the content of such a document, and the control unit 122 can verify that the document does not contain any new information for the user. For example, it can be an HTML document of a given structure, with a question about the acceptance of the purchase and the definitions of a "yes" and a "delete" button for the user to confirm or delete the purchase. If the purchase is within the limits specified by the user for automatic acceptance, the control unit 122 does not have to present the question to the user.

If the control unit 122 cannot determine that the user does not need to receive the document, it must forward the HTTP request with the document to the user. The control unit can accomplish this, for example, by sending the HTTP request back to the interceptor 120, instructing the interceptor 120 to send the HTTP request to the user. Alternatively, the system can include other means for adding such requests sent by the control unit to the data communication traffic directed to the user. In order not to initiate a payment procedure at the user's computer, the control unit 122 preferably removes the fields with electronic money information from the HTTP request forwarded to the user or replaces them and their contents with an indication having the effect that payment processing is already taking place.

In a further advantageous embodiment of the invention, the system according to the invention can give the user an indication for accepting or refusing a payment by sending an electronic document to the user, for example an HTML document containing, for example, a question about accepting the purchase, as well as the definitions of a "YES" and a "DELETE" button for the user to confirm or delete the purchase. In particular, in case 2c) described above, the control unit replaces the document sent by the merchant with a similar document specific to the ISP system before forwarding the HTTP request to the user. Of course, as described above, the control unit must first determine whether it is allowed to replace the original document.

The HTTP 1.0 protocol is defined in the RFC 1945 standard, as is well known to those familiar with the art. Accordingly, the protocol is not described in this application. The exact fields and field names used by numerous electronic money systems may vary according to the money system or the electronic money provider in question, and therefore the exact fields and field names are not defined in this application. The system according to the invention can be designed to operate on any given protocol for transmitting electronic payment transactions.

In a further advantageous embodiment of the invention, the interceptor 120 redirects all HTTP traffic based on the TCP port number reserved for the HTTP protocol. The system according to the invention may employ a two-level interceptor scheme in which the redirected HTTP traffic is interpreted and inspected by a two-level interceptor. which routes HTTP transmissions containing electronic money information to the controller 122 and forwards the remainder of the HTTP traffic to the user. Alternatively, the first interceptor 120 may redirect all HTTP traffic directly to the controller 122, which then interprets and inspects all HTTP transmissions. As before, if any given HTTP transmission does not contain electronic money information, the transmission is forwarded to the user. If the HTTP transmission contains electronic money information, the transmission may be handled as previously described.

According to a further embodiment shown in Fig. 7, the interceptor 120 and preferably also the functionality of the control unit 122 in association with the electronic money are implemented in the proxy unit 118 of the ISP system. For example, the electronic wallet device 124 of the ISP system could be implemented in the proxy unit 118 instead of the control unit 122, as previously described. Furthermore, the control devices 122a, 122b, and 122c and the other control device in connection with the use of the electronic money can be controlled by the proxy unit 118, in the embodiment according to Fig. 7. In this embodiment, the remaining functionality of the control unit 122 is very close to that of a conventional service control point 110 of an IN-ready telephone exchange. The proxy unit 118 can handle all details of the electronic money transactions and the control unit 122, in addition to the usual functions of a service control point, only needs to have the ability to receive accounting information from the proxy unit 118 and to return confirmation of a successful addition of an amount to the user's telephone bill.

In the usual ISP systems, the use of the system proxy unit is not mandatory for a user, and he can programs in his computer not to use the proxy unit. In the embodiment shown in Fig. 7, the user can also control the use of electronic money by choosing whether or not to use the proxy unit 118. Furthermore, a large ISP may have more than one proxy unit to handle traffic; in this case, the user can choose which proxy unit to use: one with electronic money functionality, or a conventional one without functionality to support the use of electronic money. In the embodiment shown in Fig. 7, if the user does not use a proxy unit or uses a conventional proxy unit, the ISP does not handle the electronic money traffic for that user in any special way, after which the user can use his own electronic money if he so wishes.

The interceptor 120 may be implemented, for example, in a firewall device or a device for preventing unwanted data access. A firewall device is typically a computer running monitoring software that is installed between a system and a network to protect the system against unwanted intruders from the network. A typical manner of operation for a firewall device is to redirect all outgoing traffic from users of the system and all incoming traffic addressed to users of a system so as not to reveal the users' true network addresses. That is, for outgoing traffic, the firewall replaces the user's address with a fake address and stores the user's address and the fake address in its memory. Conversely, the firewall device replaces the fake address specified as the destination address in an incoming message with the user's actual address. The firewall typically blocks all incoming traffic addressed to any of the other addresses. Such a redirection device provides an advantageous starting point for implementing an interceptor device which effects the separation of the electronic money traffic from the rest of the traffic by redirecting the electronic money traffic as previously described.

The incorporation of the electronic money functions into the control unit 122 in some of the above-described embodiments of the invention has been presented as an example only. Separating the electronic money functions from the control unit 122 to a separate device, such as a proxy unit 118 as in the previous example, or a separate electronic money unit, may be incorporated into any of the embodiments described in this application.

In a further advantageous embodiment, the system according to the present invention functions to convert one form of electronic money into other forms of electronic money. For example, the user may have only one type of electronic money, and in this case it is desirable for the ISP system to convert a request for payment into requests for that type of electronic money with which the user can pay. In such an embodiment, the system according to the invention sends the user a standard payment request, instead of sending booking information to the standard telephone network for charging his telephone bill. After receiving the payment from the user, the ISP system can respond to the original payment request, regardless of the type of electronic money requested.

The system can also be used to simplify the receipt of electronic money. If a Users receiving electronic money to be able to make electronic payments independently of the ISP can contact a bank that has a special agreement with the ISP that allows ISP users to download electronic money from the bank into their own computers and pay for the downloaded money together with their phone bill. Alternatively, due to the fact that a bank can also act as a regular merchant, the user can contact a bank that sells electronic money, i.e. merely changes one type of electronic money into other types of electronic money for a commission. This allows the user to receive electronic money in his computer, which can subsequently be used in other systems without the help of the ISP. For example, the user can download the electronic money from his computer into a smart card and use the smart card to pay for purchases in regular shops, for tickets in public transport, etc.

In the foregoing embodiments, the network 116 may be, but is not limited to, the Internet. The network 116 may be any other network, such as a closed network of a particular business sector that is closed in the sense that it is accessible only to companies and not to individuals.

According to the previous embodiments, the user was connected to the ISP system 105 via a conventional PSTN/ISDN telephone network. However, the system according to the invention can also be used in connection with other types of telecommunications networks. In an advantageous embodiment of the invention, the user is connected to the ISP system 105 via a mobile telecommunications network 200, as shown in Fig. 6. For example, the user can connect the ISP system 105 to his laptop computer 100 and a mobile telephone 202 via the base station 204 of the mobile telecommunications network 200. The mobile telecommunications network 200 may be, for example, a GSM (Global System for Mobile Communications) network or a DAMPS (Digital Advanced Mobile Phone Service) network. Alternatively, the user may be a PDA (Personal Digital Assistant) device 206 having mobile terminal functions or a similar device for establishing a connection to the ISP via the mobile network 200. The embodiment shown in Fig. 6 is very advantageous to the mobile telephone service providers who also sell SP services. Other possible telecommunications networks are cable television networks, for which several proposals have been made that would convert the cable TV network from a one-way broadcast network to a two-way telecommunications network.

For the foregoing embodiment, several functional units are described, such as the interceptor 120, the control unit 122 and the electronic wallet device 124. These functional units can be implemented in a variety of different ways in a single or multiple physical pieces of equipment, and the invention does not limit the form of implementation of these units. For example, the interceptor 120 can be implemented in the router 114, or multiple interceptors 120 can be implemented in the terminal servers 112. The interceptor 120 and the control unit 122 can even be implemented in the same physical device. Furthermore, if desired, the control unit 122 can be implemented with multiple subunits in one or more physically separate devices. For example, the functionality of the control unit 122 in the form of computer programs that operate in one or more computers.

In the following sections, a description is given of an exemplary embodiment of the invention with reference to Fig. 8.

In this embodiment, the interceptor 120 is implemented as a high-speed microcomputer running the Net BSD operating system. The microcomputer is equipped with local area network (LAN) interfaces for connection to the Internet, the terminal servers 112 and the controller 112. The TCP-level interceptor is implemented by modifying the operating system kernel for handling IP packets. In particular, the ip_input() operating system function is modified to inspect all incoming TCP/IP packets. The packets containing electronic money information, i.e., designating a port number reserved for an electronic money system, are redirected to the controller 122 via the commodity interface. Packets containing HTTP traffic are directed to the HTTP pre-selection software 120' running in the same microcomputer.

The HTTP screening and intercepting software 120', referred to as a two-level interceptor in the description of one of the previous embodiments, receives all packets of HTTP traffic from the modified operating system kernel. The HTTP screening and intercepting software 120' inspects the packets to determine whether the packets contain electronic money information. If this cannot be determined from a single packet in the case of an HTTP transmission with more than one packet, the HTTP screening and intercepting software 120' may collect multiple packets before making the determination. If an HTTP transmission does not contain electronic money information, the Transmission is forwarded to the terminal server 112. HTTP transmissions with electronic money information are forwarded to the control unit 122.

The microcomputer is also equipped with router software for routing non-redirected traffic to the terminal servers and user-originated traffic to the Internet and to the control device implemented by the transaction authorization device 122e.

In the embodiment of Figure 8, the control unit 122 includes a Unix server, such as an HP 700 series workstation. The workstation runs electronic wallet software 124, transaction access authorization software 122e, SCP software 122h, user authorization software 122f, and call database software 122g.

The electronic wallet software 124 contains functions that enable the software to act as a customer - ie as a buyer - in electronic money transactions. The wallet software preferably contains specialized functions for handling different forms of electronic money, such as e-cash and the credit card-based SET protocol. The electronic wallet software handles the electronic money transaction messages received from the interceptor 120, 120' and causes a request to the transaction access authorization software for accepting or rejecting a transaction. After receiving an access authorization, the electronic wallet software receives the telephone call identifier from the call database software based on the IP address of the user specified in the transaction message. After receiving the call identifier, the electronic Money software instructs the SCP software to detect an amount of money in the user's telephone account. The amount to be detected is based on the electronic money transaction request, which may include ISP service charges, sales taxes and other fees. If the exact amount cannot be billed due to the fixed size of charging units in the telephone network, the excess charge may be stored in the call database as a temporary user credit or refunded by adjusting the basic billing interval in the telephone network. If the electronic wallet software receives an indication from the SCP software that the requested amount has been billed, it continues the electronic money transaction. The electronic wallet software includes the user's IP address information in the response transmission to the merchant in such a way that the user is identified as the sender of the transmission.

The electronic wallet software 124 preferably holds a sufficiently large amount of electronic money, and all required certificates and credit and debit card numbers required for the use of credit card-based electronic money systems.

The transaction authorization software 122e determines whether a given transaction is authorized or not. The transaction authorization software includes the functions necessary to implement the authorization policy options previously described in connection with the description of Figure 3.

Preferably, the authorization software 122e also implements the payment control device 122a and the policy control device 122b described above. For this purpose, the authorization software manages one or more WWW documents in the form of HTML forms using CGI scripts. The user can access these documents at a specific network address to which users cannot connect in the same way as they would at any other network address. The combined interceptor and router device 120 routes HTTP requests addressed to this address from users of the ISP to the authorization software. Once a user has connected to the specific network address and received the payment control form, the authorization software can inform the user of a new payment request by sending the user an update of the form. The access authorization software can detect and certify that the intended user confirms the correct payment request or that a user changes his or her own payment policy options by checking the user's IP address in the HTTP transmission sent by the user.

The SCP software 122h contains the functions required for an IN-ready service control point. An example of such software is the OSN SCP software from Systems Software Partners Ltd., Lappeenranta, Finland. For the implementation of Fig. 8, the software for providing standard SCP functionality is to be supplemented with functions that implement the ability to communicate with the electronic wallet software 124.

Whenever a new connection is opened by the SSP 106, the SCP software 122h stores information about the call in the call database 122g. This information can Call identifiers for future billing functions, and a line identifier that enables the user access authorization software 122f to associate an IP number with that particular call. When a connection is closed, the SCP software 122h removes the information about the call from the call database 122g.

The accounting function of the SCP software 122h is initiated by the electronic wallet software 124. When the SCP software 122h receives an accounting request from the electronic wallet software 124 indicating the amount of money to be debited and the call identifier, the SCP software 122h converts the amount into telephone network charging units and instructs the SSP 106 to perform the actual debiting. After the SSP indicates that the debiting is complete, the SCP sends a billing response to the electronic wallet software 124 to indicate that the accounting function has been performed.

The user authorization software 122f assigns an IP number for each incoming call and stores this number together with the line information in the call database. Whenever the terminal server 112 receives a new incoming call, it sends an authorization request to the user authorization software 112f. This authorization request contains a line identifier that enables the user authorization software 112f to assign a unique IP number to this line. The IP number is sent to the terminal server in response to the authorization request. The user authorization software 112f can also authorize the users, ie confirm whether a new call is from a registered user of the ISP or not.

In this embodiment, the call database software 122e maintains a database containing at least the following information:

- Telephone accounting identifier or call identifier required to carry out telephone network billing,

- Line identifier identifying the terminal server used by the call as well as the logical line number in the terminal server, and

- the IP address assigned to the call.

Suitable database software packages are available and known to those familiar with the state of the art.

The terminal servers of the embodiment of Figure 8 may be, for example, the Ascend MAX TNT terminal servers from Ascend Communications Inc., US. These terminal servers can handle a large number of simultaneous calls and can support both standard and ISDN telephone lines. Whenever a new telephone call arrives from the SSP 106, the terminal server 112 queries the user authentication software 122, which returns an IP number to be assigned to the call. The terminal server also provides the IP number to the user's computer via PPP protocol negotiation procedures, and thereafter the terminal server 112 begins carrying the user's TCP/IP traffic until the call is completed.

The SSP 106 in the embodiment of Figure 8 may be a conventional IN-ready service switching point.

The networks specified in this application, such as the Internet and the conventional telephone network, are specified only as examples and do not limit the invention in any way. The invention is applicable to any environment containing a basic network with an accounting function and services or any other form of commerce that is to be paid for with electronic money.

In the foregoing embodiments, ISPs have been given as an example of suitable providers of the service enabled by the present invention. However, this invention is not limited to use by Internet service providers. For example, a company with its own telephone exchange can provide the system according to the invention for the benefit of its employees and numerous units without the company being an ISP per se.

Using the present invention, a user does not need to make a separate agreement with electronic money providers.

The present invention is applicable to essentially all electronic money systems. An ISP can receive all the major forms of electronic money and the ISP's users have several different forms of electronic money at their disposal, resulting in greater freedom of choice in merchant selection and purchasing decisions. Furthermore, users can then choose the most cost-effective way of paying, since different fees charged by electronic money providers can vary according to the form of electronic money and the particular electronic money providers.

For the purposes of this application, the term usual transaction means any usual way of carrying out monetary transactions, such as adding a debit or credit to a account of a telephone subscriber, sending a separate bill, transferring funds by bank transfer, or changing the balance of the user's internal account with the ISP for later billing or crediting.

Claims (9)

1. An electronic payment transaction system in a node (105) connecting a first telecommunications network (116) and a second telecommunications network, the system comprising an electronic payment interceptor (120) arranged to: intercept a request for payment messages corresponding to electronic money in a first form, arriving from the first telecommunications network (116) and addressed to a user in the second telecommunications network; to convert the request for payment messages into messages corresponding to electronic money in a second form; and to send the converted request for payment messages to the user. 2. A system according to claim 1, arranged to send a payment with electronic money in the first form in response to a payment received from the user in the second form in the first telecommunications network (116). 3. System according to claim 1 or 2, wherein the first telecommunications network (116) is a TCP/IP network. 4. System according to one of the preceding claims, wherein the first telecommunications network (116) is the Internet network. 5. A system according to any preceding claim, wherein the second telecommunications network is a conventional PSTN telephone network. 6. System according to one of claims 1 to 4, wherein the second telecommunications network is arranged to support ISDN connections. 7. System according to one of claims 1 to 4, wherein the second telecommunications network is a cellular mobile telecommunications network (200). 8. A system according to any preceding claim, comprising means for allowing a user to initiate an electronic payment transaction. 9. A method for performing an electronic payment transaction in a node (105) connecting a first telecommunications network (116) and a second telecommunications network, the method comprising: intercepting a request for payment messages corresponding to electronic money in a first form, arriving from the first telecommunications network (116) and addressed to a user in the second telecommunications network; Converting the request for payment messages into messages corresponding to electronic money in a second form; and Sending the converted request for payment messages to the user.