KR20010043117A - Method and device in a computer network - Google Patents

Abstract

Assigning a cost for using each application program by the charging unit, providing a transaction server suitable for receiving and storing information related to the use of each application program, the charging unit between the application program and the transaction server There is provided a charging method for goods and services provided by an application program over a data network comprising providing an application program interface suitable for transferring information about the cost of each application from the application program to a transaction server. . Means for receiving and storing information about costs registered for a customer while using an application, received in the form of a charging unit, and means for calculating the cost of the session by a valid currency. Is disclosed.

Description

METHOD AND DEVICE IN A COMPUTER NETWORK}

The use of credit cards and other types of payment cards is increasing.

The credit card makes it possible for the owner to purchase and pay later when the invoice is received. When using such a card, the cost per transaction is relatively high. Thus, such a card is not suitable for transactions involving small amounts of money.

For a small amount of money, a cash card can be used. Since this card has a lot of money saved, it can be used to pay for small purchases. Since this card is equal to the amount saved on the card, this card is only convenient for paying small sums of money. Typically, there is always a limit on the amount of money that can be saved on a card. The card payment is the payment of the corresponding amount, and no interest is paid on the money saved on the card. In addition, when there is no money stored in the card, the card must be saved again in the form of a terminal that can be used only in a specific place. In addition, cash cards cannot process user specific information, such as discounts that may be the user's rights.

This means that the person using these services must pay in different ways for different services, using a number of different cards.

The present invention relates to a method and apparatus for payment in a data network, and more particularly, to a method and apparatus for payment over an Internet Protocol (IP) based network such as the Internet.

1 schematically illustrates the invention;

Figure 2 illustrates in more detail the units included in the present invention.

3 and 4 illustrate signaling schemes occurring between a user and components of a system.

5 is a flowchart of steps taken to provide a service in a network.

It is an object of the present invention to provide a method and apparatus for enabling all kinds of transactions with payment.

This is accomplished by a charging method in a data network in which goods and / or services can be purchased according to the invention, which method comprises:

Providing an application program located at a node in the network for each application;

Designating, by the charging unit, a cost for using each application program;

Providing a network with a transaction server suitable for receiving and storing information relating to the use of each application program;

Between each application program and a transaction server, providing an application program interface suitable for transferring information on the cost of each application from an application program to a transaction server by a charging unit.

The object of the invention is also achieved in a device which enables charging in a data network comprising at least one application program which incurs a cost to a user, said device comprising:

Memory means for holding information about a customer and a cost of using said application program;

Means for receiving and storing information regarding costs registered for the customer during a session in which the customer uses the application, received in the form of a charging unit;

Means for storing the information;

Means for calculating the cost of the session by a valid call.

This method and apparatus allows a connection to be established for a period in which billing information can be sent many times over a regular or irregular period. In this way, the costs associated with initial setup of the connection, user authentication, and the like do not occur each time the cost is registered. This allows for low cost registration without the addition of high fraudulent claims. At the same time, very high costs can also be registered.

One charging unit can be sent for each time unit for which the duration of one time unit can be selected individually for each type of service or item, or multiple charging units can be assigned to one particular service or item. Can be sent at a time. In this way, the use of some programs may be charged. It is also easy to change the price of using the program.

For each transaction, the contract specifies parameters that accompany the transaction, including the identification and price of the buyer, seller, and type of service or item being purchased, and stores the parameters at or in connection with the transaction server that specifies the contract. do. The contract may also include a maximum price for the session as determined by the user.

The cost for each session is calculated by the valid currency and information about the cost is sent to the billing unit.

The invention will be explained in more detail below with reference to the accompanying drawings.

