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

Abstract

A charging method for goods and services provided by application programs through a data network is suggested, comprising the following steps:specifying the cost for using each application program in terms of charging units;providing a transaction server adapted to receive and store information related to the use of each application program;providing an application program interface between each application program and the transaction server, adapted to transfer information regarding the cost of each application, in terms of charging units, from the application program to the transaction server. A device for carrying out the method is disclosed, comprising means for receiving and storing information about the cost to be registered for a customer for using an application, said information being received in the form of charging units;means for calculating the cost of said session in terms of a valid currency.

Description

METHOD AND DEVICE IN A COMPUTER NETWORK TECHNICAL FIELD The present invention relates to a method and device for making payments in a data network, and particularly for making payments through a network based on Internet Protocol (IP) such as example, Internet. DESCRIPTION OF THE RELATED TECHNIQUE Credit cards and other types of payment cards are being used more and more. A credit card allows its owner to make purchases and pay for them later, when an invoice is received. The cost per transaction is relatively high when these cards are used. Therefore, these cards are not suitable for transactions involving small amounts. In the case of small amounts, a cash card can be used. An amount of money is stored on the card that can be used to pay for small purchases. Since this card is equal to the amount of money stored in it, - it can be used only for small amounts of money. Frequently, there is a limit as to the amount of money that can be stored on the card at any given time. The loss of the card means the loss of the corresponding amount of money, and no interest is offered on the money stored on the card. Likewise, when the card is exhausted it has to be recharged with money in terminal types available only in certain places. The cash card can not handle user-specific information, such as discounts to which a user may be entitled. This means that a person who employs these services must use several different cards and pay in different ways for different services. COMPENDIUM OF THE INVENTION It is an object of the present invention to offer a method and apparatus that allow the payment of any type of transaction. This is achieved in accordance with the present invention through a collection method in a data network through which articles and / or services can be purchased, the method comprising the following steps: providing an application program for the application, said application programs are localized in nodes in the network; specify the cost of using each application program in terms of collection units; providing a transaction server in the said transaction server is adapted to receive and store information regarding the use of each application program; provide an application program interface between each application program and the transaction server, said application program interface in adapted to transfer information regarding the cost of each application, in terms of collection units, from the application program to the transaction server. The object is also achieved in a device to allow charging in a data network, said data network comprises at least one application program whose use is charged to the user, said device comprises: a memory device containing information as to customers, and the cost of using that application program; a device for receiving and storing information regarding the cost to be recorded for a client for a session in which the client uses an application, said information is received in the form of collection units; means of storing said information; means to calculate the cost of such sessions of terms of a valid currency. This method and device allow the establishment of a connection for a period of time during which billing information can be transmitted several times at regular or irregular intervals. In this way, the cost associated with the initial establishment of the connection, user authentication, etc. It does not happen every time a cost is recorded. This allows for a low cost registration without adding additional high charges. At the same time, very high costs can also be recorded. A collection unit can be transmitted for each unit of time, the duration of a unit of time can be selected individually for each service time or article, or several collection units can be transmitted at one time for a service or article particular. In this way you can charge any program. It is also easy to change the price of using a program. You can specify a contract for each transaction, said contract specification parameters belong to the transaction, including buyer identification, vendor and type of service or purchased item, and price, and that contract can be stored in the transaction server or in relation to said transaction server. The contract can also include a maximum price for the session, defined by the user. The cost of each session is calculated in terms of a valid currency and the information regarding the cost is transferred to a billing unit.

