WO2005015515A2

WO2005015515A2 - Method and system for carrying out payment transactions in a computer-based communication network

Info

Publication number: WO2005015515A2
Application number: PCT/EP2004/008910
Authority: WO
Inventors: Thomas Schäfer; Timo Grammer; Marc Drockur
Original assignee: Web.De Ag
Priority date: 2003-08-08
Filing date: 2004-08-09
Publication date: 2005-02-17
Also published as: EP1654713A2; WO2005015515A3

Abstract

The invention relates to a method and a system for carrying out payment transactions in a computer-based communication network, which comprises a terminal user unit, a supplier computer system of a supplier of chargeable content data and a payment computer system of a service provider for carrying out payment transactions by way of payments in kind. According to said method and system, order data are transmitted from the supplier computer system to the payment computer system, which data comprise cost data indicating the costs for the desired access to the content data and access data specifying how the content data can be accessed.

Description

METHOD AND SYSTEM FOR IMPLEMENTING PAYMENT PROCESSES IN A COMPUTER-BASED COMMUNICATION NETWORK

Field of the Invention

The present invention relates to payment processes in a computer-based communication network, such as. B. the Internet. In particular, the present invention relates to such payment processes in connection with small amounts of money and the processing of access to content data subject to a charge.

Background of the Invention

A large amount of data is available in computer-based communication networks. Traditionally, such data could be accessed free of charge. However, it is increasingly necessary to pay for access to data. This is especially true for the internet.

In order to process payment processes associated with paid access to data, special approaches tailored to computer-based networks and in particular the Internet are known. So-called micropayment systems and processes are used, among other things. The term micropayment can be traced back to the fact that usually only low costs are billed for paid access to data.

In order to pay for paid access to data, it is known that a user of an end user unit, such as. B. a personal computer, the provider of data to be accessed for a fee, a credit card number or an account number that is used by the provider to debit the amount due. The data required for debiting (e.g. credit card number, account number, etc.) is usually transmitted from the end user unit to a computer system of the provider. This poses a security risk, since data transfers in computer-based networks and especially on the Internet allow unauthorized access by third parties. Another problem with this payment method is that the provider receives information about the user who wants to use the provider's chargeable data. This can be undesirable, for example, for data protection reasons or from the user's perspective.

In order to solve these problems, it is known to process payment processes in connection with paid access to data via a service provider that is independent of the provider. Payment processes can be carried out in such a way that security-relevant data and personal data are only communicated or known to the service provider responsible for carrying out payment processes. If a payment process required for paid access to data has been successfully completed, the provider of the data is provided with the corresponding information. On the basis of such data, the provider can determine that the required costs have been paid, which ensures that the provider does not allow access to his data without corresponding payment.

In order to carry out payment processes through a service provider separate from the provider, it is necessary to provide the service provider with information about costs incurred in the case of a data access that is subject to a charge.

It is possible for the service provider to determine the costs on the basis of the amount of data or the data transmission duration of the data which is to be accessed for a fee. This procedure is used in particular when the service provider provides not only payment processes but also the data that are to be accessed for a fee. This is the case, for example, if the desired data are not transmitted directly from the provider's computer system to the end user unit, but rather to the end user unit via a computer system of the service provider. This type of cost determination is not possible if the service provider is only responsible for the execution of payment processes, but should not provide any data.

It is also possible to determine the costs for paid data access based on different price categories. For different data (e.g. amount of data, content, etc.), the provider can tell the service provider which price category to use. The service provider then determines the corresponding price category before accessing chargeable data.

A disadvantage of known approaches, such as. B. the two approaches mentioned above, is that the service provider must determine the costs. For this purpose, components have to be provided and operated accordingly, which entails costs for the service provider.

To eliminate this disadvantage, it is e.g. It is known from DE-A-10058835 that the user who wants to access the chargeable data provides the service provider with information about the costs incurred. It is necessary for the provider to check after carrying out a payment process whether the amount paid by the user is sufficient for the paid access in order to avoid that the user pays too little, for example due to an indication of an amount that is too low. Such approaches are time-consuming and prone to errors due to the increased number of data transfers between the user, the provider and the service provider.

In order to prevent a user who wants to use chargeable data from paying for each access, it is known not to allow the user direct access to the desired data of the provider. Instead, the desired data is transmitted from the provider to the service provider, who then provides the data to the user once for each payment process or for a specific period of time. However, this leads to the problems mentioned above due to the provision of data by the service provider.

Object of the invention

The object of the present invention is to solve the above-mentioned problems of the prior art. In particular, it is the object of the present invention to make payment processes in a computer-based communication network simpler, more variable and more secure.

Brief description of the invention For this purpose, the present invention provides a method for carrying out payment processes in a computer-based communication network, which has the features of claim 1, and a system suitable for carrying out the method, which has the features of the subordinate claim.

Accordingly, a method for carrying out payment processes on the Internet is proposed with an end user unit, a provider computer system of a provider of fee-based content data and a payment computer system of a service provider for processing payment processes by means of monetary benefits, in which, in a first step, order data from the provider or the provider computer system are transferred to the payment computer system, the cost data which indicate costs incurred for a desired access to the content data, and the access data which determine how to access the content data, in the course of which, in a second step, Internet addresses are generated which target the payment computer system specify and contain the cost data and at least part of the access data of the order data in encrypted form, in which in a third step the Internet addresses as target links, in particular as Hyperl inks, are integrated into a website, in particular in websites, the provider or the provider computer system, in which, in a further step, individual of the chargeable content data are selected by activating the corresponding target link by the user of the end user unit, in particular by clicking the hyperlinks in a browser application, whereby in a subsequent step the user is forwarded to the payment computer system, in which the payment process for the content data selected by the user is processed in a further step, and in which the user is allowed access to the paid content data in a subsequent step ,

In addition, a system is proposed which is suitable for carrying out the method and which has the features of the independent claim.

These measures according to the invention create a method and a system for carrying out payment processes on the Internet, which provide the provider with any number and differently generated target links without any special effort in order to offer his fee-based content data on his website. The target links and the corresponding Internet addresses are up the payment computer system is aimed and not at the actual storage location of the content data, so that visitors to the website, i.e. the user or third parties, have no information about the storage location and the paid content data are thus completely secured against unpaid or unauthorized access. To generate the Internet addresses, the provider only needs to transfer order data, which at least includes cost data and access data, to the payment computer system, for example by input in a provided mask (front end) or by email or in some other way. The encrypted integration of the order data into the generated Internet addresses ensures that every access to the content data is always controlled and processed by the payment computer system. Because only there can the sensitive order data, in particular cost data and access data, be decrypted from the secured Internet addresses. Since the sensitive order data is saved and encrypted in the Internet addresses and these Internet addresses are available in the form of target links (hyperlink) on the website (website) of the provider, the order data itself does not need to be saved on the payment computer system. This results in a further increase in security against unauthorized access to the content data.

