WO1999030293A2 - Method of billing for services and products purchased over a network - Google Patents

Abstract

The present invention is based on the principle that, when a data network such as the Internet (25) is used through a telephone operator, the services and products available for purchase from the Internet (25) can be billed in conjunction with the telephone operator's billing. According to the invention, the connection from the caller (20) through the telecommunications network is formed through an intelligent network, i.e. an SSP exchange (21), so that it is possible for an SCP database (23) to influence the billing of the call, even retroactively. The invention is also based on the principle of linking together the A digital identity transmitted by the telecommunications network and the username known to the Internet (25) when making a connection to an Internet call series (22). In this case, billing for a service used in, or a product ordered from the Internet (25) can be performed by transmitting the total amount to be billed to the SCP (23), on the basis of the A digital identity corresponding to the Internet username.

Description

METHOD OF BILLING FOR SERVICES AND PRODUCTS PURCHASED

OVER A NETWORK

The present invention relates to a method for billing orders made from the Internet through a telephone network, by means of the telephone bill of the telephone connection used to place the order.

According to the state of the art, billing for transactions carried out through data networks, such as the Internet, takes place, for example through credit card companies. In such cases, the recipient of the payment is notified of the customer's credit card number through the Internet. Alternative methods of payment include C.O.D., rechargeable electronic cash, or special billing based on log files in Internet servers. When rechargeable electronic cash is used for payment, the customer opens an account in the recipient's system and deposits a desired sum in the account. The price of goods ordered, for example, service goods, is deducted from the balance of the customer's account. Special billing based on log files operates by a separate bill for products being sent to the person ordering them. In this type of payment, billing generally takes place after delivery of the products and the system usually demands a prior billing agreement to be made between those making and receiving the payment.

However, certain problems arise in such forms of payment according to the prior art.

Payment based on notification of a credit card number involves the risk to the customer of the number becoming known to outside parties. Due to cases of misuse, this risk is now well known and data transfer encryption has been developed in an attempt to eliminate it. Beside possible misuse, credit card billing has the drawback that the lack of a credit card may prevent purchases by many potential consumers, especially young people. Billing through credit card companies is also not economical for very cheap products.

Rechargeable electronic cash and billing based on log files also have difficult limitations. Rechargeable electronic cash requires the customer to make a sufficient deposit to cover future purchases. All consumers may not however be willing to commit themselves to product suppliers, while the making of deposits may be experienced as difficult and unpleasant. Billing using rechargeable electronic cash also prevents impulse purchases from being made from several suppliers. Nor can billing based on log files be used for impulse purchases in new customer relationships. This form of payment also requires prior agreements and mutual trust between the parties to a transaction. Log file billing uses a separate billing routine for monetary transactions, which is an expensive way to bill small sums.

Ericsson's application publication WO 97/29584 describes a method using a terminal device and a telephone network to purchase goods and services from a data network. It is particularly applicable if the Internet connection is made through a telephone system operator. In the method, data on the telephone connection used by the terminal device and on the vendor of the goods are identified, the identified data then being combined to bill the purchase from the connection used by the purchaser. Ericsson's method is based on giving the customer a temporary IP address for the duration of the contact and then linking the IP address to the device location code in the telephone exchange. Thus, the temporary IP address is linked to the customer's Calling Line Identity. When making a purchase, the person placing the order is identified by his/her temporary IP address and linked to the supplier through the supplier's IP address code.

Publication WO 97/29584 does not, however, describe the method of billing purchases in greater detail. If purchases are billed according to the state of the art as pulse billing,

Internet purchases that are billed through a telephone bill will inevitably remain within a narrow price range. This is because pulse charging is not suitable for billing very small or very large sums. If very small purchases worth less than a single metering pulse are made by this technique, the problem arises that the smallest billing unit is, however, the price of one pulse. The customer must then pay an excess price for the purchase. With large purchases, the telephone system operator must be able to ensure somehow that the customer's telephone connection remains open long enough for the total amount being billed to be transmitted to the customer's pulse meter.

