WO2005015515A2 - Procede et systeme permettant de realiser des operations de paiement dans un reseau de communication assiste par ordinateur - Google Patents

Procede et systeme permettant de realiser des operations de paiement dans un reseau de communication assiste par ordinateur Download PDF

Info

Publication number
WO2005015515A2
WO2005015515A2 PCT/EP2004/008910 EP2004008910W WO2005015515A2 WO 2005015515 A2 WO2005015515 A2 WO 2005015515A2 EP 2004008910 W EP2004008910 W EP 2004008910W WO 2005015515 A2 WO2005015515 A2 WO 2005015515A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
access
payment
provider
computer system
Prior art date
Application number
PCT/EP2004/008910
Other languages
German (de)
English (en)
Other versions
WO2005015515A3 (fr
Inventor
Thomas Schäfer
Timo Grammer
Marc Drockur
Original Assignee
Web.De Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from DE2003136519 external-priority patent/DE10336519B4/de
Application filed by Web.De Ag filed Critical Web.De Ag
Priority to EP04741390A priority Critical patent/EP1654713A2/fr
Publication of WO2005015515A2 publication Critical patent/WO2005015515A2/fr
Publication of WO2005015515A3 publication Critical patent/WO2005015515A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G06Q20/123—Shopping for digital content
    • G06Q20/1235—Shopping for digital content with control of digital rights management [DRM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • the present invention relates to payment processes in a computer-based communication network, such as. B. the Internet.
  • 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.
  • micropayment systems and processes are used, among other things.
  • micropayment can be traced back to the fact that usually only low costs are billed for paid access to data.
  • 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.
  • 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.
  • the service provider determines 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.
  • 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.
  • the object of the present invention is to solve the above-mentioned problems of the prior art.
  • it is the object of the present invention to make payment processes in a computer-based communication network simpler, more variable and more secure.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • order data which include cost data and access data
  • 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.
  • 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.
  • 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.
  • access to the content data can be made possible.
  • 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.
  • 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.
  • 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.
  • the provider identification data may 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.
  • 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.
  • 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).
  • Data identifying the desired access can be included in the order data or can be transmitted separately from these.
  • data identifying the desired access that uniquely identifies a so-called session.
  • Such data are also referred to as tokens.
  • data that characterizes the content data can 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.
  • the order data is transmitted in response to the request.
  • 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.
  • the payment computer system receives the order data without further requests to the provider computer system.
  • 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.
  • the content data can 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.
  • 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.
  • 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.
  • 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.
  • the payment computer system 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.
  • the payment computer system PS
  • the payment computer system PS
  • a monetary amount corresponding to the cost data 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.
  • 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.
  • 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.
  • 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.
  • the payment computer system can transmit a result response that characterizes the payment process.
  • a first result response is transmitted, which indicates a successful payment process for the access that triggered the result request.
  • a second result response can be transmitted from the payment computer system to the offer computer system.
  • 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.
  • 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.
  • 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 ,
  • 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.
  • 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.
  • 1 to 6 are schematic representations of preferred embodiments of the present invention.
  • FIGS. 1 and 2 Two embodiments are first described below, which are illustrated schematically in FIGS. 1 and 2.
  • 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.
  • 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.
  • 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.
  • the payment server requests an identifying identifier from the end user unit CL or its user.
  • 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.
  • 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.
  • 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).
  • 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.
  • the payment server PS 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.
  • step (&) 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.
  • step (6 ") the user can then access the content data available at the payment server using his end user unit CL.
  • step (R 1 ) 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • step (2 ") the payment server PS requests the content provider CP to transmit order data.
  • order data can correspond to the order data described with reference to FIG. 1 or, as explained below, differ from them.
  • 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.
  • 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 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.
  • HTML format 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.
  • units and methods used e.g. memory, databases, interfaces, software
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • the access data can also include other information, such as information 14 for a time limit on access, which the provider specifies.
  • information 14 for a time limit on access which the provider specifies.
  • 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.
  • 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).
  • the price entered would be "1.10 euros" only from April 4th to 7th.
  • the offer valid from August 4-7 would represent a kind of special offer or starter offer.
  • the order data 10 can also include other information, in particular description data 12, which indicate the content offered.
  • description data 12 indicates the content offered.
  • 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).
  • 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.
  • 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 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.
  • 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.
  • target links here as hyperlinks L10, L20 or L30
  • 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.
  • 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:
  • the following data is used for data exchange between the content provider and the payment server:
  • 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.
  • 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 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.
  • 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
  • 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:
  • Price cent 123 Numeric (e.g. in WEB.Cent) min. 1 (without content provider-specific), ax. (Content provider specific
  • Validity validfor 12345 Numeric, integer
  • 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:
  • Version version l Numeric, integer (version of the interface) Current: Version 1
  • 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 ,
  • 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.
  • AI 0M complete internet address
  • D1 residual URL assigned to the desired content
  • 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).
  • 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.
  • 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".
  • additional information D1 which the provider provides and which is based on the content file specifically offered, e.g. "File001.mp3".
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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").
  • 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.
  • 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").
  • 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 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.
  • 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.
  • Micropayment Pro specifically supports "larger" content providers with technical systems of greater complexity, for example with extensive content management and session handling.
  • Performing paid access to content from the content provider includes the following steps:
  • 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").
  • 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:
  • Token tok 123abc Alphanumeric, (unique session ID of the max. 256 character content provider)
  • 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.
  • the payment server 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.
  • Token tok 123abc Alphanumeric
  • Version version l Numeric, integer (version of the interface) Current: Version 1
  • the order data request can take the following form:
  • the content provider delivers the corresponding order data, which in this embodiment has the following form:
  • Price cent 123 numeric
  • Validity validfor 12345 Numeric, integer
  • the order data can have the following form:
  • the order data can have the following form:
  • 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).
  • SOAPHMAC protocol-dependent security mechanisms
  • 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.
  • the payment server directs the customer, for example, via client redirect to the corresponding page of the content provider.
  • 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.
  • Token tok 123abc Alphanumeric
  • 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.
  • a result request is made by accessing or calling one of the following URLs:
  • the result request can take the following form:
  • the result request can take the following form:
  • the payment server provides the following response in this embodiment:
  • the result response can take the following form:
  • the result response can have the following form:

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Transfer Between Computers (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé et un système permettant de réaliser des opérations de paiement dans un réseau de communication assisté par ordinateur comprenant une unité utilisateur final, un système informatique d'un fournisseur de données contenu soumises à un coût et un système informatique de paiement d'un prestataire de services aux fins de déroulement des opérations de paiement à l'aide de prestations ayant une valeur en argent. Selon ce procédé, des données de commande sont transmises du système informatique du fournisseur au système informatique de paiement et contiennent des données coûts indiquant les coûts engendrés sur les données contenu pour un accès souhaité et des données d'accès qui indiquent comment accéder aux données contenu.
PCT/EP2004/008910 2003-08-08 2004-08-09 Procede et systeme permettant de realiser des operations de paiement dans un reseau de communication assiste par ordinateur WO2005015515A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP04741390A EP1654713A2 (fr) 2003-08-08 2004-08-09 Procede et systeme permettant de realiser des operations de paiement dans un reseau de communication assiste par ordinateur

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE2003136519 DE10336519B4 (de) 2003-08-08 2003-08-08 Verfahren zur Durchführung von Bezahlvorgängen in einem rechnerbasierten Kommunikationsnetzwerk
DE10336519.2 2003-08-08
US57676804P 2004-06-03 2004-06-03
US60/576,768 2004-06-03

Publications (2)

Publication Number Publication Date
WO2005015515A2 true WO2005015515A2 (fr) 2005-02-17
WO2005015515A3 WO2005015515A3 (fr) 2005-03-31

Family

ID=34137314

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/008910 WO2005015515A2 (fr) 2003-08-08 2004-08-09 Procede et systeme permettant de realiser des operations de paiement dans un reseau de communication assiste par ordinateur

Country Status (2)

Country Link
EP (1) EP1654713A2 (fr)
WO (1) WO2005015515A2 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5963917A (en) * 1996-02-05 1999-10-05 Net Moneyin, Inc. Financial system of computers
WO2001063437A1 (fr) * 2000-02-23 2001-08-30 Web Data Corporation Systeme et procede permettant d'effectuer des transactions transparentes et anonymes sur internet
WO2001080100A1 (fr) * 2000-04-17 2001-10-25 Qsi Payment Technologies Pty Ltd Systeme de paiement pour commerce electronique

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5963917A (en) * 1996-02-05 1999-10-05 Net Moneyin, Inc. Financial system of computers
WO2001063437A1 (fr) * 2000-02-23 2001-08-30 Web Data Corporation Systeme et procede permettant d'effectuer des transactions transparentes et anonymes sur internet
WO2001080100A1 (fr) * 2000-04-17 2001-10-25 Qsi Payment Technologies Pty Ltd Systeme de paiement pour commerce electronique

Also Published As

Publication number Publication date
WO2005015515A3 (fr) 2005-03-31
EP1654713A2 (fr) 2006-05-10

Similar Documents

Publication Publication Date Title
DE69618157T2 (de) On-line-Einkaufssystem und Verfahren zum Begleichen der Rechnung
DE69908610T2 (de) Gerät und Verfahren für die automatische Zusammenstellung und Übertragung von Transaktionen welche persönliche elektronische informationen oder Daten enthalten
EP1118923A1 (fr) Procédé pour l'utilisation d'un produit SW sur réseau
DE10034734A1 (de) Web-basierte, automatisierte Schnittstelle zwischen Informationsanbietern und einem Electronic Payment Provider
WO2011029560A2 (fr) Système de paiement, système d'achat et procédé de réalisation d'une pluralité de processus de paiement
EP1347620B1 (fr) Facturation de l'utilisation des données de contenu mis à la disposition dans l'internet par un terminal mobile
EP1332438B1 (fr) Procede et dispositif pour la transmission de flux de donnees electroniques
WO2004006198A1 (fr) Procede pour le paiement electronique d'une marchandise ou d'une prestation de service par utilisation d'un reseau de telephonie mobile et ensemble pour l'execution de ce procede
DE60306974T2 (de) Verfahren, Rechner, und Rechnerprogramm für die Übertragung und Bezahlung von Dateninhalten
WO2005015515A2 (fr) Procede et systeme permettant de realiser des operations de paiement dans un reseau de communication assiste par ordinateur
EP1158471B1 (fr) Système, méthode et programme pour le paiement dans un réseau de télécommunication
DE10336519B4 (de) Verfahren zur Durchführung von Bezahlvorgängen in einem rechnerbasierten Kommunikationsnetzwerk
WO2010063563A2 (fr) Procédé et dispositif pour autoriser une transaction
DE102005062061B4 (de) Verfahren und Vorrichtung zum mobilfunknetzbasierten Zugriff auf in einem öffentlichen Datennetz bereitgestellten und eine Freigabe erfordernden Inhalten
EP1480398B1 (fr) Procédé et système pour établir un service courrier électronique payant
EP1388138B1 (fr) Procede et dispositif de paiement de donnees pouvant etre appelees par l'intermediaire d'un reseau de donnees
DE60317587T2 (de) Verfahren und System zum Zugang zu digitalem Inhalt in einem Endgerät
DE102005025489B4 (de) Verfahren und Computerprogramm zum Kontrollieren eines Zugriffs auf einen Informationsinhalt
EP1274971A2 (fr) Procede de paiement securise de livraisons et de services dans des reseaux ouverts
DE10213073B4 (de) Verfahren zum Abrechnen einer kostenpflichtigen Benutzung von Daten und Datenübertragungsnetz
DE10021756C2 (de) Systeme, Computerprogramm-Produkte, Tarifierungsserversysteme und Verfahren zur variablen Tarifierung von Internetgebühren in Abhängigkeit von gewählten Internetangeboten
DE10065067B4 (de) Verfahren zum Verifizieren nutzerspezifischer Informationen in einem Daten- und/oder Kommunikationssystem sowie Daten- und/oder Kommunikationssystem
EP1300794A2 (fr) Serveur de commande pour soutenir la taxation des services
EP1378843A1 (fr) Méthode et système de traitement de données pour la communication sécurisée entre l' administration et le public
DE10229619A1 (de) Verfahren zur Durchführung eines Zahlungsvorganges

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004741390

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2004741390

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2004741390

Country of ref document: EP