These and other advantages of the invention are described in more detail with reference to the description of the figures. The same applies to the special advantages that the configurations according to the subclaims have.

Examples of the communication network include in particular the Internet. It is provided that the communication network comprises an end user unit, a provider computer system of a provider of chargeable content data and a payment computer system of a service provider for the processing or execution of payment processes by means of monetary benefits.

Examples of the end user unit include computer-based stationary and mobile units, such as B. personal computers, portable computers, PDAs, intelligent telephones, etc. In particular, it is provided to use a so-called client designed as hardware and / or software as an end user unit. Examples of the fee-based content data include any type of data that can be transmitted in a computer-based communication network and used by third parties, with costs for the data user. In particular, it is provided to charge costs for access to content data. Such data, which can be, for example, text, image, video, audio data, are often also referred to as content. The data can be offered in the appropriate formats, such as PDF, MP3, AVI, etc.

Examples of the provider of fee-based content data include databases, in particular multimedia databases with text, music, image and / or video data, information services, information services, travel agencies, financial service providers, private and governmental organizations, etc. Accordingly, examples for the provider computer system include one Systems, devices, facilities, etc. operated by the provider, by means of which the provider provides his fee-based content data subject to a fee. With regard to the Internet, there is in particular provision to use a so-called content provider or content server.

Examples of the service provider include systems and companies that specialize in financial services and other systems and companies that provide further services in a computer-based communication network. In particular, it is envisaged that in the case of the Internet, a network service system or company will be used (e.g. Internet providers, email providers, etc.).

Examples of the payment computer system include systems, devices, devices, etc., which are designed for data exchange for the execution or processing of payment processes in computer-based communication networks. For example, a computer system designed as a payment server can be used as the payment computer system. A payment server can be a separate computer structure that is responsible for carrying out payment processes. A payment server can also be designed as an integrated component of a computer system that provides further functionalities and services.

In the method according to the invention, order data, which include cost data and access data, are transmitted from the provider or the provider computer system to the payment computer system. The cost data indicate the costs for one intended or desired access to desired content data arise. Access data specify how the content data is to be accessed. The order data are transmitted directly from the provider to the payment computer system, for example, via an input mask (front end or via the provider computer system, for example, by email or in some other way).

Both the cost data and the access data are parameters predefined by the provider which must be observed when paying and when accessing the data.

The transmission of the order data does not make it necessary for the service provider to have to determine costs for accessing the content data. Rather, these are made available to the payment computer system. The access data ensure that, according to the provider's specifications, access to his fee-based content data takes place, for example to prevent multiple data accesses without corresponding payment. A time limit on access ensures further security.

The cost data and / or the access data are preferably defined as access-dependent. The term access-dependent should not only be understood as meaning that the cost data and / or the access data are defined as a function of the access itself. Rather, the term access-dependent alternatively or additionally indicates that, for example, the provider has specified conditions for the access. Depending on the specified conditions, the cost data and / or the access data are then defined during the access.

Access-dependent can be understood, for example, to mean that the provider determines the costs indicated by the cost data depending on the time of day, depending on the possibility of access to the chargeable data, depending on the end user unit, for predetermined user groups or individual users.

In the case of an access-dependent definition of the access data, it is intended to use parameters comparable to the access-dependent definition of the cost data. It is possible to choose different sizes for the cost data and the access data, depending on which an access-dependent definition is made. It is possible for the end user unit to transmit a request for access to the content data to the provider computer system in order to transmit the order data. The request for access to the content data can be made before the order data is transmitted. This step is provided if a user of the end user unit specifies access to content data of the provider individually; For example, if a user wants to access the provider's content data once, irregularly, etc. This step is not necessary if, for example, a user wants to access certain content data regularly, e.g. B. to get their current version. In such a case, it is possible that the provider has been instructed accordingly to provide content data specified by the user, for example at regular intervals, for paid access.

To pay for access to the content data, it is provided that the payment computer system initiates a payment process for the fee-based access, the cost data being used as the basis for the payment process. The payment process for the fee-based access is therefore initiated by the payment computer system in accordance with the cost data. A further end user unit for which the desired access is to be made possible can also be specified.

If the initiated payment process is carried out successfully, ie if the costs required for access have been paid, access to the content data can be made possible. As an alternative to this, it is possible that, in addition to successfully carrying out the payment process, further conditions have to be met for access to the content data. Examples include the operation of a further end user unit if, for example, the access to the content data is to be carried out by a further end user unit. This can be advantageous, for example, if the payment process is carried out user-related and it is possible for a user to transmit the request for the content data to the provider computer system with one end user unit and to access the content data with a second end user unit. This allows the user to request and access z. B. using spatially separate end user units. If the content data is to be accessed without an individual request (e.g. access every day, once a week, monthly etc. and / or access every time the Content data), in this embodiment, and any further access can be made using any end user unit.

In a preferred embodiment, the order data further include provider identification data or provider identification data are transmitted to the payment computer system separately from the order data. Provider identification data are used, which can form part of the order data or are transmitted to the payment computer system separately from the order data. Using the provider identification data, it is possible to identify the provider and / or the provider computer system. This can be done, for example, in that the payment computer system identifies the provider and / or the provider computer system using a database on the basis of the provider identification data. In this case, the provider and / or the provider computer system can be specified in coded form using provider identification data. Alternatively, it is possible for the provider identification data to indicate the provider and / or the provider computer system directly, for example by using provider identification data which have the name of the provider and / or an identifier which uniquely identifies the provider computer system. The order data are e.g. transmitted in response to the desired access, the order data being transmitted in response to an order data request transmitted from the payment computer system to the provider computer system.

The method according to the invention is advantageously designed if the payment computer system accesses the content data in accordance with the access data and if the content data are provided by the payment computer system of the end user unit or a user of the end user unit. The access data can be provided by the payment computer system of the end user unit and the content data can be accessed according to the access data using the end user unit. In this context, it is particularly advantageous if the access data are converted from the payment computer system into temporary access data, and if the temporary access data are provided from the payment computer system to the end user unit, the content data being accessed according to the temporary access data using the end user unit. The content data can be accessed via a communication link between the End user unit and the payment computer system are performed, wherein the content data is transmitted from the provider computer system to the payment computer system, and wherein the content data is transmitted from the payment computer system to the end user unit to the end user unit.