The present invention is intended to eliminate these defects in the prior art and to create an entirely new kind of method, in which the total amounts of orders made through a data network are added to the telephone bill for the telephone connection used to place the order. The present invention does not use pulses as the basis of billing. Instead, the billing method allows unrestricted generation of the bill. In this case, billing takes place preferably on a so-called "AMA-ticket basis". According to the invention, AMA-ticket- based billing can be implemented by creating a virtual phone call in an SSP exchange, thus permitting billing data to be sent from an SCP database to the SSP exchange. To achieve this goal one can use, for example, a Core-INAP FCI (Furnish Charging Information) message to generate a virtual call. For instance, the SCP database gives a command to the SSP exchange to make a telephone connection to the exchange's internal IP device. For example, this allows the generation of an AMA-ticket to be sent with the aforementioned command based on the FCI message. Alternatively, flexible billing can take place through billing messages. Billing for a service will then take place by sending, from the SCP 23 to the SSP 21, an SCI message 9 defining the contents of the billing message that will be sent from the SSP 21 in the calling subscriber's direction.

The characterising parts of Claims 1 and 4 describe in greater detail the characteristics of a billing method according to the invention.

Thus, the invention described above allows services and goods available for purchase from the Internet through a telephone connection to be billed simply and precisely, even if the total amounts are very large, or are less than a single charging pulse.

A further problem with the method described in publication WO 97/29584 is that the customer's temporary IP address is used for customer identification in data transfer through the Internet. Such a use of an IP address involves, in principle, a risk that an external party may hijack the temporary IP address in data network traffic and use it to defraud. One versed in the art can easily hijack an IP address and though it is illegal to forge an IP address and use it to generate bills to someone else, nevertheless the risk exists. The present invention is also intended to eliminate this defect in the prior art and to create an entirely new type of method for identifying a user during transactions made over a data network through a telephone network.

The present invention is also based on linking the Calling Line Identity transmitted by a telecommunications network and the username known to the Internet, once contact has been made with the Internet call series. A service used on, or a product ordered from the Internet can be billed by using the Calling Line Identity linked to the Internet username as a basis for transmitting the total amount to be billed to the SCP. Data transferred over a public data network between the Internet operator and the vendor can, in principle, be observed by an external party. However, the data can be encrypted using a method approved by the parties, e.g. the so-called public-key method.

The characteristics of a billing method according to the invention are described in greater detail in the characterising part of Claim 5.

Thus, the aforesaid invention considerably reduces the risk of misuse if a telephone bill is used to bill for services and goods purchased from the Internet through a telephone connection. Security is improved by the fact that it is not necessary to use the IP address used by the customer to identify the customer outside the telephone operator's system.

Security is also improved by the fact that highly effective encryption methods, which are not necessarily available to private consumers, can be used in a connection through a public data network.

The invention will next be examined with reference to examples and the accompanying drawing.

The description of the invention includes references to ICA and FCI messages. In this application, ICA and FCI messages refer to ICA and FCI operators according to Core- INAP specifications. Similarly, this reference refers to other similar operators as messages for the sake of clarity, especially when the message character of the operator is emphasized. The drawing shows a diagram of one operating environment of the method according to the invention.

The drawing depicts one such system environment, in which the method according to the invention can be applied. The diagram also includes operating procedures for one method according to the invention. The procedures are shown as arrows between the system components involved. The diagram shows a telephone connection 20, connecting the user of paid services to a telephone network. Other components of the system are the telecommunications network SSP exchange 21, an Internet modem pool 22, an SCP database 23 and a verification database 24, as well as the Internet 25.

Use of the billing method comprises the following stages:

1) The telephone user calls from connection 20 (e.g. using a modem or ISDN modem) to the number of the Internet modem pool 22, after which the call is first connected to the SSP exchange 21 nearest connection 20.

2) Billing and connection data for the basic charge of the call are sought from the SCP database 23. The basic charge can be e.g. 15 p/min + local call charge, the destination number being the real number of the Internet modem pool 22.

3) The call is connected to the Internet modem pool 22, after which the user gives his/her username and password, which permit connection to the Internet contact service.

4) Once the user is connected to the contact service, the verification database 24 is updated with information that the caller in question, i.e. connection 20, has connected using the given username. Connection 20 is identified on the basis of the Calling Line Identity.