BRIEF DESCRIPTION OF THE DRAWINGS The invention will now be described in more detail with reference to the drawings, in which: Figure 1 is a schematic presentation of the invention; Figure 2 is a more detailed representation of the units that make up the invention; Figure 3 shows the signaling that it makes between the user and the system components; Figure 4 shows the signaling that is carried out according to the second embodiment of the invention; and Figure 5 is a flowchart of the steps taken to provide a service in the network. DETAILED DESCRIPTION OF THE MODALITIES Figure 1 is a general schematic presentation of the components of a system comprising a transaction server 1 according to the invention. The transaction server 1 is used to monitor the use of the services and / or the purchases made. To the transaction server 1 a first application 3 and a second application 5 are connected through a first application program interface 7 and a second application program interface 9 (API), respectively. The applications 3.5 can be connected either directly to the transaction server 1 through the API, as the first application 3, or through a data network 11. In a preferred embodiment, the Internet can be used, as data network 11 A database 13 is located on the transaction server or is connected to said server d transaction to store user data and other information. The transaction server 1 is also connected to one or more collection units 15 that handle the actual payments of the clients. Several client terminals 17,18 are also connected to the data network 11. The terminals 19 can also be directly connected to one or more applications 5. The client terminals 17,18,19 can be private terminals found in the address of the clients. people, for example personal computers or public terminals. A security unit 21 for managing the security of the transactions is also located on the transaction server or connected to said transaction server. Any type of application 3.5 can be connected to transaction server 1, as will be discussed in more detail below. From your private terminal 17, a customer can for example order items from a catalog, can make a call through the Internet telephony network or can retrieve information or programs from the Internet 11. Public terminals can used for example, to make payments in a store, a gas station or similar. The charges that correspond to these different types of applications will be described in greater detail below. The transaction server 1 and the units that comprise it will be described in greater detail with respect to Figure 2. The charging principle in accordance with the present invention includes a charging unit that is known as a tick. The collection unit, or brand, can be independently selected for each application as an appropriate value for the application. When a client uses a service, application program 3.5 sends a number of marks through API 7.9 to transaction server 1. For some services, for example telephony, a mark can be sent for each unit of time. The duration of the unit of time may vary, for example, at different times or depending on the type of call that is made. Typically, a shorter unit of time will be used for long distance calls than for local calls in such a way that the marks are sent more frequently for long distance calls. For other applications, a number of brands can be sent at one time. For example, without a customer requesting an item from a catalog, the value of the brand can be 10 pence. If the price of the item is 10 pounds, then 100 marks will be sent from the application to the transaction server. To pay for electricity or water consumption, you can send a number of marks for each unit (watt, or volume of water). One or several brands can be sent to the transaction server when a client starts an application, for example, if the client must pay each time the application is used, or when the client stops using an application. The transaction server 1, or the database 13, keeps information regarding the value of a brand for each application. The transaction server 1 or the database 13 may also retain other user information, for example, if a customer is entitled to a discount when using a particular application. Figure 2 shows the system units according to a first system mode with more details. As above, a transaction server 101 is provided, comprising a transaction manager, a database 105, and one or more servers 107 connected to an Internet service provider 109. The Internet service provider 109 offers the service of transaction to content providers (not illustrated). Of course, the service provider 109 can also be a content provider. The server 107 handles communication with the Internet service provider 109, including recovery of service programs, updating of the billing system, or protocol translation services. In accordance with a preferred embodiment the largest possible amount of logic is stored in the transaction manager 103, to make the handling of the transaction programs easier. For example, to keep applications small and easy to manage, the collection information is placed in the transaction manager 103 instead of being placed in the application program itself. The transaction manager 103 also establishes communication with the other units. The database 105 is used to store information regarding collection, vendors, customers, etc. Each service has an entry in the database that specifies the service price in terms of brands, and the value of a brand to the service in question. The customer information found in the database 105 may include, for example, information as to discounts to which the customer is entitled, and a maximum amount that the customer may spend. The transaction server 101 also comprises a payment manager 113. The payment administrator 113 is responsible for communication with the units handling the payment from the customers, represented by a billing unit 115 in figure 2. Several units of this type 115 or of different types, for example banks and / or credit card companies can be included. The transaction manager 103 is also connected to a first application program 117 and a second application program 119 through a first API 121 and through a second API 123, respectively. As shown in Figure 1, the connection can be direct or through a data network. The procedure for supplying an application program to the network will be discussed below. The API can be linked to any application that requires collection. The API should not interfere with what is being charged or the amount charged, but should simply register trademarks as described above. The API may also be adapted to send a receipt to content providers in the sense that their service is being used. Clients have at their disposal a network scanner 127 of the system to request services and articles provided through the Internet. The browser 127 may be connected to the billing unit 115 such that the browser may initiate an advance payment if required.