In addition, it is also particularly advantageous if access to the content data via a communication link between the end user unit (CL) and the provider computer system (CP) or via a communication link between the end user unit (CL) and the provider computer system (CP) via the payment computer system (PS ) is carried out. In response to the access, a communication link for the transmission of data is preferably set up at least to initiate the payment process between the end user unit (CL) and the payment computer system (PS).

In order to facilitate the assignment of the access, for example, relative to other accesses, it is possible to use data identifying the desired access. Data identifying the desired access can be included in the order data or can be transmitted separately from these. Here, it is possible to use data identifying the desired access that uniquely identifies a so-called session. Such data are also referred to as tokens.

In order to facilitate statistical evaluations, for example, it is possible for data that characterizes the content data to be integrated into the order data or separately from these to the payment computer system. The data identifying the content data can, for example, be provided in a form encrypted by the provider and / or the provider computer system and decrypted for use by the payment computer system. The data identifying the content data can also be designed in such a way that, in conjunction with a database or look-up table, they allow the content data of the provider to be specified at any time.

In a preferred embodiment, the order data is transmitted in response to the request. As stated above, if the content data is to be accessed without prior access request, for example regularly, the order data can are transmitted if the conditions specified for such an access exist; if, for example, the time interval elapsed between two accesses to be carried out has expired. In this embodiment, the payment computer system receives the order data without further requests to the provider computer system.

In an alternative embodiment, it is provided to transmit the order data from the payment computer system to the provider computer system in response to a corresponding request. This embodiment has the advantage that steps provided before the payment process is carried out can be carried out. If these steps are carried out successfully, the payment process is initiated. Otherwise there is no payment process. This prevents the payment computer system from receiving the order data before it is clear whether a payment process can even be initiated. Data processing problems and security problems arising from the receipt of the order data are thus avoided.

The content data can be accessed via a communication link between the end user unit and the computer system.

It is possible for the content data to be transmitted from the provider computer system to the payment computer system and then from the computer system to the end user unit

Alternatively, it is possible for the content data to be accessed via a communication link between the end user unit and the provider computer system. It is also possible for a communication link to be used directly between them or via the payment computer system.

In a further embodiment, in response to the desired access, a communication link is set up between the end user unit and the payment computer system, this communication link serving at least to transmit data which are required for initiating the payment process. In order to increase the security of the method according to the invention, it is possible, to initiate the payment process, to check whether the end user unit and / or a user of the end user unit is or are authorized to carry out a payment process. Here it is possible that after the establishment of this communication connection, data are made available to the payment computer system which identify the end user unit and / or its users. Such identifying data can be used to check whether the end user unit and / or its users are registered with the payment computer system or the service provider. If this is the case, the payment process can be continued. If it is established that the end user unit and / or its users are not registered, a registration can be carried out under the control of the payment computer system. In order to initiate the payment process, the payment computer system (PS) checks an authorization to carry out the payment process using the end user unit (CL) or by a user of the end user unit (CL) or using the end user unit (CL) by their users, and it the payment process is carried out when the authorization is successfully checked. In order to carry out the payment process, it can be checked by the payment computer system (PS) whether an account assigned to the user or the end user unit (CL) has at least one monetary amount corresponding to the cost data, and if the account is checked successfully, a monetary amount corresponding to the cost data Account is withdrawn and if the check of the account is unsuccessful, the payment process is terminated or a request is sent from the payment computer system (PS) to the end user unit (CL), which indicates that to carry out the payment process, the monetary amount of the account at least up to the cost data the corresponding monetary amount is to be increased.

To carry out the payment process, it is provided that the payment computer system checks whether an account assigned to the end user unit and / or its user has an account balance that corresponds at least to the amount specified by the cost data. In particular, it is provided to use accounts with so-called monetary amounts, which are available, for example, in the form of points or a virtual currency (e.g. WEB cent) and can be converted into real amounts of money.

If the account has a corresponding minimum amount, a monetary amount corresponding to the cost data is deducted from the account. If the account is insufficiently covered, the payment process can be canceled. The desired access is then advantageously not permitted. If the account is not sufficiently covered, it is also possible that the payment computer system requests the end user unit and / or its user to increase the account balance at least to the minimum amount. Thereafter, it is possible to deduct a monetary amount corresponding to the cost data from the account and to continue the payment process.

The method according to the invention can thus be advantageously configured in that, in response to an access to the content data, a result request is transmitted from the provider computer system to the payment computer system, which indicates that a result response characterizing the payment process is transmitted from the payment computer system to the

Provider computer system is to be transmitted, a first result response from the

Payment computer system is transmitted to the provider computer system, which indicates a successfully carried out payment process for the access, and a second

Result response is transferred from the payment computer system to the provider computer system, indicating a payment transaction that has not been carried out for the access. It is preferably provided that the provider computer system in response to the first

Result response allows access to the content data and that the provider computer system prevents access to the content data in response to the second result response.

The security of the method according to the invention can be further increased in that, in response to access to the content data, the provider computer system transmits data to the payment computer system which indicate that the provider computer system desires information about whether the payment process was carried out successfully. In response to such a result request from the provider computer system, the payment computer system can transmit a result response that characterizes the payment process. In particular, it is provided that a first result response is transmitted, which indicates a successful payment process for the access that triggered the result request. If no payment process has been carried out for this access, a second result response can be transmitted from the payment computer system to the offer computer system. On the basis of information from the payment computer system about the payment process, the provider computer system can control access to its content data. In this way, the provider computer system can allow access to the content data in response to the first result response, whereas access to the content data can be prevented in response to the second result response.

Furthermore, to achieve the above object, the present invention provides a system for carrying out payment processes in a computer-based communication network with an end user unit, a provider computer system and a payment computer system. In particular, it is provided that the provider computer system is set up to be able to transmit order data to the payment computer system, the order data comprising cost data which indicate costs incurred for a desired access to the content data and access data which specify how the content data is to be accessed ,

In a preferred embodiment, the system according to the invention is designed to be operated according to the method according to the invention or according to embodiments thereof.

The proposed system for carrying out payment processes in a computer-based communication network thus comprises an end user unit, a provider computer system of a provider of fee-based content data and a payment computer system of a service provider for processing payment processes by means of monetary benefits. Order data is transmitted from the provider or the provider computer system to the payment computer system, the order data comprising the cost data which indicate costs incurred for a desired access to the content data and access data which specify how the content data is to be accessed. The system preferably has a first database assigned to the payment computer system for storing at least data identifying the provider computer system or the end user unit or a user of the end user unit. In addition, the system preferably also has a second database assigned to the payment computer system for storing data which indicate the current monetary amount of an account assigned to the end user unit or to a user of the end user unit. Brief description of the figures

In the following description of preferred embodiments, reference is made to the accompanying figures, of which:

1 to 6 are schematic representations of preferred embodiments of the present invention.

Description of preferred embodiments