5) The user moves around the Internet 25 and orders a product that he/she has found or uses a service subject to a charge. 6) Information that the username in question has used certain services or ordered certain products is transferred to verification database 24. On the basis of the username, the database 24 links the information it has received with the correct Calling Line Identity.

7) Database 24 transfers information on the transaction to SCP database 23, in order to bill the connection 20.

8) If billing takes place on a AMA-ticket basis, the SCP database 23 uses ICA and Continue messages to command SSP exchange 21 to make a telephone connection. At the same time, it sends an FCI (Furnish Charging Information) message to SSP exchange 21. In addition, the SCP database requests the SSP exchange 21 to report on the success of the call, and for this purpose sends a further RequestReportBCSM message.

10) On the basis of the FCI message, the SSP exchange 21 generates a AMA-ticket 26, for billing the relevant connection.

9) If charging is pulse-based, SCP database 23 sends an SCI (Send Charging Information) message to SSP exchange 21.

11) On the basis of the SCI message, SSP exchange 21 sends a pulse train, corresponding to the price of the service or product, to the connection 20 used by the person placing the order.

Once the call has been disconnected, the link in verification database 24 between the username and the Calling Line Identity can be deactivated.

If desired, information on limits to the use of paid services by different usernames' or connections' can also be entered in database 24. If database 24 is informed that a certain username or a connection 20 wants to use certain services or order certain products, it checks if this is possible. If the user's data are found in database 24 (the Calling Line Identity corresponds to the username) and the user has not, for example, exceeded any use limit set for each billing period or order, database 24 informs the service producer that the payment can be billed, and simultaneously sends the information to SCP 23 for billing 7 the caller. In principle, use limits can be specific to either the username or the telephone connection or even to a combination of both.

If the user's data is not found in database 24 (the Calling Line Identity and the username do not correspond) or if, for example, the user would exceed a use limit for each billing period, database 24 informs the service producer that billing cannot be accepted. The same procedure can be followed, if the user is on a so-called black list, due to unpaid bills. If billing is rejected, information for billing 7 is not transferred to the SCP 23.

Pulse-based billing for a service or product is implemented by a Core-INAP SCI message (Send Charging Information) 9. During a connected call, SCP 23 can freely send one or more such SCI messages 9 to SSP 21. SCI messages 9 permit not only individual metering pulses, i.e. MPM messages 11, to be transmitted, but charge events to be altered. A system can also be constructed to use an SCI message 9 to control the tariff data of the so-called metering messages.

1 - 15 pulses can be defined as chargeable within a single SCI message 9. The SSP exchange 21 then sends a corresponding Metering Pulse Message (MPM) 11, containing the aforesaid number of pulses, in the direction of the A subscriber. The pulses are recorded in the meter of the calling subscriber 20, to form a basis for charging.

The following example illustrates pulse charging. If a single pulse costs 48.8 Finnish pennies and the user is billed for 30 Finnish markkas (= 61 pulses a 48.8 p/pulse), SCP 23 sends the pulses to SSP exchange 21 in the following form:

1. SCI message: 15 pulses

2. SCI message: 15 pulses

3. SCI message: 15 pulses

4. SCI message: 15 pulses

5. SCI message: 1 pulse The SSP exchange 21 then sends corresponding metering messages 11 in the direction of the A subscriber:

1. MPM message: 15 pulses

2. MPM message: 15 pulses

3. MPM message: 15 pulses

4. MPM message: 15 pulses

5. MPM message: 1 pulse

A service can also be billed by using the SCI message 9 to momentarily switch the charge, already generated by SSP exchange 21, in the direction of the A subscriber 20. This takes place by first using SCI message 9 to send a new train charge event from SCP 23 to SSP 21, and then immediately after by bringing the old charge event into force by a new SCI message 9.

For example, when billing the user of a service for 30 markkas (= 61 pulses a 48.8 p/pulse), SCP 23 can first send SSP 21 a message 9, in which the charge event commands it to send a 61 -pulse train in the direction of the A subscriber 20. Immediately after this, SCP 23 sends SSP 21 a new SCI message 9, in which the original charge event is given as the charge event.