1 shows schematically a system component comprising a transaction server 1 according to the invention. The transaction server 1 is used to monitor the use and / or purchase of the service. The third and fifth applications are connected to the transaction server 1 via seventh and ninth application program interfaces (APIs), respectively. The applications 3, 5 may be connected directly to the transaction server 1 via the API, like the first application 3, or may be connected to the transaction server 1 via the data network 11. In the preferred embodiment, the Internet is used as the data network 11. The database 13 is found at or in association with a transaction server that stores user data and other information. The transaction server 1 is also connected to one or more charging units that handle the actual payment from the customer. In addition, a plurality of customer terminals 17 and 18 are also connected to the data network 11. The terminal 19 can also be directly connected to one or more applications 5. The customer terminals 17, 18 and 19 may be dedicated terminals found in people's homes, such as dedicated computers or public terminals. In addition, a security unit 21 which handles the security of the transaction is found at or in connection with the transaction server.

As discussed in more detail below, any type of application 3, 5 may be connected to transaction server 1.

From the people's dedicated terminal 17, a customer may order goods, for example from a catalog, make a call via an Internet telephone network or retrieve information or a program from the Internet 11. A public terminal can be used for example to pay at a gas station or similar store. The charging for these different types of applications will be described in more detail below.

The transaction server 1 and the units it comprises will be described in more detail with respect to FIG. 2.

The charging principle according to the present invention includes a charging unit called a tick. The charging unit or tick can be freely selected for each application as a suitable value for the application. When the customer uses the service, the application program 3, 5 sends a number of ticks to the transaction server 1 via the API 7, 9. For some services, for example, one tick for a telephone can be sent for each time unit. The duration of the time unit may vary, for example, at different times or for the type of call made. Typically, short time units can be used for long distance calls rather than local calls so the ticks will be sent more often for long distance calls. For other applications, multiple ticks can be sent simultaneously. For example, if a customer orders an item from a catalog, the value of the tick may be 10 pence. If the price of the product is £ 10, 100 ticks will be sent from the application to the transaction server. To pay for power or water consumption, multiple ticks can be sent for each unit (watt or volume of water).

For example, if the customer pays for each time the application is used, one or more ticks may be sent to the transaction server when the customer starts the application or when the customer stops using the application.

The transaction server 1 or database 13 holds information about the value of the tick for each application. Transaction server 1 or database 13 may also retain other user information, for example, if the customer is entitled to a discount when using a particular application.

2 shows in more detail the units of the system according to the first embodiment of the system. As noted above, a transaction server 101 is provided that includes one or more servers 107 connected to a transaction manager, a database 105, and an internet service provider 109. Internet service provider 109 provides a transaction service to a content provider (not shown). Of course, service provider 109 may also be a content provider. The server 107 handles the communication with the Internet service provider 109, which includes searching for service programs, updating billing systems, or protocol translation services.

According to a preferred embodiment, as much logic as possible is stored in transaction server 103 to make the processing of the application program easier. For example, to keep the application small and easy to manage, the charging information is placed in the transaction manager 103 instead of the application program itself. Transaction managers can also communicate with other units.

The database 105 is used to store information about charging, sellers, customers, and the like. Each service has a entry value and a tick value for the associated service in the database that specifies the price of the service by tick. The customer information included in the database 105 may include, for example, information about any discounts that may be the customer's rights and information about the maximum amount a customer can spend.

Transaction server 101 also includes payment manager 113. The payment manager 113 resolves the communication with the unit that handles the payment from the customer, represented by the billing unit 115 in FIG. 2. These different billing units of different types may be included, such as banks and / or credit card companies.

In addition, the transaction manager 103 is connected to the first 117 and second 119 application programs through the first 121 and second 123 APIs, respectively. As shown in FIG. 1, this connection may be directly or through a data network. The procedure for providing an application program to the network will be described below.

The API can be linked to any application that requires a charge. The API cannot interfere with what is being charged or how much it is being charged, and is simply register ticks as described above. The API may also be suitable for sending incoming bounces to content providers whose services of content providers are being used.

Web browser 127 allows system customers to order services and products offered over the Internet. The browser 127 can be connected to the billing unit 115, so that the browser can start prepaid if required.

Billing unit 115, payment manager 113, transaction manager 103 and internet service provider 109 are connected to one or more certification authorities 129. The certification authority 129 issues a user identification and can therefore query for a special user identification when required.