Two embodiments are first described below, which are illustrated schematically in FIGS. 1 and 2.

In the embodiment shown in FIG. 1, the end user unit sends a request to the content provider CP in step (1), which indicates that the user of the end user unit CL wants to access certain content data of the content provider CP.

In step (2), the content provider CP transmits order data to a payment server PS.

The order data indicate what real amount or monetary equivalent the user has to pay to access the desired content data. Furthermore, the order data include information (access data) about how the desired content data should be accessed when the user has paid the requested price. It is optionally provided that the order data also include information (default for an error case) about how to proceed after a payment process that has not been carried out successfully, for example what information should be provided to the user. In step (3), the payment server PS initiates a payment process which takes place via a communication link between the payment server PS and the end user unit CL.

To initiate the payment process, the payment server requests an identifying identifier from the end user unit CL or its user.

For example, the user can be asked to provide a user name. The user name is checked for validity by the payment server PS. If this check fails, the user is informed of this by an error message; the payment process is ended.

The user can also be prompted for a password. The payment server PS checks the validity of the password. If this check fails, the user is informed of this by an error message; the payment process is ended.

The payment server PS then checks an account assigned to the user and / or the end user unit. The account can be a conventional account, for example at a bank, an account maintained by the payment server PS with real amounts of money or an account maintained by the payment server PS that has monetary values.

If the account is insufficiently covered, the user is informed of this by an error message. After that, the payment process can be ended or the user can be asked to increase the account accordingly.

In the embodiments described here, error messages occur in that the payment server PS establishes a connection between the end user unit CL and the content provider CP in accordance with the specification contained in the order data for an error case so that the user accesses one of the content provider CP given website. This is indicated in FIG. 1 by step (4). Alternatively, the error message can also be transmitted by the service provider to the end user unit CL. If the checked account is sufficiently covered, ie if the account has a real or monetary amount that is sufficient to pay the price requested by the content provider CP, the payment process can be successfully completed.

After the payment process has been carried out successfully, the payment server PS provides the end user unit CL with the desired content data. In the embodiments described here, this takes place in accordance with step (5) in that the payment server PS establishes a connection between the end user unit CL and the content provider CP in accordance with the access data contained in the order data. Via this connection, the user comes to a website of the content provider CP, which enables the user to access the desired content data.

