EP1368792A2 - Verfahren zur bezahlung von entgeltpflichtigen angeboten, die über ein netz erfolgen - Google Patents

Verfahren zur bezahlung von entgeltpflichtigen angeboten, die über ein netz erfolgen

Info

Publication number
EP1368792A2
EP1368792A2 EP02712932A EP02712932A EP1368792A2 EP 1368792 A2 EP1368792 A2 EP 1368792A2 EP 02712932 A EP02712932 A EP 02712932A EP 02712932 A EP02712932 A EP 02712932A EP 1368792 A2 EP1368792 A2 EP 1368792A2
Authority
EP
European Patent Office
Prior art keywords
internet
user
network
data
identification
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP02712932A
Other languages
English (en)
French (fr)
Inventor
Renate Zygan-Maus
Ulrich Mitreuter
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens 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
Application filed by Siemens AG filed Critical Siemens AG
Priority to EP02712932A priority Critical patent/EP1368792A2/de
Publication of EP1368792A2 publication Critical patent/EP1368792A2/de
Withdrawn legal-status Critical Current

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/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/04—Payment circuits
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • an Internet user can receive offers that are subject to a fee (eg data or information provision offers, order business offers, etc.) that he receives and accepts with a PC via his Internet access, via his Internet access bill can pay (even if the offers are not provided by their own Internet access provider).
  • a fee eg data or information provision offers, order business offers, etc.
  • the method according to the invention is based on an Internet user identification in accordance with the "method for network-wide identification of Internet users" described in the appendix. If the Internet user identification procedure mentioned is used for the IP messages of the Internet user with which he transmits his purchase request, the Internet access provider of the user and the Internet user can be determined for offline billing. The billing is expediently carried out via the user's Internet access provider who already has a business relationship with the user (collection service for the information seller):
  • a payment service provider provides a special payment server, through which the internet user consents to the collection of the purchase amount and via which the data or information subject to payment is transmitted and monitored in the event of a data or information provision becomes.
  • the payment server stores the data assigned to each purchase process, in particular the Internet user identification data, the confirmed purchase amount, an identification for the information purchased and for the information seller, and forwards it offline to the Internet access provider of the user for billing.
  • the purchase amount to be paid by the user is divided between the information seller, the payment service provider and the Internet access provider of the user according to previously agreed rules.
  • the payment service provider may or may not be the same as an Internet access provider.
  • a payment service provider that is not identical to the Internet access provider of the user requires a trustworthy business relationship with the Internet access provider in order to use the collection service of an Internet access provider, the Internet access provider in technical terms the Internet access service feature "identification of the Internet user" is required.
  • the information seller is a customer of the payment service provider.
  • the new method enables an independent 3rd party (the payment service provider) to record details of the TCP / IP-based information transfer process (used TCP / IP addresses and port numbers, time, duration, amount of data transferred) for a possible later check.
  • the payment service provider the payment service provider
  • a variant of the method in which the billing is carried out by a payment service provider that is not identical to the user's Internet access provider is possible.
  • the Internet access provider does not collect payments for the payment service provider, but instead transfers the data required for billing (name, address of the Internet user) to him on request.
  • the data required for billing name, address of the Internet user
  • a special feature of the invention lies in the use of the method described in the introduction "simple method for network-wide identification of Internet users" in connection with a special payment service server, so that it is possible without a direct business relationship between the information provider and the buyer, Internet information to buy and sell.
  • An internet user with the internet access service feature "Identification of the internet user” finds a web page with an offer that interests him.
  • the owner of the website has integrated a "Click-to-Pay-via-Internet service” button on his website, which the Internet user (identified via new IP protocol data) clicks on when he initiates the purchase of the information offered would like to
  • the server of the payment service provider creates a corresponding ticket for this, which is included in the creation of the internet access bill offline. At the same time, it establishes a TCP / IP connection to the server of the
  • Information provider from whom he receives the requested information and forwards it to the PC of the buyer. Every payment transaction, including an unsuccessful transaction, is logged by the payment service provider's server.
  • the customer of the payment service provider is the information provider who uses the Internet payment service.
  • a network-wide introduction of the Internet user identification service according to the invention would significantly increase trust in IP messages and would greatly facilitate the spread of commercial applications with their potentially higher security requirements and would help to curb Internet abuse.
  • the previously known methods for secure identification (authentication) of an Internet user all use the principle of end-to-end authentication.
  • This data can either a) be known to the other communication partner before the start of communication (sufficient Identification and authentication data are stored at the communication partner) or b) the other communication partner is informed at the start of communication using a trustworthy 3rd instance (identification and authentication data are stored at a central public certification authority).
  • IPSEC is not suitable for the technical problem to be solved, since 1. the majority of Internet users use dial-in access and are only assigned a temporary IP address by their Internet access provider;
  • TCP functions TCP functions
  • Application programs are used that use TCP / IP. It requires adjustments in the application programs and the provision of end-to-end identification and authentication data either according to principle a) or b).
  • a shared secret e.g. a password that is only known to the user and his communication partner is also transferred in the application log or - in the application user data. This method can only be used in combination with a transmission that is secured against "eavesdropping" (e.g. encrypted).
  • a shared secret is used to encrypt part of the message. If the recipient can decrypt the message, the sender is authenticated as the owner of the encryption key.
  • a challenge-response procedure in the application protocol proves that the user has a shared secret.
  • a shared secret is used to create a digital fingerprint of the message that is attached to the message. If this fingerprint can be reproduced by the recipient, the sender is authenticated as the owner of the shared secret. 5. With the help of his "private key" of an asymmetrical authentication method, the sender creates a digital fingerprint of the message to be sent, which is attached to the message and additionally attaches his electronic certificate to the message. This certificate contains the "public key" and the name of the user. The recipient can use this public key to verify the digital fingerprint. The recipient must now also verify the certificate. This is done according to the standard procedure for certificates.
  • the certificate contains a digital fingerprint of the data of the certificate, made with the private key of a certification authority. If the recipient has the public key of the certification authority, he can check the integrity of the user's certificate. Having the private key that was used to generate the digital fingerprint of the message authenticates the user.
  • the disadvantage of all known methods is the great effort for the installation, administration and maintenance of the various databases that contain the identification and authentication data of the Internet users (either central, expensive certificate depots, or many decentralized subscriber databases with different service providers) as well as in the management of the infrastructure that is to ensure the integrity of the identification data (eg certificate revocation lists, security policy database).
  • This effort is due to the fact that each Internet user carries out the identification and authentication procedures himself (principle of end-to-end authentication).
  • the Internet access provider can provide its customers' IP messages with data that enables the Internet user's IP packets to be identified.
  • the Internet access provider guarantees the integrity of this data using cryptographic means.
  • the difference to the known methods mentioned above is that it is no longer the Internet user who initiates his identification himself, but the Internet access provider who does this.
  • the invention reduces the effort for the identification of IP packets by Internet users.
  • a prerequisite for the new identification and authentication method according to the invention is that the Internet access provider has a business relationship with the Internet user. He thus has data that can identify the Internet user. If the Internet user uses the access service of the Internet access provider (e.g. when establishing an Internet connection via the telephone line), he must authenticate himself to the Internet access provider at the beginning (typically with an account name and a password that the Internet access provider has saved). After authentication, the identity of the Internet user is thus known to the Internet access provider. He can now add information identifying the Internet user to all IP packets of the Internet user.
  • the IP packets of the Internet user can be identified by other Internet service providers without the Internet user himself having to provide them with his identification data, either according to principle a), ie the service provider must Store and administer Internet user-specific data yourself, or according to principle b), ie with the help of a central certification authority).
  • An analogy from the Public Switching Telephone Network PSTN may illustrate the idea.
  • the caller's calling number is set up by the telephone network.
  • the operator of the telephone network guarantees that this number really identifies the connection of the calling number, the number of the calling subscriber is "network provided" or "user-provided, verified and passed".
  • the calling subscriber is unable to change the number because it is set up by the network and not by the subscriber.
  • Other telephone network subscribers cannot change this number either. It is therefore always possible to reliably identify the connections taking part in a telephone call. This is not possible in the IP network, because firstly the sender IP addresses can be falsified in the IP messages and secondly the IP addresses are only made available to Internet users temporarily.
  • the Internet access provider as a trustworthy entity in an IP network can provide the IP message with forgery-proof information provided by the network for identifying the Internet user.
  • the invention makes use of the point-to-point Internet user identification that is customary for Internet access between the Internet user and his Internet access provider, in order to use a trustworthy Internet access provider (equipped with a public certificate) to provide secure identification of an Internet user across the network.
  • IP packets are then examined to determine whether a certain (still to be defined) flag, a so-called
  • Authentication request flag is set, which means that the Internet user can be requested to add identification data per IP packet, and / or
  • a database which has an analog function like the Security Policy Database at IPSEC is used to check whether the service "Provide IP packets with identification data" is requested for Internet users becomes. Selectors can be the destination IP address, the transport protocol or the TCP / UDP ports. If so, the Internet access provider adds the data that identifies the Internet user to the IP packet header. For example, a telephone number of the Internet user is possible, or his user name used for the subscription to his Internet access, which is known to his Internet access provider.
  • the Internet access provider uses the modified IP packet, including the unchanged user data sent by the user, to create a digital signature in order to protect the identification data and the user data sent from the user from falsification (data integrity). For this purpose, a checksum is calculated via the modified IP packet and encrypted with the ISP's secret key (Integrity Check Value). Finally, the Internet access provider adds its electronic certificate (ISP X.509 Certificate) to the IP packet header, which contains the ISP's public key for decrypting the checksum. Each recipient of the IP message can thus check the correctness of the digital signature by decrypting the checksum and comparing it with the checksum that the recipient has calculated. In addition, the recipient has the option of accessing further data of the Internet user (name, address) via the certificate owner (the Internet access provider) specified in the certificate. (This could be used for Malicious Caller Identification.)
  • the proposed implementation is similar to IPSEC.
  • the main difference is that, in contrast to IPSEC, no point-to-point authentication but point-to-multipoint authentication can be implemented, since all data relevant for authentication (the "name" of the Internet user, the name of the Internet access providers (ISPs) and his certificate) are included in the IP package.
  • ISPs Internet access providers
  • IP level requires a new optional function of the IP stack. If this function is not available in a recipient host, the entire new AOD information (see FIG. 3) of an IP message must be ignored. For unknown IP options, this function is already supported by standard IP stacks.
  • IP payload can be changed on the way of the IP message to the actual communication partner, e.g. by authorized proxies (e.g. the VIA field for SIP, IP addresses for NAT).
  • authorized proxies e.g. the VIA field for SIP, IP addresses for NAT.
  • the proxy then also recalculates the TotalLength field and HeaderChecksum in the IP header.
  • the proxy can either already be the end host of the transmission secured according to the invention. This is the case, for example, when the proxy authenticates the Internet user to check whether the user is e.g. is already a customer of the message recipient. The proxy checks the AOD and forwards the IP message without the AOD.
  • the proxy adjusts the AOD information and signs these changes using a digital signature.
  • the proxy calculates the integrity check value and overwrites the previous one.
  • he replaces the ISP certificate with his certificate and extends the Origin Identification data for information that identifies the ISP.
  • the advantage of the implementation at the IP level compared to an implementation at the transport or application level is that the Internet access provider can see very quickly in the POP whether identification data should be inserted or not, since only the IP header analyzes or the policy database must be queried (performance advantage).
  • the data of the higher protocol levels, which are exchanged end-to-end, are not changed.
  • the applications on Internet hosts that use this new IP option require an extended IP network interface (IP socket - Interface) in order to set the authentication flag for an IP packet or sender identification data to the IP - Pass network interface and read incoming sender identification data.
  • IP socket - Interface IP socket - Interface
  • the ISP which offers the new Internet access service feature "Identification of Internet users" needs a policy database that must be administered.
  • the ISP needs a certificate from a public certification authority for itself, which must also be administered and maintained (update of the certificate revocation lists, etc.).

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (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)
  • Computer Security & Cryptography (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephone Function (AREA)
  • Meter Arrangements (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Die Erfindung ermöglicht es, dass ein Internet-Nutzer entgeltpflichtige Angebote, die er mit einem Rechner über seinen Internet-Zugang empfängt und annimmt, über seine Internet-Zugangsrechnung bezahlen kann.

Description

Beschreibung
Verfahren zur Bezahlung von entgeltpflichtigen Angeboten, die über ein Netz erfolgen
1. Welches technische Problem soll durch Ihre Erfindung gelöst werden?
2. Wie wurde dieses Problem bisher gelöst?
3. In welcher Weise löst Ihre Erfindung das angegebene technische Problem (geben Sie Vorteile an) ?
4. Worin liegt eine Besonderheit der Erfindung ?
5. Ausführungsbeispiel [e] der Erfindung.
Zu Punkt 1: Welches technische Problem soll durch Ihre Erfindung gelöst werden?
Es soll möglich sein, dass ein Internet-Nutzer, entgeltpflichtige Angebote (z.B. Daten- bzw. Informationsbereitstellungs-Angebote, Bestellungsgeschäfts- Angebote, usw.), die er mit einem PC über seinen Internet- Zugang empfängt und annimmt, über seine Internet- Zugangsrechnung bezahlen kann (und zwar auch dann, wenn die Angebote nicht von seinem eigenen Internet-Zugangs-Provider bereitgestellt werden) .
Zu Punkt 2: Wie wurde dieses Problem bisher gelöst?
Da Bezahlvorgänge im Internet, die auf der (Ende-zu-Ende) Identifizierung und Authentisierung des Käufers (= Internet- Nutzers) über Kreditkartennummern oder über Zertifikate basieren, relativ viel technischen und organisatorischen Aufwand erfordern, wäre es wünschenswert (insbesondere für das Herunterladen von elektronischer Information aus dem Internet, aber auch für die Bestellung anderer Waren (insbesondere von Waren, deren Preis im Rahmen der monatlichen Internet-Zugangsgebühren liegen) ) , eine Bezahlung über den Internet-Zugangsdienst zu ermöglichen.
Bisherige Realisierungen für das Bezahlen von Angeboten, die nicht vom Internet-Zugangs-Provider selbst bereitgestellt werden, über die Internetzugangsrechung, sind unbekannt.
Zu Punkt 3: In welcher Weise löst Ihre Erfindung das angegebene technische Problem (geben Sie Vorteile an) ?
Das erfindungsgemäße Verfahren basiert auf einer Internet- User Identifikation gemäß dem im Anhang beschriebenen "Verfahren zur netzweiten Identifikation von Internet- Nutzern" . Falls für die IP-Nachrichten des Internet-Nutzers, mit denen er seinen Kaufwünsch überträgt, das genannte Internet-User-Identifizierungsverfahren eingesetzt wird, können der Internet-Zugangs-Provider des Nutzers und der Internet-Nutzer für eine offline-Rechnungsstellung ermittelt werden. Die Rechnungsstellung erfolgt zweckmäßigerweise über den Internet-Zugangs-Provider des Nutzers, der bereits eine Geschäftsbeziehung mit dem Nutzer hat (Inkasso-Dienstleistung für den Informationsverkäufer) :
Ein Bezahlungs-Dienst-Anbieter stellt einen speziellen Bezahlungsserver zur Verfügung, über den der Internet-Nutzer sein Einverständnis zum Inkasso des Kaufbetrages gibt und über den im Falle eines Daten- bzw. Informationsbereitstellungs-Angebotes die Übertragung der entgeltpflichtigen Daten bzw. Informationen erfolgt und überwacht wird. Vom Bezahlungsserver werden die jedem Kaufvorgang zugeordneten Daten, insbesondere die Internet- User-Identifizierungsdaten, der bestätigte Kaufbetrag, eine Identifikation für die gekaufte Information und für den Informationsverkäufer gespeichert und offline zur Rechnungserstellung an den Internet-Zugangs-Provider des Nutzers weitergeleitet. Der vom Nutzer zu zahlende Kaufbetrag wird zwischen dem Informationsverkäufer, dem Bezahlungs- Dienst-Anbieter und dem Internet-Zugangs-Provider des Nutzers nach zuvor vereinbarten Regeln aufgeteilt.
Der Bezahlungs-Dienst-Anbieter kann mit einem Internet- Zugangs-Provider identisch sein oder nicht. Ein nicht mit dem Internet-Zugangs-Provider des Nutzers identischer Bezahlungsdienste-Anbieter benötigt für die Inanspruchnahme der Inkasso-Dienstleistung eines Internet-Zugangs-Providers eine vertrauenswürdige Geschäftsbeziehung mit dem Internet- Zugangs-Provider, wobei der Internet-Zugangs-Provider in technischer Hinsicht das Internet-Zugangs-Dienstmerkmal "Identifikation des Internet-Nutzers" benötigt. Der Informationsverkäufer ist Kunde des Bezahlungs-Dienst- Anbieters .
Die Vorteile dieses neuen Verfahrens gegenüber anderen Verfahren sind:
- kostengünstiger für den Informationsverkäufer als das Kreditkartenverfahren - kostengünstiger für den Käufer als das Verfahren über nutzerbezogene, öffentliche Zertifikate
- sicherer für den Käufer als das Kreditkartenverfahren
- das neue Verfahren ermöglicht einer unabhängigen 3. Partei (dem Bezahlungs-Dienst-Anbieter) Details des TCP/IP-basierten Informationsübertragungsvorganges (verwendete TCP/IP-Adressen und Portnummern, Zeit, Dauer, übertragene Datenmenge) aufzuzeichnen für eine etwaige spätere Überprüfung.
Eine Variante des Verfahrens, in der die Rechnungsstellung von einem nicht mit dem Internet-Zugangs-Provider des Nutzers identischen Bezahlungsdienst-Anbieter erfolgt, ist möglich. In diesem Fall macht der Internet-Zugangs-Provider kein Inkasso für den Bezahlungs-Dienst-Anbieter, sondern übergibt ihm auf Anfrage die für die Rechnungsstellung notwendigen Daten (Name, Adresse des Internet-Nutzers) . Zu Punkt 4 : Worin liegt eine Besonderheit der Erfindung ?
Eine Besonderheit der Erfindung liegt in der Anwendung des im Angang beschriebenen Verfahrens "Einfaches Verfahren zur netzweiten Identifikation von Internet-Nutzern" in Verbindung mit einem speziellen Bezahlungs-Dienst-Server, sodaß es ohne eine direkte Geschäftsbeziehung zwischen dem Informationsanbieter und dem Käufer möglich wird, Internet- Informationen zu kaufen und zu verkaufen.
Zu Punkt 5: Ausführungsbeispiel [e] der Erfindung
Ablauf einer möglichen Realisierung des erfindungsgemäßen Verfahrens (siehe unterstützend dazu auch die entsprechend der nunmehr folgenden Verfahrensschritte nummerierte Figur 1)
1. Ein Internet-Nutzer mit dem Internet-Zugangs-Dienstmerkmal "Identifikation des Internet-Nutzers" findet eine Web- Seite mit einem ihn interessierenden Angebot. Der Eigentümer der Web-Seite hat auf seiner Web-Seite einen Button "Click-to-Pay-via-Internetservice" eingebaut, den der (via neue IP-Protokolldaten identifizierte) Internet- Nutzer anklickt, wenn er den Kauf der angebotenen Information einleiten möchte
2. Mit Standard-Internet-Verfahren (HTTP - Protokoll) wird durch das Anklicken des Buttons "Click-to-Pay-via- Internet-service" eine HTTP - Verbindung zwischen dem PC des Internet-Nutzers und einem Server des Bezahlungs- Dienst-Anbieters ( die Adresse des Bezahlungs-Dienst- Anbieters ist hinter dem Button versteckt, ein normales Browser-Verfahren) hergestellt. Dabei wird eine Referenz auf die gewählte entgeltpflichtige Information von der Web-Seite des Verkäufers/Informationsanbieters mit übertragen (Standard-Leistungsmerkmal von HTTP) . 3. Der Server des Bezahlungs-Dienst-Anbieters fragt via HTTPS den Käufer, ob er diesen Kauf mit dem angegebenen Preis tatsächlich tätigen möchte. Für diese HTTPS-Verbindung ist ein Server-Zertifikat ausreichend, der Nutzer benötigt kein eigenes Zertifikat.
4. Wenn der Käufer den Kauf bestätigt, legt der Server des Bezahlungs-Dienst-Anbieters ein entsprechendes Ticket dafür an, das in die Erstellung der Internet- Zugangsrechnung offline einfließt. Gleichzeitig stellt er eine TCP/IP-Verbindung zum Server des
Informationsanbieters her, über die er die nachgefragten Informationen empfängt und an den PC des Käufers weiterleitet. Jeder Bezahlungsvorgang, auch ein nicht erfolgreicher Vorgang, wird vom Server des Bezahlungs-Dienst-Anbieters protokolliert. Der Kunde des Bezahlungs-Dienst-Anbieters ist der Informations-Anbieter, der den Internet-Bezahlungsdienst einsetzt .
Anhang
Verfahren zur netzweiten Identifikation von Internet-Nutzern
1. Welches technische Problem soll durch Ihre Erfindung gelöst werden?
2. Wie wurde dieses Problem bisher gelöst? 3. In welcher Weise löst Ihre Erfindung das angegebene technische Problem (geben Sie Vorteile an) ? 4. Ausführungsbeispiel [e] der Erfindung.
Zu Punkt 1: Welches technische Problem soll durch Ihre Erfindung gelöst werden? Internet-Zugang wird für den Massenmarkt heute von den Internet-Zugangsprovidern ohne das Dienstmerkmal "netzweite Identifikation des Internet-Nutzers" angeboten. Neue Internet-basierte Dienste erfordern jedoch eine Identifikation des Internet-Nutzers gegenüber dem Dienste- Anbieter. Diese Identifikation soll auch gegen Manipulationen und Mißbrauch durch einen anderen Internet-Nutzer gesichert sein. Z.B. setzen Internet-Telefonie-Dienste und Internet- Telefonnetz-Konvergenzdienste voraus, daß der Nutzer dieser Dienste (d.h. der Absender der IP-Pakete, die die Dienst- Signalisierungsdaten beinhalten) identifiziert wird. Der Anbieter solcher neuen Internet-Dienste ist nicht notwendigerweise identisch mit dem Internet-Zugangs-Provider des Internet-Users.
Eine netzweite Einführung des erfindungsgemäßen Internet- User-Identifizierungsdienstes würde das Vertrauen in IP- Nachrichten wesentlich vergrößern und der Verbreitung kommerzieller Anwendungen mit ihren potentiell höheren Sicherheitsanforderungen sehr entgegenkommen sowie mithelfen, den Internet-Mißbrauch einzudämmen.
Zu Punkt 2 : Wie wurde dieses Problem bisher gelöst?
Die bisher bekannten Verfahren für die gesicherte Identifikation (Authentifikation) eines Internet-Nutzers verwenden alle das Prinzip der Ende-zu-Ende Authentisierung. D.h. die Kommunikationspartner authentisieren sich auf der Basis von Identifizierungs- und Authentisierungsdaten, die jedem Kommunikationspartner individuell zugeordnet und dem anderen Kommunikationspartner bekannt gemacht werden. Diese Daten können entweder a) dem anderen Kommunikationspartner vor Beginn der Kommunikation bereits bekannt sein (hinreichende Identifizierungs- und Authentisierungsdaten sind beim Kommunikationspartner gespeichert) oder b) dem anderen Kommunikationspartner beim Beginn der Kommunikation mithilfe einer vertrauenswürdigen 3. Instanz mitgeteilt werden (Identifizierungs- und Authentisierungsdaten sind bei einer zentralen öffentlichen Zertifizierungsinstanz gespeichert) .
Bisher bekannte Prozeduren für die gesicherte Identifikation eines Internet-Nutzers sind:
I. Identifizierung und Authentisierung über die von den Kommunikationspartnern verwendeten IP-Hosts: IPSEC Diese Prozedur hat zur Voraussetzung, dass beide Kommunikationspartner statische IP-Adressen nutzen und diese IP-Adressen eineindeutig beiden
Kommunikationspartnern zugeordnet sind.
IPSEC ist für das zu lösende technische Problem nicht geeignet, da 1. der Großteil der Internet-Nutzer Dial-in Zugang verwendet und von ihrem Internet-Zugangsprovidern nur eine temporäre IP-Adresse zugewiesen bekommen;
2. IPSEC als Punkt-zu-Punkt Methode vom Typ a) die
Speicherung der Identifizierungs- und Authentisierungsdaten aller potentiellen
Kommunikationspartner erfordert und daher für den
Massenmarkt neuer Internet-Dienste ungeeignet ist.
II. Identifizierung und Authentisierung durch TCP - Funktionen (TLS, Transport Layer Security) Diese Prozedur kann im Prinzip von allen
Anwendungsprogrammen genutzt werden, die TCP/IP verwenden. Sie erfordert Anpassungen in den Anwendungsprogrammen sowie Bereitstellung von end-to-end Identifizierungs- und Authentisierungsdaten entweder nach Prinzip a) oder b) .
III. Identifizierung und Authentisierung durch die verwendeten Anwendungsprogramme Die Daten zur Identifizierung des Users, z.B. sein "Name", werden im Applikationsprotokoll (z.B. HTTP, FTP, Telnet, SIP) im Klartext übertragen. Für den Beweis, daß der Absender der Träger des Namens ist, d.h. für die Authentisierung des Namens, gibt es mehrere Möglichkeiten, z.B.
1. Ein gemeinsames Geheimnis, z.B. ein Paßwort, welches nur dem User und seinem Kommunikationspartner bekannt ist, wird im Applikationsprotokoll oder - in den Applikationsnutzdaten mitübertragen. Diese Methode ist nur in Kombination mit einer gegen "Abhören" gesicherten (z.B. verschlüsselten) Übertragung einsetzbar.
2. Ein gemeinsames Geheimnis wird dazu verwendet, einen Teil der Nachricht zu verschlüsseln. Kann der Empfänger die Nachricht entschlüsseln, ist der Absender als Besitzer des Verschlüsselungschlüssels authentifiziert .
3. Durch ein Challenge-Response-Verfahren im Applikationsprotokoll wird der Beweis erbracht, daß der User im Besitz eines gemeinsamen Geheimnisses ist. 4. Ein gemeinsames Geheimnis wird dazu verwendet, einen digitalen Fingerabdruck der Nachricht zu erzeugen, der an die Nachricht angehängt wird. Kann dieser Fingerabdruck vom Empfänger reproduziert werden, ist der Absender als Besitzer des gemeinsamen Geheimnisses authentifiziert. 5. Der Absender erzeugt mit Hilfe seines "private key" eines asymmetrischen Authentifizierungsverfahrens einen digitalen Fingerabdruck der zu versendenden Nachricht, der an die Nachricht angehängt wird und hängt an die Nachricht zusätzlich sein elektronisches Zertifikat an. Dieses Zertifikat enthält den "public key" und den Namen des Users. Der Empfänger kann mit Hilfe dieses public key den digitalen Fingerabdruck verifizieren. Der Empfänger muß nun auch das Zertifikat verifizieren. Dies erfolgt entsprechend dem Standard-Verfahren für Zertifikate. Dazu enthält das Zertifikat einen digitalen Fingerabdruck der Daten des Zertifikats, angefertigt mit dem private key einer Zertifizierungsinstanz. Besitzt der Empfänger den öffentlichen Schlüssel der Zertifizierungsinstanz, kann er die Integrität des Zertifikats des Users überprüfen. Der Besitz des privaten Schlüssels, der für die Erzeugung des digitalen Fingerabdruckes der Nachricht verwendet wurde, authentifiziert den User.
Der Nachteil aller bekannten Verfahren ist der große Aufwand für die Installation, Administration und Pflege der verschiedenen Datenbanken, die die Identifikations- und Authentisierungsdaten der Internet-Nutzer enthalten (entweder zentrale, teure Zertifikat-Depots, oder viele dezentrale Subscriber-Datenbanken bei verschiedenen Diensteanbietern) sowie im Management der Infrastruktur, die die Integrität der Identifikationsdaten sichern soll (z.B. Zertifikat- Revocation-Listen, Security Policy Database) . Dieser Aufwand ist dadurch gegeben, daß jeder Internet-Nutzer die Identifikations- und Authentifizierungs-prozeduren selbst durchführt (Prinzip der Ende-zu-Ende Authentisierung) .
Zu Punkt 3: In welcher Weise löst Ihre Erfindung das angegebene technische Problem (geben Sie Vorteile an) ?
Der Internet-Zugangs-Provider versieht IP-Nachrichten seiner Kunden auf Wunsch mit Daten, die die Identifikation der IP- Pakete des Internet-Nutzers ermöglichen. Der Internet- Zugangs-Provider garantiert die Integrität dieser Daten mit kryptographischen Mitteln.
Der Unterschied zu den oben genannten bekannten Verfahren liegt also darin, daß nicht mehr der Internet-Nutzer selbst seine Identifikation initiiert sondern der Internet-Zugangs- Provider dies übernimmt. Durch die Erfindung wird der Aufwand für die Identifikation von IP-Paketen von Internet-Nutzern reduziert. Voraussetzung für das erfindungsgemäße neue Identifizierungsund Authentisierungsverfahren ist, dass der Internet-Zugangs- Provider mit dem Internet-Nutzer eine Geschäftsbeziehung unterhält. Damit besitzt er Daten, die den Internet-Nutzer identifizieren können. Nimmt der Internet-Nutzer den Zugangs- Dienst des Internet-Zugangs-Providers in Anspruch (z.B. beim Aufbau einer Internet-Verbindung über die Telefonleitung) , so muß er sich dem Internet-Zugangs-Provider gegenüber zu Beginn authentifizieren (typischerweise mit einem Accountname und einem Passwort, welche der Internet-Zugangs-Provider gespeichert hat) . Nach der Authentifizierung ist dem Internet-Zugangs-Provider die Identität des Internet-Nutzers somit gesichert bekannt. Er kann nun eine den Internet-Nutzer identifizierende Information allen IP-Paketen des Internet- Nutzers beifügen. Mit dieser Information können die IP-Pakete des Internet-Nutzers von anderen Internet-Dienst-Anbietern identifiziert werden, ohne daß der Internet-Nutzer selbst ihnen seine Identifikationsdaten bereitstellen muß, und zwar entweder nach Prinzip a) , d.h. der Dienst-Anbieter muß die Internet-Nutzer-spezifischen Daten selbst speichern und administrieren, oder nach Prinzip b) , d.h. mithilfe einer zentralen Zertifizierungsinstanz) .
Eine Analogie aus dem Public Switching Telephone Network PSTN mag die Idee verdeutlichen. Beim Rufaufbau im Telefonnetz wird die Rufnummer des anrufenden Teilnehmers vom Telefonnetz aufgesetzt. Der Betreiber des Telefonnetzes garantiert, daß diese Nummer wirklich den Anschluß der anrufenden Nummer identifiziert, die Rufnummer des anrufenden Teilnehmers ist "network provided" oder "user-provided, verified and passed" . Der anrufende Teilnehmer ist nicht in der Lage, die Nummer zu verändern, da sie vom Netzwerk und nicht vom Teilnehmer aufgesetzt wird. Auch andere Telefonnetzteilnehmer können diese Nummer nicht verändern. Damit ist es immer möglich, die an einem Telefongespräch teilnehmenden Anschlüsse sicher zu identifizieren. Im IP Netz ist dies nicht möglich, da erstens die Absender- IP-Adressen in den IP-Nachrichten gefälscht werden können und zweitens die IP Adressen den Internet-Nutzern nur temporär zur Verfügung gestellt werden. Erfindungsgemäß kann in einem IP Netz jedoch der Internet-Zugangs-Provider als vertrauenswürdige Instanz die IP-Nachricht fälschungssicher mit einer durch das Netzwerk aufgesetzten Information zur Identifikation des Internet-Nutzers versehen.
Die Erfindung nutzt die für den Internet-Zugang übliche Punkt-zu-Punkt Internet-Nutzer-Identifizierung zwischen dem Internet-Nutzer und seinem Internet-Zugangs-Provider aus, um über einen vertrauenswürdigen (mit einem öffentlichen Zertifikat ausgestatteten) Internet-Zugangs-Provider eine gesicherte Identifizierung eines Internet-Nutzers netzweit zur Verfügung zu stellen.
Zu Punkt 4: Ausführungsbeispiel [e] der Erfindung
Für eine generische Lösung (Lösung, die unabhängig vom verwendeten Transport - oder Applikationsprotokoll ist) mit möglichst guter Performance wird eine Realisierung auf der IP-Ebene vorgeschlagen (siehe Figuren 2 und 3) .
Am POP (Point-of-Presence, Zugangsknoten) des Internet- Zugangs-Providers werden
• die IP-Pakete daraufhin untersucht, ob ein bestimmtes (noch zu definierendes) Flag, ein sogenanntes
Authentication-Request Flag gesetzt ist, wodurch für den Internet-Nutzer ein Hinzufügen von Identifikationsdaten pro IP-Paket angefordert werden kann, und/oder
• es wird in einer Datenbank (die eine analoge Funktion besitzt wie die Security Policy Database bei IPSEC) nachgeschaut, ob für den Internet-Nutzer der Dienst "IP- Pakete mit Identifizierungsdaten versehen" angefordert wird. Selektoren können dabei die Destination IP-Address, das Transportprotokoll oder die TCP/UDP Ports sein. Wenn ja , fügt der Internet-Zugangs-Provider dem IP-Paket- Header die Daten hinzu, die den Internet-Nutzer identifizieren. Möglich ist z.B. eine Telefonnummer des Internet-Nutzers, oder sein für die Subskription seines Internet-Zugangs verwendeter User-Name, die seinem Internet- Zugangs-Provider bekannt ist.
Der Internet-Zugangs-Provider bildet anschließend über das modifizierte IP-Paket einschließlich der vom Nutzer gesendeten unveränderten Nutzdaten eine digitale Unterschrift, um die Identifikationsdaten und die vom Nutzer gesendeten Nutzdaten vor Verfälschung zu sichern (Datenintegrität) . Dazu wird eine Prüfsumme über das modifizierte IP Paket berechnet und diese mit dem geheimen Schlüssel des ISP' s verschlüsselt (Integrity Check Value) . Abschließend fügt der Internet-Zugangs-Provider dem IP-Paket- Header sein elektonisches Zertifikat (ISP X.509 Certificate) , welches den öffentlichen Schlüssel des ISP' s zur Entschlüsselung der Prüfsumme enthält, hinzu. Somit kann jeder Empfänger der IP-Nachricht die digitale Unterschrift auf Korrektheit überprüfen, indem er die Prüfsumme entschlüsselt und mit der Prüfsumme, die der Empfänger berechnet hat, vergleicht. Außerdem hat der Empfänger die Möglichkeit, über den im Zertifikat genannten Besitzer des Zertifikates (den Internet-Zugangs-Provider) an weitere Daten des Internet-Nutzers (Name, Adresse) zu gelangen. (Dies könnte für Malicious Caller Identification verwendet werden.)
Die vorgeschlagene Realisierung besitzt Ähnlichkeiten mit IPSEC. Der wesentliche Unterschied ist jedoch, daß im Gegensatz zu IPSEC keine point-to-point Authentifizierung sondern eine point-to-multipoint Authentifizierung realisiert werden kann, da alle für die Authentifizierung relevanten Daten (der "Name" des Internet-Nutzers, der Name des Internet-Zugangs-Providers (ISPs) und sein Zertifikat) im IP- Paket enthalten sind. Außerdem liegt weder eine End-to-End noch eine Host-to-Host Authentifizierung vor, sondern eine ISP-to-Host Authentifizierung.
Die Realisierung der Internet-Nutzer-Identifikation auf IP- Ebene erfordert eine neue optionale Funktion des IP-Stacks. Falls diese Funktion in einem Empfänger-Host nicht verfügbar ist, ist die gesamte neue AOD-Information (siehe FIG.3) einer IP-Nachricht zu ignorieren. Diese Funktion wird für unbekannte IP Options bereits heute von Standard-IP-stacks unterstützt .
Da sich die Länge einer IP-Nachricht durch das Einfügen der AOD-Information ändert, müssen sowohl das TotalLength Feld als auch die HeaderChecksum im IP Header neu berechnet werden. Die digitale Unterschrift des Internet-Zugangs- Providers gilt solange, wie sich die Daten in der IP Payload nicht ändern.
Es ist möglich, dass Daten in der IP Payload auf dem Weg der IP-Nachricht zum eigentlichen Kommunikationspartner verändert werden können, z.B. durch autorisierte Proxies (z.B. das VIA Feld bei SIP, IP Adressen bei NAT) . Der Proxy berechnet dann ebenfalls TotalLength Feld sowie HeaderChecksum im IP Header neu.
In einem solchen Fall kann der Proxy entweder bereits End- Host der erfindungsgemäß gesicherten Übertragung sein. Dies ist beispielsweise der Fall, wenn der Proxy die Authentifizierung des Internet-Nutzers durchführt um zu prüfen, ob dieser z.B. bereits ein Kunde des Nachrichten- Empfängers ist. Der Proxy überprüft die AOD und sendet die IP Nachricht weiter ohne die AOD.
Oder der Proxy nimmt eine Anpassung der AOD-Information vor und signiert diese Änderungen mittels digitaler Unterschrift. Dazu berechnet der Proxy den Integrity Check Value und überschreibt den bisherigen. Zusätzlich ersetzt er das ISP Zertifikat durch sein Zertifikat und erweitert die Origin Identification Data um Informationen, die den ISP identifizieren.
Der Vorteil der Realisierung auf IP-Ebene gegenüber einer Realisierung in der Transport- oder Anwendungsebene ist es, daß der Internet-Zugangs-Provider im POP sehr schnell sehen kann, ob Identifikationsdaten eingefügt werden sollen oder nicht, da dazu nur der IP Header analysiert oder die Policy Datenbank abgefragt werden muß (Performance-Vorteil) . Die Daten der höheren Protokollebenen, die Ende-zu-Ende ausgetauscht werden, werden nicht verändert. Die Applikationen auf Internet-Hosts, die diese neue IP-Option verwenden, benötigen eine erweiterte IP-Netzschnittstelle (IP socket - Interface), um abgehend ggf. das Authentication-Flag für ein IP-Paket zu setzen oder Absender- Identifizierungsdaten an die IP-Netzschnittstelle zu übergeben und ankommend empfangene Absender- Identifizierungsdaten zu lesen. Der ISP, der das neue Internet-Zugangs-Dienstmerkmal "Identifikation von Internet- Nutzern" anbietet, benötigt eine Policy Datenbank, die administriert werden muß. Zusätzlich benötigt der ISP für sich selbst ein Zertifikat einer öffentlichen Zertifizierungsinstanz, welches auch verwaltet und gepflegt werden muß (Update der Certificate-Revocation-Lists usw.).