A system can also be built, in which an SCI message 9 is also used to request SSP exchange 21 to send tariff data in the direction of the calling subscriber by a charging message. In this case, the service is billed by sending an SCI message 9 from SCP 23 to

SSP 21, defining the tariff information to be sent from SSP 21 in the direction of the calling subscriber. This allows a single payment for a service to be defined very flexibly in the charging message. The charge can be, for example, between 1 penny and 100,000 markkas.

Alternatively, billing can also be carried out on a AMA-ticket basis. When a service or product is billed on a AMA-ticket basis, an ICA (InitiateCallAttempt) message and a Continue message can be sent from SCP 23 to SSP 21, with the AMA-ticket being defined in an FCI message 8 included in the same connection. As in this case the ICA and Continue operations are only to allow the FCI message 8 to be sent and the call being built is not even meant to succeed, the call (attempted call) can be made, for example, to a telephone number that cannot respond. Preferably, the call is made to a telephone number that is not defined in the destination number analysis of the SSP exchange. Alternatively, the form of the destination number can be abbreviated so much that the call cannot succeed. The destination number is given in the DestinationRoutingAddress field of the aforesaid ICA message. By setting the SSP exchange 21 to generate an AMA-ticket from unsuccessful calls, billing information from the FCI message is entered in the AMA-ticket as described above, and thus proceeds to further processing and billing with minimum loading of the SSP exchange 21. In such a failed call, the dialogue between SSP exchange 21 and SCP database 23 will be terminated without error, if the SCP database 23 sends not only the aforesaid ICA, Continue and FCI messages, but also a RequestReportBCSM message, requesting the SSP exchange 21 to check the success of the call. If the call fails as described above,

SSP exchange 21 reports this to SCP database 23, after which the dialogue ends. This makes it possible, in an entirely different way to the prior art, to generate AMA-tickets, even for events that do not directly concern operations carried out in the telephone network by the telephone user.

The actual billing information is transmitted in the FCIChargeBase section of the FCI message 8, and in its fields in which data can be freely entered. Such fields can be used to state e.g. the Calling Line Identity of the subscriber paying for the service or product, and billing information (price, number of items, currency, etc.) on the service or product. In the future, it will be possible to define more fields in the FCI message, for this and other purposes.

The AMA-ticket generated in SSP exchange 21 is transferred to the telecommunications operator's billing system, so that the correct calling subscriber 20 is billed for the service used or product ordered, on the basis of the aforesaid fields in the AMA-ticket.

AMA-ticket 26 can also be used to credit money to the producer of a service and to perform clearing between telecommunications operators. Thus, in the method for adding a billing amount to a telephone bill, a message, e.g. a call attempt, generating a call event permitting the billing event, is sent from SCP database 23 to SSP exchange 21, after which the relevant call event is generated. In addition, a message incorporating the billing data is sent from SSP database 23 to SSP exchange 21 and forms the basis of the generation of an AMA-ticket in SSP exchange

21. Next, the AMA-ticket is transferred to the billing system.

Though the above examples refer to the Internet, the invention can also be applied to transactions carried out through other data networks. The invention can also be applied so that the telephone connection 20 is a mobile phone connection or, for example, an extension of a PBX in a company. One preferred embodiment of the invention can be purchasing by means of a mobile phone incorporating a computer.

The invention can also be applied so that the billing event transmits not only the aforesaid billing information available from the Internet or other data network, but also additional purchase information, such as a more detailed product specification or product description, the vendor's name and address or other information that it is advantageous to transfer to the telephone bill. In this case, SCP database 23, which is informed of the billing event, adds this information to the FCI message 8 sent to SSP exchange 21. The aforesaid additional fields in the FCI message can permit a considerable amount of additional information to be transferred transparently to the AMA-ticket, and thus through the billing system, to create the desired telephone bill. Examples of this include additional lines of text, graphics, illustrations, alphanumerical signs, and barcodes. One possible embodiment for transmitting this additional information is to code the FCI message 8 as eight-bit ASCII symbols, thus adding a line of text, with the desired content for each purchase event, to the purchaser's telephone bill. Such additional lines of text can provide vendor and product information (product specification, product description, etc.).