The billing unit 115, the payment administrator 113, the transaction manager 103 and the Internet service provider 109 are connected to one or more certification authorities 129. The certification authority 129 issues user identities and can therefore verify the identity of a particular user when required. Figure 3 is an overview of the signaling that occurs between the client and the system units according to the first embodiment of the invention. The client and each of the units are represented by horizontal lines, between which arrows are drawn to represent the signaling. The units are: the APPL application, the API, an AUTH authentication module, the TS transaction server and the OB database. The authentication module can be implemented as part of the API, but it is shown here as a separate set of functions. In this way, any available product can be used for management authentication functions. The authentication module, and other security functions will be described in more detail below. S31: a client first starts an application. If you wish to order an article, or if you wish to make a call, through the Internet, this is done in accordance with a preferred modality, by opening an appropriate Internet site, or by appropriate Internet page and through the request for a service in the manner known in the art. If a payment must be made, for example, in a warehouse or in a gas station, these are made by the client identifying themselves and starting the process. acquisition. S32: A signal is sent from the application to the API, which includes boot information, for example application identity, information regarding the client and request of information regarding the cost per brand. S33: The API establishes a session on the transaction server, for example, in accordance with the Secure Socket Layer (SSL) protocol. S34: The transaction server requests information from the database, for example, information regarding the client and regarding the cost per brand of the application. S35: The base returns the requested information to the transaction server. S36: The transaction server returns the status information in the session, including, for example, the cost per brand and a customer contract, which will be described in more detail below. S37: The API requests a client authentication. S38: The authentication module initiates a dialogue with the client, including an identification request. The identification can be carried out in any manner produced in the art, in accordance with what has been said in relation to the security functions. Other information regarding the transaction can also be entered, such as the type of service or items desired, the maximum cost, etc. S39: The user enters the aforementioned information which is transferred to the authentication module. S40: The authentication module returns the signed user contract and a certificate verifying that the client has been accepted, to the API. S41: The API sends the signed user contract and the certificate to the transaction server. S42: The transaction server starts the session and sends information to the database for a given client and a given application. S43: The transaction server verifies the status of the signed customer contract and the certificate and transmits a notice of acceptance to the API. S44: The API sends the acceptance notice to the application. The application starts. This may imply, for example, that a program or a document is downloaded to the customer, that an order for an item in a catalog is registered. S45: The application transmits marks to the API when it is required. The first mark can be transmitted when the application starts, or later.

S46: The API sends the marks to the transaction server.

S47: The transaction server inserts marks for the session in question in the database. This can be carried out once or several times at regular or irregular intervals, S45-S47 are repeated an arbitrary number of times. S48: When an application ends, a suspension signal is sent from the application to API. S 9: A message possibly with one or several marks is transmitted from the API to the transaction server. S50: The suspension and the final marks are also registered in the database. S51: The transaction server verifies, in the API, that the session has not ended. S52: The API verifies in the application that the session has ended. For some applications, for example, when a payment is made in a store, several brands can be sent, corresponding to the amount to be paid, only once at the end of the transaction. For other applications such as, for example, when a vehicle tank is filled, a number of marks can be sent for each liter of gasoline. A confirmation is sent from the program administrator to the API and from the API to the application.