Figure 3 schematically shows the signaling occurring between the customer and the unit of the system according to the first embodiment of the invention. The customer and each unit are shown by a vertical line between the arrows shown to indicate signaling. The units are application APPL, APL, application module AUTH, transaction server (TS) and database (DB). The authentication module can be realized as part of an API, but is shown here as an independent set of functions. In this way, any available product that handles the authentication function can be used. Authentication modules and other security functions will be described in more detail below.

S31: The customer first starts starting the application. This is accomplished by opening an appropriate Internet site or page and ordering the service in a manner known in the art, if an item is ordered or a call is made over the Internet. This is accomplished, for example, by customers who identify themselves and initiate a purchase when a payment is made at a store or gas filling station.

S32: The signal is sent from the application to an API that includes a request for start information such as application identification, information about the customer, and information about cost per tick.

S33: The API establishes a session with the transaction server according to, for example, a Secure SocKet Layer (SSL) protocol.

S34: The transaction server requests, for example, information from the database about customer and cost per tick application.

S35: The database returns the requested information to the transaction server.

S36: The transaction server returns status information about the session, including, for example, cost per tick and customer contract, which will be described in more detail below.

S37: The API requires customer authentication.

S38: The authentication module starts a conversation with a customer that includes a prompt for identification. Identification can be performed in any method known in the art, as discussed in connection with security functions. Other information about the transaction may also be entered, such as the type of service or product desired, the maximum price, and the like.

S39: The user inputs the above-described information transmitted to the authentication module.

S40: The authentication module returns to the API a certificate that queries the signed user contract and whether the customer has approved.

S41: The API sends the signed user contract and certificate to the transaction server.

S42: The transaction server starts a session and sends information to the database for a given customer and application.

S43: The transaction server looks up the status of the signed customer contract and certificate and sends an approval notification to the API.

S44: The API sends an approval notification to the application. The application starts. This means, for example, that a program or document has been downloaded from a catalog to a customer whose order for the item has been registered.

S45: The application sends a tick to the API when requested. The first tick may be sent when the application starts or in the next step.

S46: The API sends a tick to the transaction server.

S47: The transaction server inserts a tick for the session in question in the database. It can be inserted once or several times at regular or irregular intervals.

S45-S47 can be repeated many times.

S48: When the application ends, a stop signal is sent from the application to the API.

S49: Go one or more ticks as much as possible and the message is sent from the API to the transaction server.

S50: The stop and final ticks are also registered in the database.

S51: The transaction server queries the API if the session is over.

S52: The API queries the application if the session ends.

For some applications, for example, multiple ticks may be sent in one burst at the end of a transaction, corresponding to the amount paid when paying at the store. For other applications, for example, multiple ticks may be sent for each liter of gas when refueling.

Confirmation is sent from the program manager to the API, and from the API to the application.

In the above, only appropriate signals which illustrate the idea of the invention are included. Of course, other signals, such as sync signals, can also be transmitted at any stage.

The user contract specifies valid data for the transaction. User identification and application are specified. For example, the cost is specified by the cost of one tick and the time interval between ticks, cost per time period, or overall cost. The user can also specify the maximum cost. The user contract can be stored by the user and is always stored on or in connection with the transaction server. As with the method of user identification, other data may likewise be specified. In this way, some transactions can be queried at a later stage if necessary.

4 illustrates a signaling scheme that occurs according to a second embodiment of the present invention in which all ticks are transmitted simultaneously to the database. For example, when a web server is involved in a session, this will be more secure than connecting for a long time. Negotiation of authentication and contract can be performed in the same way as in FIG. 3 and thus not shown in FIG. 4.

S62: The application sends a signal to the API that includes information about the customer and the application and the number of ticks transmitted.

S63: The API sends application and customer information to the transaction server.

S64: The transaction server returns status information about the session.

S65: If applicable, the API sends a signed user contract, customer data, and multiple ticks to the transaction server.

S66: The transaction server stores information about the new session in the database.

S67: The transaction server sends the application and customer information to the database.

S68: The transaction server stores the appropriate number of ticks in the database.

S69: The transaction server ends the session in the database.

S70: The transaction server sends state information to the API.