Alternatively, it is possible for payment server PS in step (&) to establish a connection to the content provider CP in accordance with the access data and to access the desired content data. The content data is then transmitted from the content provider CP to the payment server PS. In step (6 ") the user can then access the content data available at the payment server using his end user unit CL.

In an optional step (R ¹ ), the content provider CP can use a result request to request the payment server PS to provide information as to whether the payment process was successfully completed. In step (R "), the payment server PS provides the content provider CP with such information in the form of a result response. If the result response indicates that the payment process has not been successfully completed, the content provider CP can in particular then prevent the desired access when access is via a direct communication link between the end user unit CL and the content provider CP.

The steps described in connection with access to the desired data can also be carried out using an end user unit, not shown in the figure, which differs from the end user unit CL used to carry out the payment process. This makes it possible to use the desired content data after a successful payment process Attach any end user and / or access them at different locations (e.g. office, home, internet cafe) and / or at any time.

The embodiment shown in FIG. 2 differs from the embodiment shown in FIG. 1 in the implementation of step (2) from FIG. 1. Otherwise, the illustrated steps shown in FIGS. 1 and 2 are comparable.

In step (2 '), the content provider CP transmits information to the payment server PS, which indicate that the payment server PS wants to access content data. This information does not contain any more specific information, e.g. B. about how to access soft content data, how much to pay, how to access content data, etc.

This information includes, for example, an identifier of the content provider CP with respect to the payment server PS. On the basis of such information content, the payment server PS recognizes that access to content data is to be paid for. For example, by comparing it to a database in which registered content providers are listed, the payment server PS can determine that operations in the following have to be carried out in connection with paid access to content data.

In step (2 "), the payment server PS requests the content provider CP to transmit order data. These order data can correspond to the order data described with reference to FIG. 1 or, as explained below, differ from them. In step (2 Order data are provided to the payment server PS which correspond to the request of the user of the end user unit CL, that is to say, among other things, to specify the content data desired by the user.

Further embodiments and the two above embodiments are described in more detail below, reference also being made to FIGS. 3, 4 and 5. In all the cases described, the following is assumed for simplification:

A personal computer designed for communication via the Internet is used as the end user unit. The personal computer and the methods used with it (e.g. in the form of software applications, in particular internet browsers) are collectively referred to as clients.

The provider assumes a service provider who provides content data in the form of so-called content over the Internet for paid access.

In particular, data in HTML format is assumed for the content data of content in the form of PDF files, files created with word processing systems and / or graphics systems or processes.

The provider computer system is based on a so-called content provider and the units and methods used (e.g. memory, databases, interfaces, software) with which content can be provided via the Internet.

The payment computer system is based on a so-called payment server and the units and methods used (e.g. memory, databases, interfaces, software) with which payment processes can be carried out over the Internet.

For security reasons, HTTPS connections and corresponding devices and procedures can be used for communication over the Internet. If encrypted or otherwise protected data is transmitted during communication, conventional, "insecure" connections can suffice.

In a first embodiment ("micropayment light"), order data in the form of URLs are used with parameters "attached" to them, with order data in each case in response to a request by the personal computer to access content from the content provider of the content Providers are transmitted to the payment server without using order data requests transmitted from the payment server to the content provider.

In a second embodiment ("Micropayment Pro"), order data in the form of URLs are used with parameters "attached" to them, with order data following a request from the personal computer to access content from the content provider in response to the payment Server to the content provider transmitted order data requests are transmitted from the content provider to the payment server.

Micropayment Light

The following embodiment specifically supports "smaller" content providers with technical systems of low complexity, for example without extensive content management and session handling. This embodiment can be inferred from the following description, with particular reference being made to FIGS. 3-6:

The payment server PS provides the content provider CP with an administration interface in the form of a website. It is preferably an input mask for order data set up on a front end FE. After a login content provider, order data is entered for each offer. In FIG. 4, three data records with order data 10, 20 and 30 are shown schematically by way of example. Each data record, such as the record with the order data 10, comprises at least cost data 13 which indicate the price and access data in the form of links 11, in particular URLs, to the content data offered, i.e. to the actual storage location of the content data (see CNT in FIG. 3). This is an offered text document "file013.doc", which is saved on an ftp server of the provider under the URL ftp: // ContentServer / directorv002 / ... and can be called up there by download.

In addition, the access data can also include other information, such as information 14 for a time limit on access, which the provider specifies. Here the access to the named text file for the period from 4th to 7th August 2004, limited to three days. This means that the content, i.e. the virtual data goods, as it were, (text document) is additionally secured against unauthorized access, for example by hackers or other people. In addition, the time limit in connection with the price indication 13 can be used to make various time-dependent offers for one and the same content (data goods). In this example, this means that the provider has the option of offering the text document "file013.doc", depending on the time, at different prices. In this example, the price entered would be "1.10 euros" only from April 4th to 7th. Valid in August. After that, another price could be valid, for example a higher price of "1.30 euros". Thus, the offer valid from August 4-7 would represent a kind of special offer or starter offer.

In addition to the access data 11 and 14 and the cost data 13, the order data 10 can also include other information, in particular description data 12, which indicate the content offered. In the example according to FIG. 4, this is the text document “file013.doc”, which contains a 15-page technical article from January 2003 with the title “Distribution channels on the Internet” by the author “Addi Server” (all information is purely fictitious and has none Relation to real things or people, but only serve as an illustration).

As schematically shown in FIGS. 3 and 4, the order data 10, 20, 30 etc. are transmitted in a first step S1 via the front end FE from the provider or his system CP to the payment computer system PS. There, in a second step S2, Internet addresses A20, A30 and A40 are respectively formed from the order data, which contain the cost data 13 and at least some of the access data 11 and 14 in encrypted form, the Internet addresses themselves specifying the payment computer system PS and not the actual location for the paid content data CNT.

Each generated Internet address A10 has the form of a URL, which begins with "https: // PaymentServer / login / ..." and is therefore intended for a registration process at the payment computer system PS. The further details in the URL are data "Data = ..." which contains the details of the provider in encrypted form, ie here the original URL 11, the description 12, the price 13 and the period of validity 14. With this data, the payment computer system PS can control the processing of the payment and the access to the content data. For this task, however, it is also sufficient if only the price information 13 and at least part of the original URL, in particular the main path to the content, are integrated into the Internet address.

In a third step S3, the generated Internet addresses A10, A20, A30 etc. are installed as target links, here as hyperlinks L10, L20 or L30, in a website, here in the website WS, of the provider. This means that the user who visits the WS website and sees the offers there can make an immediate selection through simple Click on the desired hyperlink. For example, if he wants the above-mentioned technical essay in the form of a text file, he clicks on link L10 in step S4.

A connection to the payment computer system PS is then established in a further step S5, i.e. the user is directed with his browser to a website of the payment computer system PS. The actual payment for the desired content is then processed there in a step sequence S6. An online account is used, among other things, to checked whether the user can pay the requested price. If this is the case and the payment process has been completed, in a step S7 the user is authorized to access the desired content data CNT, in this example specifically the text file "file013.doc". The content data is transmitted, for example, by a direct download from ftp server, whereby the address URL 11 is not visible to the user, or alternatively the payment computer system PS can first retrieve the content there, which is also invisible to the user, and can then make the content available for download In these cases, the actual storage location for the content data CNT is not apparent, in particular there is no sensitive data on the provider's website WS nor on the payment computer system PS and no data is exchanged in unsecured form.

The links built into the WS website encrypt all information that the payment server needs to carry out a payment process in connection with a paid access to content from the content provider. In order to regain this information, the payment server is set up to read the encrypted information from a link (URL).

Performing paid access to content from the content provider includes the following steps:

Selection of content at the content provider by the user of an end user unit (personal computer) Forwarding of the user to the payment server by means of a special URL which has order data as “attached” information. Login of the user to the payment server (possibly after the customer has registered) ) Execution of a payment process (if necessary after increasing the account balance of an account assigned to the user) forwarding the user to the desired content at the content provider and delivery of the content by the content provider or access to the content by the payment server and delivery of the Contents through the payment server to the user or the end user unit

In this embodiment, the following data is used for data exchange between the content provider and the payment server:

The following input data (input) specified by the content provider is used:

Data name Explanation

Price: Amount that the operator of the content provider requires for access to the content data desired by the user. The price can indicate a real amount of money or a monetary benefit (e.g. points, WEB. Cent).

ContentlD: Identifies the content desired by the user (e.g. order number or commodity number of the content provider).

Return / Download URL: Specifies at least part of an Internet address that can be used to access the desired content. (see master URL and rest URL)

Return URL: Specifies an Internet address to which the user will be directed in the event of an error (e.g. if the payment process has not been completed successfully).

Master URL: Indicates that the return / download URL is a full internet address to access the desired content or is part of an Internet address that, supplemented by the rest of the URL, gives an Internet address for access to the desired content.

Remaining URL: Defines a part of an Internet address which, if specified by the master URL, is combined with a return / download URL indicating part of an Internet address, which results in an Internet address for accessing the desired content.

Description: A summary of the desired content that the payment server can provide to the user.

Validity: Defines the period in which the user can access the desired content after a successful payment.

The payment server generates the following output data:

Data name Explanation

Data: Includes the data price, content ID, return / download URL, return URL, master URL, description, validity

Version: Defines the software interface for data exchange between the payment server and the content provider. The following examples of software codes are specified depending on the currently provided interface and are therefore to be understood only as examples and as changes and modifications, in particular as a result of technical changes and further developments. As already described above, the output data are generated as access data for the content and in the form of an address, in particular a link in the form of a secured URL

In order to be able to offer content, the content provider logs in at https: // payment server / using the user name and password received from the payment server. The following information is then entered using the administration interface (see VU in FIG. 3) and the access data is generated in the form of said URL using the information:

Data name Data format Data type

(Note)

Price cent = 123 Numeric (e.g. in WEB.Cent) min. 1 (without content provider-specific), ax. (Content provider specific

ContentlD contid = abcl23 Alphanumeric

(assigned by the content provider, max. 256 characters no evaluation by payment server)

Return / download URL backok = valid URL (if successful, assigned by the content provider http (s): // payment server / uri? Params)

Master URL Yes / No Boolean

(indicates ("yes") that return / download URL only specifies part of an address and can be combined with a residual URL)

Return URL backerc = Valid URL

(in the event of an error / termination, from http (s): // payment server / uri? params Content provider)

Description desc = abcl23 Alphanumeric,

(textual description of the content max. 256 characters by content provider)

Validity validfor = 12345 Numeric, integer

(Duration of the access right in seconds) Default: 1200 [20 minutes]

With this information, the secure URL is generated, which the content provider provides to users, for example, integrated into one of its websites. The content provider only needs to integrate the URL generated by the payment server into the offer pages on its website as links. Neither the URL nor any other information mentioned in this context is saved by the payment server or otherwise held. At least one such URL is generated for each offer of the content provider. Several URLs can also be generated for the same offered content (e.g. text document, music file, etc.) by e.g. A URL is generated for different price levels. In these cases, the content provider has several URLs to choose from and can immediately change the price by replacing the current URL with the desired URL.

The generated URLs are links that lead from the website of the content provider to the payment server. The URLs have the form https: // Payment-Server / login / with the following parameters:

Data name Data format Data type

(Note)

Data data = 123abc Alphanumeric

(includes the information entered using the administration interface) Version version = l Numeric, integer (version of the interface) Current: Version 1

After the customer has selected the desired content, the content provider forwards the customer to the address https: // Payment-Server / login. This can be done by a so-called client editor in the current browser window of the user's end-user unit or by opening a new browser window.

^' The parameter "Data" contains the price information for the desired content. If the content provider wants to charge different prices for its content (e.g. depending on the time of day, access frequency, users, etc.), it is intended to generate a URL for the different prices and to provide these users, for example, depending on the time of day ,

With particular reference to FIG. 5, an embodiment will now be described in which the content provider wishes to charge a price for different content. In this case, it is also provided to activate the "master URL" parameter (by means of a cross "X" in the checkbox M). The "master URL" parameter indicates that the access data UM contain a special URL which does not initially represent a complete internet address (AI 0M) for access to the desired content, but is to be combined with a residual URL assigned to the desired content (specification D1), so that a complete URL is created as hyperlink L101 for content access.

The URL UM specified by the provider specifies the "master URL" as the ftp access address for an entire directory ftp: // Content-Server / directory 111, under which a variety of content data (here the music files "Oldie-Hits 1970-1979 ") for a uniform price per piece (here for EUR 0.25). This means that the order data 10M refer to an entire directory, under which a lot of content data is offered at the unit price 14M. The information thus corresponds to only part of the access data, namely the higher-level part, which relates to a directory, that is to say a directory path. From this order data 10M, the payment computer system PS generates an Internet address A10M, in which only the directory path is integrated.

In order to obtain a complete target link L101, this Internet address A10M is supplemented by the provider computer system CP with additional information D1 which the provider provides and which is based on the content file specifically offered, e.g. "File001.mp3". Thus, on the provider side, based on the one Internet address A10M, any number of destination links L101, L102, L103 etc. can be formed and incorporated into the WS website there. The provider can therefore expand his or her offer as desired Payment computer system PS essentially only checks the correct payment of the unit price 14M for each access.

In relation to FIGS. 1 and 2, this means that in such a case the URL containing a price indication (see above) is supplemented by the following parameter:

Data name Data format Data type

(Note)

Remaining URL ext = 123abc Alphanumeric

(optional, when using the master URL = setting "yes")

After the payment process has ended, the payment server directs the customer, for example, via client redirect to the corresponding page of the content provider, where the content can be downloaded. Here, the return / download URL is used after a successful payment process (user has paid the amount requested by the content provider), while after an unsuccessful payment process (user has not paid the amount requested by the content provider), in the event of an error or at a cancellation by the user uses the return URL for the error.

Since the content of the content provider can be reached statically under a specific URL, the content URL or download URL, there is a risk that the user will be able to access the content after the Paid access uses the return / download URL again in the event of success without further payment, passes it on to third parties etc. as accesses can be carried out without the content provider being paid accordingly.

To avoid this, it is provided that the payment server provides the content itself. The return / download URL is not provided to the user in the event of success. Rather, the payment server server accesses the content and makes it available to the user.

In order to provide the content to the user through the payment server, the desired content can be transmitted from the content provider to the payment server. This transmission can take place by a request from the payment server ("download") or a transmission ("upload") initiated by the content provider. The user can then be provided with information, for example in the form of a link (for example in the form of a URL), which enables the user to access the desired content and transmit it to his personal computer ("download"). In order to prevent the user from repeatedly accessing the desired content using this information without making a corresponding payment, the information can be provided in the form of information that is valid for a limited period of time and / or in the form of information that is only required once Allow (successful) access. It is also possible that the payment server deletes the desired content after a single (successful) access. This is advantageous for reasons of storage capacity and also ensures that the user can only access the desired content once.

In order to provide the content to the user through the payment server, it is alternatively provided that the payment server converts the return / download URL into a URL which, from the user's point of view, is assigned to the payment server, but one for which Includes user unrecognizable link to the return / download URL. The converted URL is provided to the user by the payment server. Using the converted URL, the user can then access the desired content and transfer it to his personal computer ("download"). In order to prevent the user from repeatedly accessing the desired content using this information without making a corresponding payment, the converted URL are provided in the form of a URL that is valid for a limited time and / or in the form of a URL that only allows one-time (successful) access.

The following configuration is also described with reference to FIG. 6:

The access address specified by the provider can be a higher-level branch address (tree URL) 10T, which relates to any collection or compilation of content data. In the example shown, the tree URL ftp: // ContentServer / treeOl is used to address a collection TOI of all content data for an encyclopedia. The tree URL corresponds to a virtual address, which, like a bracket, encloses all thematically combined files regardless of their data type and their physical storage location. All of this thematically summarized content data can therefore be requested by the user under the tree URL, whereby the user can request the respective file, e.g. "Dokl" must pay the assigned price. The content files (Dokl, Dok2, etc.) that are virtually summarized under the tree URL can therefore be offered at different conditions, in particular at different prices. The payment system essentially checks whether the user is fundamentally authorized is to access the respective collection. This means that entire subject areas can be booked and managed by users. For example, sub-accounts can be set up which the user can manage differently. For example, the father of a family is registered as a user. The sub-accounts relate to family members, who only have access rights to certain subject areas. For example, the children can access all content data of the shown encyclopedia TOI via their sub-accounts at the expense of the father (user), but not to other collections, such as travel reports T02 areas for a flat rate, i.e. as part of a subscription.

Corresponding target links LT1B1D1, LT1B1D2 ... LT2B1D1 etc. are formed for access, this being done on the provider side, i.e. in the provider computer system CP, by supplementing the internet address formed by the payment computer system, which has the body https: // Payment-Server / login / data = ... starts.

Micropayment Pro The following embodiment specifically supports "larger" content providers with technical systems of greater complexity, for example with extensive content management and session handling.

Selection of content at the content provider by the user of an end user unit (personal computer) - forwarding the user to the payment server by means of special URL communication ("handshake") between the payment server and content provider in order to provide order data to the payment server. Login of the user at the payment server (if necessary after registering the customer) performing a payment process (if necessary after increasing the balance of an account assigned to the user) forwarding the user to the desired content at the content provider and delivering the content by the content Provider or result request from the content provider to the payment server in order to receive a result response that characterizes the execution of the payment process, and, in the event of a positive result response (ie successfully carried out payment process), delivery of the content by the content provider

In the case of data exchange between the content provider and the payment server, the following data are used in this embodiment in addition to the data mentioned in the previous embodiment:

Data name Explanation

Content-Pro viderlD: Identifies the content provider vis-à-vis the payment server. Token: Identifies the process ("session") associated with access to the desired content as a whole vis-à-vis the content provider. Transaction ID: Identifies the payment process associated with accessing the desired content to the content provider.

Success: Indicates the result of a payment transaction (e.g. user has paid).

Counter: Indicates how often the desired content was provided to the user during the period in which the content can be used without further payment (parameter "validity").

After the user has selected the desired content, the content provider forwards the user to the address https: // Payment-Server / login /. This can be done by a so-called client redirect in the current browser window of the user's end-user unit or by opening a new browser window.

The content provider appends the following parameters as additional information:

Data name Data format Data type

(Note)

Content-ProviderlD cpid = 12345 Numeric, whole number

(unique, assigned by WEB.DE)

Token tok = 123abc Alphanumeric, (unique session ID of the max. 256 character content provider)

Version version = l Numeric, integer

(Version of the interface) Current: Version 1 Requests with invalid content provider IDs result in an error message for the user.

The content provider is responsible for the uniqueness of the token and the ability to identify a specific session based on the token. A session can be valid for at least 20 minutes, for example.

If the payment server has received the information transmitted by the content provider, the payment server sends an order data request to the content provider, which in response transmits order data assigned to the desired content to the payment server.

Such data exchange or "handshake" can take place, for example, via HTTPS access or via SOAP.

In this embodiment, detailed information about the transaction is provided to the payment server via a defined URL at the content provider. An order data request is used, which uses the token received from the content provider to identify the respective transaction:

Data name Data format Data type

(Note)

Token tok = 123abc Alphanumeric,

(unique session ID of the max. 256 character content provider)

Version version = l Numeric, integer (version of the interface) Current: Version 1

In the case of access in accordance with HTTPS, the order data request can take the following form:

https: // Payment-S erver / uri? tok = 123 abc & version = 2 & wkz = 123 abc In the case of SOAP access via an HTTPS connection, the order data request can take the following form:

<? xml version = "1.0" encoding- 'UTF-8 "?>

<SOAP-ENV: Envelope SOAP-

ENV: encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/" xmlns: SO AP-ENC = "http: //schemas.xmlsoap .org / soap / encoding /" xmlns: xsi = "http: // www. w3.org/1999/XMLSchema-instance "xmlns: SOAPENV =" http: // schemas .xmlsoap. org / soap / envelope / "xmlns: xsd =" http://www.w3.org/1999 / XML Schema ">

<SOAP-ENV: Body>

Handshake SOAP-ENC: root = "l">

</ Handshake>

</ SOAP-ENV: Body>

</ SOAP-ENV: Envelope>

In response, the content provider delivers the corresponding order data, which in this embodiment has the following form:

Price cent = 123 numeric,

(in WEB.Cent) min. 1 (or partner-specific) max. (Partner-specific)

Transaction ID transid = 12345 Numeric, integer

(unique, assigned a maximum of 64 positions by the content provider)

ContentlD contid = abcl23 Alphanumeric

(assigned by the content provider, no max. 256 characters evaluation by payment server) Return / Download URL backok = Valid URL

(if successful, assigned by the content provider http (s): // payment server / uri? params)

Bake return URL = valid URL

(in the event of an error / termination, assigned by http (s): // payment server / uri? params content provider)

Description desc = abcl23 Alphanumeric,

(textual description of the content max. 256 characters by content provider)

Version version = l Numeric, integer

(Version of the interface) Current: Version 1

Validity validfor = 12345 Numeric, integer

(optional; duration of access right Default: 1200 in seconds) [20 minutes]

In the case of access according to HTTPS, the order data can have the following form:

<? xml version = "1.0" encoding = 'TSO-8859-l "?> <handshake>

<backok> https: // Payment-Server / uri? parameter = value </backok> <backen> https: // Payment-Server / uri? parameter = value ^ ackok>

</ Handshake> In the case of access according to SOAP via an HTTPS connection, the order data can have the following form:

<? xml version = "1.0" encoding = "UTF-8"?>

<SOAP-ENV: Envelope SOAP-

ENV: encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/" xmlns: SOAP-ENC = "http.7 / schemas.xmlsoap.org / soap / encoding /" xmlns: xsi = "http: / / www.w3.org/1999/XMLSchema-instance "xmlns: SOAPENV =" http://schemas.xmlsoap.org/soap/envelope/ "xmlns: xsd- 'http: // www. w3.org/1999/XMLSchema ">

<SOAP-ENV: Body>

<nsl: handshakeResponse xmlns: nsl = "https: // Payment-Server / uri" SOAP-ENC: root = "1">

<backok xsi: 1ype = "xsd: string"> https: // Payment-Server / uri? parameter = value </backok>

<bake xsi: type = "xsd: string"> https: // Payment-Server / uri? parameter = value </backok>

</ nsl: handshakeResponse>

</ SOAP-ENV: Body>

</ SOAP-ENV: Envelope>

If the content provider would like to charge different prices for its content (e.g. depending on the time of day, access frequency, user, etc.), this can be done by the content provider responding to the order data request with order data at different prices transmits to the payment server.

The content provider is free to restrict access to defined computer systems of the payment server and / or to use additional, for example protocol-dependent security mechanisms (SOAPHMAC). In the event of an error, the content provider should provide an error message if possible so that the user does not have to wait until a time limit is exceeded.

The payment server keeps track of the duration of an access authorization for a transaction. A renewed request with the same ContentlD and the same user leads to positive feedback for the duration of an access authorization, i.e. access to the desired content is made possible.

After the payment process has ended, the payment server directs the customer, for example, via client redirect to the corresponding page of the content provider. Here, the return / download URL is used after a successful payment process (user has paid the amount requested by the content provider), while after an unsuccessful payment process (user has not paid the amount requested by the content provider), in the event of an error or at a cancellation by the user uses the return URL for the error.

The following parameters are appended:

Data name Data format Data type

(Note)

Token tok = 123abc Alphanumeric,

(unique session ID of the max. 256 characters content provider)

As an optional security measure, the content provider can check the validity of a transaction (ie whether the user has paid the amount required before accessing the content) after the user returns to the content provider at the payment server. For this, the content provider transmits a result request to the payment server, for example by transmitting a result response to the content provider before the content is delivered. For example, in this embodiment, a result request is made by accessing or calling one of the following URLs:

https: // Payment-Server / intern / transaction / soap / https: // Payment-Server / intem / transaction / xml /

The following parameters are added or appended:

Data designation Data format Data type (explanation)

Transaction ID transid = 12345 Numeric, integer

(unique, assigned a maximum of 64 positions by the content provider)

Content-ProviderlD cpid = 12345 Numeric, whole number

(unique, assigned by WEB.DE)

Version version = l Numeric, integer

(Version of the interface) Current: Version 1

In the case of access according to HTTPS, the result request can take the following form:

https: // Payment server / internal / transaction / xml? transid = 12345 & cpid = 12345 & version = 1

In the case of SOAP access via an HTTPS connection, the result request can take the following form:

<? xml version- '1.0 "encoding =" UTF-8 "?><SOAP-ENV: Envelope SOAP-ENV: encodingStyle =" http://schemas.xmlsoap.org/soap/encoding/ "xmlns: SOAP- ENC = "http://schemas.xmlsoap.org/soap/encoding/" xmlns: xsi = "http: // www.w3.org/1999/XMLSchema-instance" xmlns: SOAPENV = "http: // schemas. xmlsoap.org/soap/envelope/ "xmlns: xsd =" http://www.w3.org/1999/XMLSchema ">

<SOAP-ENV: Body>

<version xsi: type- "xsd: int"> K / version>

</ Callback>

</ SOAP-ENV: Body>

</ SOAP-ENV: Envelope>

As a result response, the payment server provides the following response in this embodiment:

Data name Data format Data type

(Note)

Success result = ok or alphanumeric

(Payment server confirms the result = failed or either ok, failed payment is known to the initiating result = none or transaction, content provider only if successful) result = multiple or not paid or result = canceled validity expired), none (for content - ProviderlD unknown transaction), multiple (transaction ID not unique) or canceled (for a canceled transaction)

Transaction ID transid = 12345 Numeric, integer

(clear, max. 64 digits from the content provider forgive)

ContentlD contid = abc 123 Alphanumeric

(assigned by the content provider, no max. 256 characters evaluation by payment server)

Counter checkcount = l Numeric

(Number of queries for at least 1

Transaction including this)

Version version = l numeric,

(Version of the interface) Current: Ve

In the case of access according to -HTTPS, the result response can take the following form:

<? xml version = "1.0" encoding = "ISO-8859-l"?> <callback> <result> ok </result> <transid> 12345 </transid> <contid> abcl23 </contid> <checkcount> 1 </checkcount> <version> 1 </version> </callback>

In the case of SOAP access via an HTTPS connection, the result response can have the following form:

<? xml version = "1.0" encoding = "UTF-8"?><SOAP-ENV: Envelope SOAP-ENV: encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/" xmlns: SOAP-ENC = "http://schemas.xmlsoap.org/soap/encoding/" xmlns: xsi = "http://www.w3.org/1999/XMLSchema-instance" xmlns: SOAPENV = "http: //schemas.xmlsoap .org / soap / envelope / "xmlns: xsd =" http://www.w3.org/1999/XMLSchema "> <SOAP-ENV: Body>

<checkcount xsi: type = "xsd: int"> K / checkcount>

</ nsl: callbackResponse>

Claims

1.Procedure for carrying out payment processes on the Internet with an end user unit (CL), a provider computer system (CP) of a provider of fee-based content data (CNT) and a payment computer system (PS) of a service provider for processing payment processes by means of monetary benefits, in the first Step (S1) order data (10, 20, 30) are transmitted from the provider or the provider computer system (CP) to the payment computer system (PS), the cost data (13), which indicate costs incurred for a desired access to the content data, and the Access data (11, 14) comprise, which specify how to access the content data (CNT), in which in a second step (S2) Internet addresses (A10, A20, A30) are generated which specify the payment computer system (PS) as the destination and contain the cost data (13) and at least part of the access data (14) of the order data (10, 20, 30) in encrypted form, in which in ei In a third step (S3), the Internet addresses (A10, A20, A30) are integrated as target links (L1 1, L12, L13), in particular as hyperlinks, in an Internet presence (WS), in particular in websites, the provider or the provider computer system (CP) are provided, in which in a further step (S4) individual of the chargeable content data (CNT) are selected by activating the corresponding destination link (L) by the user of the end user unit (CL), in particular by clicking the hyperlinks in a browser application, thereby in a subsequent step (S5) the user is forwarded to the payment computer system (PS), in which the payment process for the content data selected by the user (CNT) is processed in a further step (S6), and in which in a subsequent step (S7 ) the user is allowed access to the paid content data (CNT).

2. The method according to claim 1, in which in the second step (S2) the Internet addresses (A10, A20, A30) are each generated with a first part which specifies a URL under which the user logs on to the payment computer system (PS) can register and be generated with a second part, in which order data (10, 20, 30) are fully and encrypted integrated.

3. The method according to claim 1, in which in the second step (S2) the Internet addresses (A10M) are each generated with a first part that specifies a URL under which the user can log on to the payment computer system (PS), and with a second part are generated, in which the order data (10M) are only partially and completely integrated, the integrated part indicating the cost data (14M) completely and the access data (1 IM) to the extent that the user receives the payment when the payment is made Access to an entire directory (D), in which several chargeable content data are stored, is allowed.

4. The method according to claim 3, in the third step (S3) composite target links (AL101, ALI 02, ALI 03) are created and integrated into the Internet presence (WS) in which the Internet addresses (A 10M), each of which access to an entire directory (D), in which several fee-based content data are stored, are supplemented by address details (D1) provided by the provider or the provider computer system (CP) and which address the fee-based content data stored in the directory (D) ,

5. The method as claimed in claim 1, in which, in the first step (S1), the provider or the provider system (CP) transmits access data (10T) to the payment computer system (PS) which, when paid, gives access to entire collections (T01, T02), especially thematic collections, of content data allowed.

6. The method according to claim 5, in which in the second step (S2) the Internet addresses are each generated with a first part, which specifies the URL under which the user can log on to the payment computer system (PS), and with a second part in which this access data (10T) for the respective collection (TOI, T02) is integrated in an encrypted manner, and in which in the third step (S3) composite target links (AL101, ALI 02, ALI 03) are created and in the Internet presence (WS ) are integrated, in which these Internet addresses, which each allow access to a collection, are supplemented by address details (DI), which the provider or the provider computer system (CP) provides and which address the content data summarized in the collection.

7. The method according to any one of the preceding claims, wherein the cost data or the access data or the cost data and the access data are defined depending on access.

8. The method according to any one of the preceding claims, wherein a request for access to the content data from the end user unit (CL) to the provider computer system (CP) is transmitted before the transmission of the order data.

9. The method according to any one of the preceding claims, in which a further end user unit (CL ') is specified for which the desired access is to be made possible.

10. System which is designed to carry out the steps according to a method according to any one of the preceding claims.