Claims

Patentansprüche
1. Verfahren zur Bezahlung von entgeltpflichtigen Angeboten, die über ein Netz erfolgen, demgemäß - durch einen Client eines Netz-Nutzers ein entgeltpflichtiges Angebot, auf das der Netz-Nutzer über einen Angebots-Server hingewiesen wird, angefordert wird,
- daraufhin dem Client von dem Angebots-Server eine Referenz auf das entgeltpflichtige Angebot sowie auf einen Bezahlungsdienst-Server mitgeteilt wird,
- daraufhin das genannte Angebot durch den Client von dem genannten Bezahlungsdienst-Server angefordert wird, wobei der Anforderungsnachricht von dem Netzugangs-Server des Netz-Nutzers hierbei die Identität des Netz-Nutzers und seines Netzzugangs-Providers hinzugefügt werden,
- das Erbringen der gemäß dem Angebot offerierten Leistung von dem genannten Bezahlungsdienst-Server vermittelt bzw. durchgeführt wird,
- die Gebühren für die Inanspruchnahme des entgeltpflichtigen Angebots von dem genannten Bezahlungsdienst-Server aufgezeichnet werden,
- anhand der genannten aufgezeichneten Gebühren von einem Billing System eine Rechnung für den genannten Netz-Nutzer erstellt wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet , daß es sich bei dem genannten Billing System um das Billing System des Netzzugangs-Providers handelt.
3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß es sich bei dem genannten Billing System um das Billing System des genannten Bezahlungsdienst-Anbieters handelt.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch geken zeichnet, daß
- es sich bei der durch das Angbot offerierten Leistung um das zur Verfügungstellen von Daten bzw. Informationen handelt,
- die genannten Daten bzw. Informationen aus dem Netz über den genannten Bezahlungsdienst-Server heruntergeladen werden.
EP02712932A 2001-03-02 2002-02-28 Verfahren zur bezahlung von entgeltpflichtigen angeboten, die über ein netz erfolgen Withdrawn EP1368792A2 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP02712932A EP1368792A2 (de) 2001-03-02 2002-02-28 Verfahren zur bezahlung von entgeltpflichtigen angeboten, die über ein netz erfolgen

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
EP01105176 2001-03-02
EP01105176 2001-03-02
EP02712932A EP1368792A2 (de) 2001-03-02 2002-02-28 Verfahren zur bezahlung von entgeltpflichtigen angeboten, die über ein netz erfolgen
PCT/EP2002/002182 WO2002071350A2 (de) 2001-03-02 2002-02-28 Verfahren zur bezahlung von entgeltpflichtigen angeboten, die über ein netz erfolgen