In the foregoing, only relevant signals were included to illustrate the idea of the present invention. Obviously, other signals such as synchronization signals can also be transmitted in other stages. The user contract specifies the valid data for the transaction. The user identity and the request is specified. The cost is specified, for example, in terms of the cost of a brand and the time interval between the brands, the cost per period time or the total cost. The user can also allow the specification of a maximum cost. The user contract can be stored with the user and is always stored in the transaction server or connected to the transaction server. Other data such as, for example, the user identification method may also be specified. In this way, any transaction can be verified at a later stage, if necessary. Figure 4 shows the signaling that is carried out according to the second embodiment of the invention, in which all the marks are transmitted at once to the database. For example, when a network server is involved in the session, it can be more secure than having a connection for a long period of time. The authentication and negotiation of the contract can be carried out in the same way as in Figure 3 and therefore they are not shown in Figure 4. S62: The application sends a signal to the API, which comprises information regarding the client, as to the application and regarding the number of brands to transmit. S63: The API sends the application and client information to the transaction server. S64: The transaction server returns the status information regarding the session. S65: The API sends a signed user contract, if applicable, client data and a number of marks to the transaction server. S66: The transaction server stores information regarding the new session in the database. S67: The transaction server sends client and application information to the database. S68: The transaction server stores the appropriate number of marks in the database. S69: The transaction server ends the session in the database. S70: The transaction server sends information about the API. As mentioned above, user identification can be effected in several different ways, using keys, smart cards, soft cards, speech recognition or in any other manner known in the art. The security functions may be implemented as an integral part of the API, but it may also be desirable to add the authentication functions as a separate package. In this way each content provider can select authentication functions that fit the application in question. Evidently, security functions can be omitted, for example, in a network in which access is limited. For security reasons, the information transmitted between the user and the application, and between the units, is encrypted. This can be done using an appropriate cryptography method of the prior art according to the required level of security. A common method for encrypting information between the client and the application is through the use of a private cryptography key, specific to the client, in combination with a public cryptographic key. When the collection data have been stored in the database, they can be transferred to one of the billing units, which ensures that the payment is received from the customer. This can be effected in any of several ways known in the art. For example, a customer may have an account, to which money is paid in advance, or the customer may be billed at fixed time intervals or when the amount receivable reaches a certain limit. Figure 5 is a flowchart of the steps required to provide an application in the system. Step SI: The application program is designed. The design of the application program depends on the application team, as will be discussed later. Step S2: The API is recovered and linked to the application. Step S3: The cost of using the application is specified and stored in the database. The cost is specified in terms of a cost for brands and a number of brands per unit of time or element. Step S4: The program is available on the network. This can mean, for example, storage on a network server or delivery of the program to customers for installation on their computers. The design of the application program and the API will depend on the type of application. If you must order items from a catalog, you must provide information regarding the articles and in relation to their price to the client, preferably on the website, which should also allow the client to present the information to the server. transaction through the API. This information must include customer identification, identification of the items to be acquired. Alternatively, the information regarding the elements can be provided in a printed catalog, in which case the website only requires to have functions to present the identification and specifications of the desired articles. In accordance with the present invention it is also possible to include payments such as, for example, for electricity or water consumption. In this case, the consumption must be measured in some known way, and the information regarding this must be transmitted to the transaction server. The information can be transmitted as a number of marks 10 when a certain amount has been consumed or at certain time intervals. fifteen twenty rittMüníiiafa-

Claims (1)

1. CLAIMS A method for charging in a data network through which articles and / or services can be purchased, said data network comprises at least one application program (3, 5) in a node in the network, a server of transactions (1, 101) placed to receive and store information regarding at least one registered client in the network in relation to the use by the client of each application program (3,5), and a program interface of application (7,9) between said application program (3,5) and the transaction server (1; 101), said method comprises the following steps: the client activates the application program; the cost that comes from the use of the application program is transferred from the application program to the transaction server through the interface of the application program during an ongoing session, in the form of collection units, as they arise in the program of application, the collection units are accumulated in the transaction server. n method according to claim 1, characterized by the transmission of a charging unit for each unit of time, the duration of a unit of time can be selected individually for each type of service or article. A method according to claim 1 or according to claim 2, characterized by the transmission of a number of collection units for a particular service or article. n method according to any of claims 1-3, characterized by transmitting the value of a charging unit from the transaction server to the application at the beginning of a session. n method according to any of the preceding claims, characterized by the specification of a contract for each transaction, said contract specifies parameters pertaining to the transaction, including identification of the buyer, seller, and type of service or item purchased, and price, and for the storage of said contract in the transaction server or connected to said server. A method according to any of the preceding claims, comprising the step of receiving and informing the application program from the transaction server about the value of a feeder unit for the application program, calculating a cost for the application program. use of the application program based on this information and inform the client about the cost. A method according to any of the preceding claims, characterized in that it allows a client to specify a maximum price for the use of an application. A method according to claim 6, characterized in that it includes said maximum price in the contract. n method according to any of the preceding claims, characterized by the steps of: - calculating the cost of each session in terms of a valid currency; - transfer information regarding the cost to a billing unit (127). n device (1; 101) to allow charging in a data network, said data network comprises at least one application program (3.5) whose user costs are absorbed by the user, said device comprises - a memory means (13/105) that contains information regarding customers and cost of use of said application program (3, 5); - means (103) to receive and store information regarding the cost to be recorded for a customer for a session in which a customer uses an application, said information is received in the form of collection units; - storage unit (13; 105) for storing said information; - means (103) to calculate the cost of said session in terms of a valid currency. A device according to claim 10, characterized in that it comprises means (103) for negotiating a contract with a client and storing the resulting contract in a database. A device according to claim 10 or according to claim 11, characterized in that it comprises a storage medium (13).; 105) to store customer-specific information and a means to adjust the price in accordance with this information, for example, offer discounts. a data network, characterized in that it comprises: - at least some devices (1; 101) according to any of claims 9-11; - an API (7,9) to transfer information between an application program (5,7) and said device (1; 101).