As mentioned above, user authentication can be performed in a number of different ways, using passwords, smart cards, soft cards, voice recognition, or other methods known in the art. The security function may be realized as an integral part of the API, but it may also be desirable to add the authentication function as a standalone package. In this way, each content provider can select the appropriate authentication function for the application in question. Of course, the security function can be omitted entirely, for example in a network where access is restricted.

For security, between the user and the application, the information transmitted between the units is encrypted. This is realized using conventional prior art cryptography methods appropriate to the required level of security. A common way to encrypt information between a customer and an application is to work with a public cryptographic key to use a dedicated cryptographic key specific to the customer.

When charging data is stored in the database, the charging data can be sent to one of the billing units to ensure that payment from the customer is received. This can be done by any method known in the art. For example, a customer may have a prepaid account, or may be charged to a customer at fixed time intervals or when a billed amount reaches a certain limit.

5 is a flow chart of the steps required to provide an application in the system.

Step S1: The application program is designed. The design of the application program depends on the type of application, as discussed below.

Step S2: The API is queried and linked to the application.

Step S3: The cost of using the application is specified and stored in the database. The cost is specified by the cost for each tick and a number of ticks per time unit or item.

Step S4: The program is made available on the network. This means, for example, delivering a program to a customer for storage on a web server or for installation on a customer's computer.

The design of the application program and the design of the API depend on the type of application. When a product is ordered from a catalog, information about the item and the price of the item is preferably provided to the customer on a web page that allows the customer to provide information to the transaction server via an API. This information includes customer identification, identification of the item to be purchased. Alternatively, information about the item may be provided in a printed catalog, in which case the website only needs to include a function that enables identification and designation of the desired item.

According to the invention, it is also possible to include payment for electricity or water consumption, for example. In this case, consumption should be measured in a known manner, and information about it is sent to the transaction server. This information may be sent as multiple ticks when some amount is consumed or at certain time intervals.

Claims (12)

A charging method in a data network in which goods and / or services can be purchased, Providing an application program (3, 5) located in a node in the network for each application: Specifying the cost for using each application program by the charging unit: Providing a network with a transaction server (1; 101) suitable for receiving and storing information relating to the use of each application program (3,5): Provides an application program interface (7, 9) suitable for transferring information on the cost of each application from the application program to the transaction server by a charging unit between each application program (3, 5) and transaction server (1; 101) A charging method in a data network comprising the steps of: The method of claim 1, Sending one charging unit for each time unit, wherein the duration of the time unit can be individually selected for each type of service or item. The method according to claim 1 or 2, 6. A method of charging in a data network, comprising transmitting a plurality of charging units for one particular service or item. The method according to any one of claims 1 to 3, And transferring the value of the charging unit from the transaction server to the application when starting the session. The method according to any one of claims 1 to 4, For each transaction, the steps in which the contract specifies parameters, including the identification and price of the buyer, seller, and type of service or item purchased, and the parameters are stored in or in connection with the transaction server specifying the contract. The method of charging in a data network, comprising the steps of: The method according to any one of claims 1 to 5, And enabling the customer to specify a maximum price for use of the application. The method of claim 6, Including the maximum price in the contract. The method according to any one of claims 1 to 7, Calculating the cost for each session by a valid currency; And transmitting information about the cost to a billing unit (127). An apparatus (1; 101) which enables charging in a data network comprising at least one application program (3,5) incurring a cost to a user, Memory means (13; 105) for holding information on the customer and the usage cost of the application program (3, 5); Means (103) for receiving and storing information relating to the cost for which the customer is registered for the customer during a session using the application, received in the form of a charging unit; Storage means (13; 105) for storing the information; Means (103) for charging in a data network comprising means (103) for calculating the cost of said session by a valid currency. The method of claim 9, Means for negotiating a contract with a customer and storing the contract results in a database (103). The method of claim 9 or 10, And storage means (13; 105) for storing customer specified information and means for adjusting (e.g., discounting) the price in accordance with the information. In the data network, At least one device (1; 101) according to any one of claims 9 to 11; A data network comprising an application program (5,7) and an API (7,9) for transferring information between the device (1; 101).