Publications (1)

Publication Number Publication Date
EP1368792A2 true EP1368792A2 (de) 2003-12-10

Family

ID=8176663

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02712932A Withdrawn EP1368792A2 (de) 2001-03-02 2002-02-28 Verfahren zur bezahlung von entgeltpflichtigen angeboten, die über ein netz erfolgen

Country Status (3)

Country Link
US (1) US20040133499A1 (de)
EP (1) EP1368792A2 (de)
WO (1) WO2002071350A2 (de)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101064616A (zh) * 2006-04-28 2007-10-31 华为技术有限公司 一种网络计费方法、系统及设备
US8555057B2 (en) * 2006-07-21 2013-10-08 At&T Intellectual Property I, L.P. System and method for securing a network
US8316422B2 (en) * 2006-10-17 2012-11-20 Sap Ag Propagation of principal authentication data in a mediated communication scenario
US8321678B2 (en) * 2006-10-17 2012-11-27 Sap Ag System and method to send a message using multiple authentication mechanisms
US8302160B2 (en) * 2006-10-17 2012-10-30 Sap Ag Propagation of authentication data in an intermediary service component
US20080177656A1 (en) * 2007-01-22 2008-07-24 Microsoft Corporation Client applications with third party payment integration
WO2008144772A1 (en) * 2007-05-24 2008-11-27 Arpu, Inc. Subscription promotion and management system and method
US20090182675A1 (en) * 2008-01-04 2009-07-16 Brody Edward Method and system for conducting electronic commerce over a network using a shadow credit card number
US10966091B1 (en) * 2017-05-24 2021-03-30 Jonathan Grier Agile node isolation using packet level non-repudiation for mobile networks

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10507053A (ja) * 1995-05-24 1998-07-07 ウォーカー・アセット・マネイジメント・リミテッド・パートナーシップ オンライン・コンピュータ・サービス用の９００番料金請求・集金システム及び方法
FI113224B (fi) * 1996-11-11 2004-03-15 Nokia Corp Laskutuksen toteuttaminen tietoliikennejärjestelmässä
AU3625097A (en) * 1997-07-08 1999-02-08 France Telecom Interactive System and method for managing transactions between service suppliers and customers on a communication network
JPH1168987A (ja) * 1997-08-15 1999-03-09 Sony Corp 情報通信システム、情報通信端末、サーバ装置および情報通信方法
US6292789B1 (en) * 1997-08-26 2001-09-18 Citibank, N.A. Method and system for bill presentment and payment
US20020169664A1 (en) * 1997-12-01 2002-11-14 Walker Jay S. System for providing offers using a billing statement
FR2779896B1 (fr) * 1998-06-15 2000-10-13 Sfr Sa PROCEDE POUR PAYER A DISTANCE, AU MOYEN D'UN RADIOTELEPHONIQUE MOBILE, l'ACQUISITION D'UN BIEN ET/OU D'UN SERVICE ET SYSTEME ET RADIOTELEPHONE MOBILE CORRESPONDANTS
US20010032312A1 (en) * 2000-03-06 2001-10-18 Davor Runje System and method for secure electronic digital rights management, secure transaction management and content distribution

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO02071350A3 *