The invention can also be applied to cases other than intelligent network calls, i.e. to cases in which the call is controlled by the operator's modem pool using traditional methods of call control. Here too, AMA-tickets can be generated in an intelligent telephone network and added to the caller's telephone bill.

Claims

Claims:

1. A method for adding an amount to be billed for orders placed from a data network (25), by means of a telephone network (20, 21, 22, 23), to the telephone bill of the telephone connection used, characterized in that, when the amount is added

- a message to generate a call event, such as a call attempt, permitting the creation of a billing event, is sent from an SCP database (23) to an SSP exchange (21),

- a call event permitting the billing event is generated,

- a message containing the billing information is sent from the SCP database (23) to the SSP exchange (21),

- in the SSP exchange (21), an AMA-ticket is generated on the basis of the billing information contained in the message, and

- the AMA-ticket is transferred to the billing system.

2. A method according to Claim 1, characterized in that the message for creating the call event permitting the billing event is an ICA message.

3. A method according to Claim 2, characterized in that a Continue message is also sent together with the ICA message.

4. A method according to any of Claims 1-3, characterized in that the message containing the billing information is an FCI message.

5. A method according to any of Claims 1-4, characterized in that the call event permitting the billing event is a call attempt to a non-existent telephone number.

6. A method for adding an amount to be billed for orders placed from a data network (25), by means of a telephone network (20, 21, 22, 23), to the telephone bill of the telephone connection used, c h a r a c t e r i z e d in that, when the amount is added

- an SCI message is sent from the SCP database (23) to the SSP exchange (21),

- in the SSP exchange (21), a billing message, containing the tariff data, is generated on the basis of the SCI message,

- the billing message is sent from the SSP exchange (21) to the exchange collecting billing for the telephone connection (20), and

- the billing information is transferred to the billing system from the exchange collecting billing.

7. A method for billing orders placed from a data network (25) through a telephone network (20, 21, 22, 23), in which method

- the telephone connection (20) used by the purchaser is identified,

- the billing request directed to the purchaser from the data network (25) is received, and

- the billing amount is added to the telephone bill of the telephone connection (20) used by the purchaser,

c h a r a c t e r i z e d in that, in the method

- the data network (25) username used by the purchaser is identified, - the telephone connection's (20) identification data, the purchaser's username and the link between them are recorded in a verification database (24),

- on the basis of the username, a billing request received from a data network (25) is identified as requiring targeting to the purchaser,

- the verification database (24) is checked for a link between the username to be billed and the telephone connection (20),

- on the basis of the check, a decision is made whether to accept the billing request, and, if the billing request is accepted, the billing amount is added to the telephone bill of the telephone connection (20) used by the purchaser.

8. A method according to Claim 7, characterized in that, if the billing request is rejected, the sender of the billing request is notified of the rejection.

9. A method according to Claim 7 or 8, characterized in that

- a database containing information on any use limit set for the telephone connection (20) is used as the verification database (24), and

- besides checking for a link between the username and the telephone connection (20), a check is made to ascertain if the use limit permits the billing request to be accepted.

10. A method according to any of Claims 7-9, characterized in that

- a database containing information on any use limit set for the username is used as the verification database (24), and

- in addition to checking for a link between the username and the telephone connection (20), a check is made to ascertain if the use limit permits the billing request to be accepted.

11. A method according to any of Claims 7-10, characterized in that, when the billing amount is added to the telephone bill

- an ICA message is sent from the SCP database (23) to the SSP exchange (21) to generate a call event permitting the billing event,

- a call event permitting the billing event is generated,

- an FCI message containing the billing information is sent from the SCP database (23) to the SSP exchange (21),

- on the basis of the FCI message, an AMA-ticket is generated in the SSP exchange (21), and

- the AMA-ticket is transferred to the billing system.

12. A method according to any of Claims 7-10, characterized in that, when the billing amount is added to the telephone bill

- an SCI message is sent from the SCP database (23) to the SSP exchange (21),

- in the SSP exchange (21), a billing message containing the tariff data is generated on the basis of the SCI message,

- the billing message is sent from the SSP exchange (21) to the exchange collecting billing for the telephone connection (20), and

- the billing information is transferred to the billing system from the exchange collecting billing.