Also Published As

Publication number Publication date
WO2002071350A2 (de) 2002-09-12
WO2002071350A3 (de) 2003-09-25
US20040133499A1 (en) 2004-07-08

Similar Documents

Publication Publication Date Title
DE60218042T2 (de) Verfahren und system für einen dienstleistungsprozess zur bereitstellung eines dienstes zu einem kunden
DE60220718T2 (de) Verfahren und system zur sicheren behandlung von elektronischen geschäften im internet
DE602004003518T2 (de) Verfahren und System zum legalen Abfangen von Paketvermittlungsnetzwerkdiensten
DE60214632T2 (de) Multidomäne Berechtigung und Authentifizierung
EP3220597B1 (de) Verfahren und vorrichtung zum bereitstellen eines einmalpasswortes
DE69830726T2 (de) Verfahren zum betrieb eines systems von authentifizierungsservern sowie ein solches system
DE602004004325T2 (de) Verfahren und Vorrichtung zur Bereitstellung eines sicheren VPN-Zugriffs mittels veränderter Zertifikat-Zeichenketten
EP1316188B1 (de) Verfahren und Internet-Zugangsknoten zur Identifikation von Internet-Nutzern
WO2016008659A1 (de) Verfahren und eine vorrichtung zur absicherung von zugriffen auf wallets in denen kryptowährungen abgelegt sind
WO2007045395A1 (de) Vorrichtungen und verfahren zum durchführen von kryptographischen operationen in einem server-client-rechnernetzwerksystem
EP1241847A1 (de) Übermittlung von Informationen mit einer verifizierten QoS in einem Kommunikationsnetz
EP2245832A1 (de) Verfahren zum authentisieren einer schlüsselinformation zwischen endpunkten einer kommunikationsbeziehung
DE69925482T2 (de) Verfahren, einrichtung und gerät zur authentifizierung
WO2002095637A2 (de) Verfahren zum erbringen von diensten in einem datenübertragungsnetz und zugehörige komponenten
EP1128615A2 (de) Verfahren und Kommunikationseinrichtung zur Verschlüsselung von E-Mail
EP1368792A2 (de) Verfahren zur bezahlung von entgeltpflichtigen angeboten, die über ein netz erfolgen
WO2002093513A2 (de) Verfahren zum abrechnen von in einem rechnernetzwerk bereitgestellten diensten
EP2932677B1 (de) Verfahren für die sichere übertragung einer digitalen nachricht
DE60219915T2 (de) Verfahren zur Sicherung von Kommunikationen in einem Computersystem
EP1776821A1 (de) System und verfahren zum sicheren anmelden in einem kommuniktionssystem mit netzwerkverbindungs- und verbindungssteuerungs-rechnern
WO2002067532A1 (de) Verfahren zur übertragung von daten, proxy-server und datenübertragungssystem
DE102006010821B4 (de) Selbstzielsuchendes Datenübertragungssystem und Verfahren hierzu
EP4179758B1 (de) Authentisierung eines kommunikationspartners an einem gerät
EP1248432B1 (de) Verfahren und System zum Abfragen von Zertifikatsinformationen unter Verwendung von dynamischen Zertifikatsreferenzen
WO2007079792A1 (de) Verfahren und vorrichtung zum mobilfunknetzbasierten zugriff auf in einem öffentlichen datennetz bereitgestellten und eine freigabe erfordernden inhalten

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20030604

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

17Q First examination report despatched

Effective date: 20040714

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20070215