DE10034734A1

DE10034734A1 - Web-basierte, automatisierte Schnittstelle zwischen Informationsanbietern und einem Electronic Payment Provider

Info

Publication number: DE10034734A1
Application number: DE2000134734
Authority: DE
Original assignee: Accenture GmbH Germany
Current assignee: Accenture GmbH Germany
Priority date: 2000-07-17
Filing date: 2000-07-17
Publication date: 2002-01-31
Also published as: US9141980B2; CA2385055A1; WO2002007019A2; EP1301885A1; US20030120549A1; US20030014328A1; CA2385055C; AU2001272545A1

Description

Die Erfindung betrifft Systeme und Verfahren zum kontrollierten Bereitstellen, Verwalten, Speichern, Übertragen und/oder Verkaufen einer angebotenen Information im Internet oder einem anderen Netz und insbesondere eine Schnittstelle zwischen Informationsanbietern und einem Electronic Payment-Provider. Insbesondere betrifft die Erfindung eine web-basierte, automatisierte Schnittstelle zwischen Informationsanbietern und einem Electronic Payment-Provider mit einem Virtual Domain-Hoster als Aggregator und Kommisionär.

Informationsanbieter, die die von ihnen angebotenen Informationen im Internet verkaufen möchten, müssen bisher ein System zum elektronischen Zahlungsverkehr in ihre Web-Site integrieren.

Bekannte Lösungen haben die Nachteile, dass die Implementierung von Zahlungssystemen für Informationsanbieter technisch sehr aufwendig und zudem sehr teuer ist. Der Informationsanbieter muß bei bekannten Zahlungssystemen im Internet seinen Web-Auftritt neu konfigurieren, das Zahlungssystem aufwendig integrieren und insgesamt testen. Dafür ist in den meisten Fällen ein erheblicher Programmieraufwand nötig.

Weiterhin sind die bekannten Zahlungssysteme für den Informationsanbieter aus Kostengründen unattraktiv, da bei jedem Kauf eine Online-Transaktion notwendig ist und dabei hohe Gebühren für den Informationsanbieter anfallen.

Der Erfindung liegt daher unter anderem die Aufgabe zugrunde, eine technisch einfacher zu integrierende und zu handhabende und insgesamt kostengünstigere Lösung für den Verkauf von Informationen im Internet bereitzustellen.

Die Aufgabe wird durch die vorliegende Erfindung gelöst. Dabei werden durch die Erfindung die genannten und andere Nachteile des Standes der Technik vermieden bzw. zumindest teilweise gelindert.

Die Aufgabe wird durch eine Schnittstelle gemäß Anspruch 1 gelöst.

Die Erfindung schlägt ferner ein Verfahren gemäß Anspruch 15 vor.

Ferner schlägt die Erfindung ein Verfahren zum Anbieten und Verkaufen von Informationsinhalten im Internet gemäß Anspruch 26 und ein Zahlungsabwicklungssystem gemäß Anspruch 27 vor.

Die erfindungsgemäßen Verfahren und die erfindungsgemäße Vorrichtung gestatten es Informationsanbietern, sehr einfach und innerhalb kürzester Zeit einen elektronischen Handel im Netz aufzubauen.

Weitere Aspekte der Erfindung betreffen ein Computerprogramm gemäß Anspruch 31 und eine Datenstruktur gemäß Anspruch 30.

Weitere, bevorzugte Ausgestaltungen der Erfindung ergeben sich aus den abhängigen Ansprüchen, der Beschreibung einschließlich der beiliegenden Zeichnungen und weiteren Darstellungen.

Die vorliegende Erfindung stellt eine neue, web-basierte und automatisierte Schnittstelle zwischen einem Informationsanbieter (IA) im Internet und einem Electronic Payment-Provider (EPP) (der deutsche Begriff "Dienstleister für Zahlungen im Internet" wurde hier zu Gunsten des englischsprachigen Begriffs "Electronic Payment-Provider" aufgegeben. Gemeint sind Systeme, wie CyberCash, Milicent und Qpass. Diese Systeme sind zu unterschieden von reinen Online-Transaktionsakzeptanzstellen für Kreditkartenzahlungen, wie z. B. AviCom, da) mit dem Arbeitstitel "SalesMate" bereit. Dabei wird ein "Virtual Domain Hosting-Provider" (VDHP), der die zu verkaufenden Daten des IA hostet, als Kommissionär genutzt.

In Verbindung mit einem EPP ermöglicht SalesMate besonders kleinen und mittleren Unternehmen den risikolosen Einstieg in den Electronic-Commerce, da es äußerst einfach in die Web-Site eines Anbieters von Informationsinhalten im Internet zu integrieren ist. SalesMate versetzt auch kleine IA in die Lage, am eCommerce teilzunehmen. Auch darin liegt eine wesentliche Neuerung. Das Konzept von SalesMate geht über die bisher IA-freundlichste Lösung des "By_Me Buttons^TM" von CyberCash noch einmal weit hinaus und vereinfacht die Integration und Bepreisung von Anbieterinhalten so stark, daß eine "door opener"-Funktion erfüllt wird, die einen neuen Markt erschließt.

SalesMate stellt in Verbindung mit einem EPP und einem VDHP eine Schnittstelle und ein Verfahren dar, die in idealer Weise das Geschäftsfeld des VDHP erweitert. Implementiert ein solcher VDHP das SalesMate-Konzept, ermöglicht er einem großen Teil seiner Kunden, am eCommerce teilzunehmen. Daraus ergeben sich sowohl für den Kunden, als auch für den VDHP neue Einnahmequellen. SalesMate ermöglicht völlig neue Geschäftsfelder, wo vorher kein Geschäft möglich war. Es trägt damit dem Grundgedanken des eCommerce Rechnung.

Durch SalesMate in Verbindung mit EPP werden, neben der äußerst attraktiven und werbewirksamen Erweiterung des Angebots eines VDHP, in hohem Maße Kosten eingespart. Diese Kosten hätte ein IA normalerweise in der direkten Zusammenarbeit mit einer Online-Transaktionsakzeptanzstelle für Zahlungen (OTAZ) zu tragen. Es wird gezeigt, daß die Kostenersparnis für den IA derart erheblich ist, daß sie den Unterschied zwischen Gewinn und Verlust ausmacht.

SalesMate-Charakteristiken:

- SalesMate erlaubt einem IA den Einstieg in den eCommerce in weniger als 1 Stunde.
- SalesMate erfordert keinerlei Eingriffe des IA in seine Web-Pages.
- SalesMate ist völlig transparent. Der IA erhält einen vollständigen Bericht über jede an seiner Web-Site vorgenommene Änderung. Er kann über ein Web-Tool leicht Fehler korrigieren und Änderungen vornehmen.
- SalesMate ist 100% reversibel.
- SalesMate macht aufgrund der vergleichsweise sehr geringen Integrations- und Betriebskosten den experimentellen und risikolosen Einstieg in eCommerce möglich. Es ist deshalb besonders geeignet für "Ersteinsteiger".

Hier erfüllt SalesMate eine "door opener"-Funktion. SalesMate öffnet eCommerce auf der Anbieterseite für den massenhaften Einstieg; dadurch kann die Abwicklung von Geschäftsvorfällen erheblich günstiger angeboten werden, als bei traditionellen OTAZ. SalesMate ist besonders geeignet für private Anbieter, kleine und mittlere Unternehmen, aber nicht auf diese beschränkt. Es ist sehr einfach und ohne Vorkenntnisse zu integrieren, anzupassen und zu verwalten.

Geschäftsprozesse werden in diesem Dokument aus zwei Sichten beschrieben, der "Benutzersicht" und der "IA-Sicht". Die Benutzersicht stellt die Sicht eines Benutzers von EPP's dar, also eines Surfers, der im Cyberspace einkaufen möchte. Sie bietet gegenüber bekannten Konzepten teilweise eine eine verbesserte, klarere Benutzerführung (im Vergleich zu CyberCash) oder ist unverändert (wie z. B. bei Qpass). Die IA-Sicht dagegen beschreibt, wie ein IA seine Inhalte im Web zum Kauf anbieten kann. Sie wird durch SalesMate entscheidend vereinfacht

Ausgangssituation

- Ein "Virtual Domain Hosting-Provider" (VDHP) erhält von seinen Kunden Informationsinhalte, die er dann zum Abruf im Internet bereitstellt. Er aggregiert hierbei auf seinen Speichersystemen die wertvollen Informationsinhalte tausender Kunden.
- Bisher können VDHP-Kunden nur in den seltensten Fällen elektronische Zahlungsmittel akzeptieren, da die technischen Voraussetzungen sowie die Gebühren hierfür zu teuer sind.

Die Idee: SalesMate

- SalesMate macht die Aggregationsfähigkeiten eines VDHP nutzbar und senkt damit die Kosten für die Akzeptanz elektronischer Zahlungsmittel so, daß sie für VDHP-Kunden erschwinglich werden.
- SalesMate ermöglicht, in Zusammenarbeit mit einem Anbieter von Online- Payment, die Bereitstellung, Verwaltung und den Verkauf dieser Informationen im Internet, im Auftrag der VDHP-Kunden.
- Der VDHP-Kunde nutzt das SalesMate-WebTool als alleinige Schnittstelle, um seine Dateien im Internet zum Verkauf anzubieten. SalesMate führt, basierend auf seinen Angaben, alle erforderlichen Konfigurationen in der Web-Site des VDHP-Kunden automatisiert durch.
- Der VDHP wird zum Kommissionär für die Informationsinhalte seiner Kunden und agiert als alleiniger Ansprechpartner gegenüber dem Online- Payment-Anbieter. Dies wird durch SalesMate ermöglicht und unterstützt.

Marktübersicht Entwicklung eCommerce

Weitere offene Fragen:

- Wieviele Internet-Benutzer weltweit und in Deutschland?
- Wieviele Domain-Namen sind weltweit und in Deutschland registriert? (die Anzahl der Web-Seiten übersteigt schon jetzt die Anzahl der Internet-Benutzer erheblich.)
- Wie groß ist der Anteil von Domain-Namen, unter denen eine Web-Site aktiv existiert?
- Wie groß ist der Anteil von "Virtually Hosted" Web-Sites?
- Wer sind die Key-Player im "Virtual Domain-Name Hosting"-Business?
- Welche Umsätze erwirtschaften diese Key-Player?
- Welcher Anteil unter den aktiven Web-Sites bietet eCommerce (also Akzeptanz von irgendwelchen Zahlungsmitteln) an?
- Wie hoch ist der Anteil von Kreditkartenzahlungsakzeptanz?

Überblick

Fazit

Zur Zeit ermöglicht keines der angebotenen Systeme einem Informationsanbieter, sich bei einer OTAZ, ePayment Trust-Center oder anderem Service mit einfachen Mitteln anzumelden, eine Web-Page mit Informationen über seine Angebote auszufüllen und dann, ohne weitere Tätigkeiten, Zahlungen für diese Angebote anzunehmen. Die angebotenen Systeme erfordern immer eine manuelle Anpassung der existierenden Web-Pages, die dann auch getestet werden muß; es entsteht also ein teilweise erheblicher Aufwand. Die Prozesse für die Integration vieler der aufgeführten Systeme sind schlecht dokumentiert und daher eine Fehlerquelle.

SalesMate ändert das drastisch, indem der IA seine bestehende "Free-Of-Charge"- Site mit einfachsten Mitteln in eine eCommerce-Site umwandeln kann. Der IA macht in SalesMate Angaben über die Dateien, die er verkaufen möchte und gibt die Web- Pages an, die die Links darauf enthalten. Mehr ist nicht erforderlich. SalesMate führt die notwendigen Änderungen reversibel direkt auf dem Domainspace des Informationsanbieters durch.

Danach wird vor jedem direkten Link zu einer für einen Benutzer kostenpflichtigen Datei zuerst eine ePH-Seite zwischengeschaltet, die den Benutzer zur Zahlung auffordert. Den gezahlten Betrag erhält nach Abzug der ePH-Gebühren der Informationsanbieter überwiesen.

ePayment Verständnis

Unter ePayment soll im folgenden jedes zur Bezahlung von Waren, Dienstleistungen und Informationen in elektronischen Netzen geeignete Verfahren verstanden werden. Das z. Z. vorherrschende Verfahren ist die Akzeptanz von Kreditkarten, entweder direkt durch die Anbieter oder im Auftrag durch ASP's. Andere Verfahren, wie Bankeinzug und sogenanntes Cybergeld ("Digicash" usw.), spielen eine nur untergeordnete Rolle.

Kategorisierung

ePayment läßt sich aus Sicht kleiner Unternehmen in zwei Kategorien unterteilen. Diese Unterteilung wird durch die Dominanz der Benutzung von Kreditkarten für Online-Payment vorgegeben. Sämtliche ASP von Online-Paymentsystemen (z. B. AviCom.de), im folgenden wie bereits erklärt "OTAZ" genannt, bauen ihr Angebot der Akzeptanz von Kreditkarten im Auftrag eines Anbieters auf dem folgenden Preismodell auf:

1. Clearing Setup, einmalige Einrichtungskosten für die Bereitstellung der Dienstleistung zur Autorisierung von Online-Transaktionen per Kreditkarte im Internet (Größenordnung 500-1500 DM, Beispiel AviCom: 698,00 DM).
2. Clearing Account, monatliche Kosten für die Bereitstellung der Dienstleistung (Größenordnung 200-500 DM, Beispiel AviCom: 198,00 DM).
3. Clearing Transaction, Kosten für die Durchführung je Online-Transaktion (Größenordnung 0,30-1,00 DM, Beispiel AviCom: 0,30-0,80 DM, abhängig vom Transaktionsvolumen), zuzüglich zu den (je nach Kreditkarte unterschiedlichen) Prozenten für die Kreditkartennutzung in der Höhe von ca. 4% des Kaufpreises.

Punkt 3 in diesem allgemeinen Preismodell macht es augenscheinlich, daß die Annahme von Zahlungen in der Größenordnung von 1 DM für einen Anbieter unattraktiv ist, da er diese nahezu vollständig an die OTAZ abführen muß. Weiterhin ist sowohl die Integration der am Markt angebotenen Online-Transaktionssysteme mit größeren Kosten verbunden, als auch die hohe, monatliche Grundgebühr (2) für kleinere Unternehmen, gerade in der Anfangsphase, äußerst problematisch.

Basierend auf diesen Überlegungen läßt sich eine Kategorisierung von ePaymentsystemen vornehmen:

a) ePaymentsysteme, die für Angebote mit Preisen um 40,00 DM und darüber nutzbar sind (nahezu alle am Markt angebotenen Systeme).
b) ePaymentsysteme, die bereits für Angebote in der Größenordnung von 0,01 bis 40,00 DM verwendbar sind (z. B. QPass oder Net900). Diese Systeme werden auch als Micropaymentsysteme bezeichnet. Der Focus liegt hier bei Zahlungen im Gebiet um 5,00 DM.

Die ePaymentsysteme der Kategorie ii) müssen natürlich ebenfalls eine Gebühr für die Abwicklung einer Kreditkartentransaktion in Kauf nehmen. Darüber hinaus können die Systeme der Kategorie ii) aber hoffen, mehrere Zahlungen von einem Benutzer über einen gewissen Zeitraum zu akkumulieren, bevor diese zu einer Kreditkartentransaktion zusammengefaßt werden. Weiterhin kann durch die Öffnung solcher Systeme für den Massemarkt die einzelne Online- Transaktion erheblich günstiger angeboten werden. Dadurch vermindern sich die Kosten für eine einzelne Online-Transaktion erheblich. Weiterhin kann durch einen "Zwischenhändler", der die Zahlungen für mehrere Anbieter gebündelt annimmt, die Grundgebühr für alle diese Anbieter entfallen.

Detaillierte Beschreibung der Erfindung

Der SalesMate-EPP wird im folgenden anhand einer fiktiven Firma mit Namen "ePH (Electronic Payment-House)" beschrieben. ePH stellt einen Electronic Payment- Provider, wie Qpass, Millicent oder CyberCash dar, der den Informationsanbietern SalesMate als Schnittstelle zur Verfügung stellt. ePH agiert als "Zwischenhändler" zwischen einem Informationsanbieter (IA) und einer Online-Transaktions- Akzeptanzstelle für Zahlungen (OTAZ), wie z. B. AviCom.de. ePH soll nicht die OTAZ ersetzen.

ePH kauft Leistungen von der OTAZ und verkauft diese an die IA. Durch einen akkumulierenden Effekt entsteht eine erhebliche Kostenersparnis, die teilweise an die IA weitergegeben wird. Die nur teilweise Weitergabe der Kostenersparnis macht einen Teil des Gewinns von ePH aus.

Weiterhin wird durch die Kombination der "door opener für eCommerce"-Funktion von ePH eine erhebliche Attraktivität auf die IA's ausgeübt. Wenn ePH als Erweiterung des Angebotes eines VDHP angeboten wird, ist sowohl die Integration äußerst einfach als auch die massenhafte "Anhebung" von Kunden aus dem low-budget- Bereich oder niedrige Preiskategorien (Private Web-Sites oder B2C) in den erweiterten Bereich (Kommerzielle Web-Sites oder B2B) und somit höhere Preiskategorien überführt werden. Darüber hinaus werden neue Kunden angezogen, die direkt in erweiterte Angebote des VDHP einsteigen. Hierdurch wird ein weiterer Gewinn für den VDHP oder den ePH ermöglicht.

Business Case Aus ePH-Sicht

- ePH akkumuliert die Angebote tausender (!) IA (ePH-Kunden) und agiert als "Super-Anbieter" gegenüber den OTAZ. Dadurch entfallen die Einrichtungs- und monatlichen Grundgebühren aller unter dem ePH-Dach zusammengefaßten IA.
- ePH führt als "Super-Anbieter" eine sehr hohe Anzahl von Online-Transaktionen durch. Dadurch sinken die Gebühren für eine einzelne Online-Transaktion drastisch (z. B. von 0,80 DM auf 0,30 DM), da die OTAZ Mengenrabatt anbieten.
- ePH kann n Zahlungen von Benutzern über einen gewissen Zeitraum cachen und am Monatsende mit der OTAZ abrechnen. Dadurch fallen nicht n Online- Transaktionsgebühren, sondern nur eine Online-Transaktionsgebühr an.
- ePH erhöht die Attraktivität eines VDHP (eCommerce ASP) in erheblichem Maße. Neue Kunden werden für anspruchsvolle Angebote gewonnen, existierende Kunden werden in diese Angebote überführt.

(Vereinfachende Annahme; im weiteren Verlauf der Entwicklung von SalesMate-EPP wäre das Ersetzen von OTAZ durchaus denkbar und sogar wünschenwert.)

Aus IA-Sicht

- Da ePH seine Vorteile teilweise an die IA's weitergeben kann, wird für die IA der Einstieg in eCommerce sehr günstig (bis zu 75% verglichen mit den Bedingungen "traditioneller" OTAZ) ermöglicht.
- Für die meisten IA ist in der direkten Zusammenarbeit mit den OTAZ der Einstieg in eCommerce unattraktiv, da die Kosten teilweise über 50% (!) der Einnahmen betragen. ePH ändert das drastisch und ermöglicht so den eCommerce-Einstieg auf breiter Basis ("door opener-Funktion"). Mit den Gebühren für Einrichtung und monatliche Nutzung sinkt gleichzeitig das Risiko für einen IA, den Einstieg in den eCommerce erstmalig zu wagen.
- Mit dem SalesMate-Werkzeug (WebTool) können IA's auf einfachste Art und Weise beliebige Informationsinhalte zum Verkauf im Internet anbieten. Integration von Verkauf von Informationen" und "Zahlungsakzeptanz" wird damit für die breite Masse der IA möglich.

Informationsinhalte aus Sicht eines IA sind z. B. (Auswahl):

- Shareware,
- Bildschirmschoner,
- Musikdateien,
- Videodateien,
- Bilddateien,
- Literaturdateien,
- Technische Hilfestellungen,
- Adressen von Kontaktpartnern.

Modellrechnung

Der Business-Case soll anhand einer Modellrechnung mit plausiblen, eher konservativen Annahmen im Vergleich zwischen einem traditionellen Dienstleister und einem ePH veranschaulicht werden.

Allgemeine Annahmen

- Das ePH-System findet eine Marktakzeptanz. Diese Annahme ist besonders dann gerechtfertigt, wenn das ePH-System von einem Dienstleister im Bereich Virtual Domain-Hosting (VDHP) als Erweiterung des existierenden Angebotes genutzt wird. Abhängig von der Kundenzahl des VDHP wird das ePH-System schnell einen hohen Verbreitungsgrad finden, da es einem großen Anteil der Kunden den Ersteinstieg in den eCommerce ermöglicht.
- Benutzer, die ePH zur Zahlung bei einem IA verwenden, kehren wieder zu diesem Anbieter oder zu anderen Anbietern, die ebenfalls ePH verwenden, zurück. Dadurch wird (siehe vorhergehendes Kapitel) die Gebühr für eine einzelne Online-Transaktion verringert.
- ePH verringert sowohl die Einrichtungskosten als auch die Betriebs-, also Anpassungs- bzw. Änderungskosten für einen Anbieter erheblich, da ePH die gegenüber dem OTAZ als nur ein Kunde auftritt, seinerseits aber die Grundkosten für tausende IA überflüssig macht (in der Realität wird ePH diese Kosten aus Gewinngründen "nur" drastisch reduzieren wollen).
- Da sowohl auf ePH- als auch auf IA-Seite nur wenige manuelle Tätigkeiten erforderlich sind (SalesMate WebTool), wird die Integration und Anpassung neuer Angebote stark vereinfacht. Einem IA kann es zugemutet werden, sein Angebot selbst über SalesMate zu verwalten und sich an die SalesMate- Technologie gegebenfalls anzupassen. In den weitaus meisten Fällen wird diese Anpassung nicht notwendig oder nur minimal sein.

Annahmen für die Modellrechnung

- PH wird von einem Virtual Domain-Hoster mit 100.000 Kunden angeboten.
- 1% der Kunden (Anbieter von Informationen, Dienstleistungen oder Produkten) nutzen das ePH-Angebot.
- Ein Anbieter setzt durchschnittlich 1000 DM pro Monat um.
- Der durchschnittliche Umsatz pro Geschäftsvorfall wird mit 5 DM angenommen und ist damit typisch für Micropayment; daraus ergeben sich 200 Geschäftsvorfälle pro Monat.
- 10% der Benutzer sollen während eines Monats ePH von diesem oder einem anderen Anbieter aus wiederholt benutzen.
- Der Aufwand für die Einrichtung und Anpassung von ePH auf Anbieterseite beträgt nur 10% des Aufwandes beim Einsatz einer traditionellen Akzeptanzstelle (für die Vergleichsrechnung zu den Gebühren eines traditionellen Dienstleistungsanbieters der Akzeptanz von Online-Transaktionen von Kreditkarten im Internet wird AviCom.de beispielhaft angenommen).
- PH ist bei den monatlichen Grundgebühren als auch bei den Gebühren für eine einzelne Oline-Transaktion um 75% günstiger als traditionelle OTAZ.

Auswertung

Basierend auf den vorhergehenden Annahmen wird eine Modellrechnung angestellt.

Die Ergebnisse werden im folgenden beschrieben:

Traditionelle ePCH-Lösung

Die monatlichen Kosten für einen Anbieter betragen 522,42 DM, gegenüber 1000 DM Umsatz. Das sind 52%. Die OTAZ würde zwar theoretisch an 1000 solcher Anbieter 522.420,00 DM pro Monat verdienen; das scheitert aber daran, daß für den IA der Einsatz einer solchen Lösung in den allermeisten Fällen völlig unattraktiv ist. Es kommt kein Geschäft zustande.

Neue ePH-Lösung

Die monatlichen Kosten betragen aus Anbietersicht 125 DM, das ist eine Kostensenkung um 76%. Bei 1000 DM Umsatz sind diese Kosten mit 12,5% vergleichsweise äußerst günstig und ermöglichen somit den Einstieg in den eCommerce mit einem vertretbaren Risiko. Weiterhin betragen die Einrichtungsgebühren (Anfangsinvestition) nur 10% der sonst üblichen Kosten (Annahme).

ePH verdient an einem einzelnen IA in der Modellrechnung 38 DM pro Monat. Das ist vor allem vom Umfang der an den Anbieter weitergegebenen Verringerung der Gebühren für eine einzelne Online-Transaktion abhängig. Der Spielraum für einen Geiwnn des ePH ist aber weitaus größer. Soll beispielsweise nur die Einrichtungs- und Grundgebühr um 75% verringert werden, erhöht sich der Verdienst pro Anbieter auf 158 DM (!) pro Monat. Auch in diesem Fall sinken die Kosten für den IA noch um 53% gegenüber der traditionellen OTAZ-Direktanbindung.

Zur Veranschaulichung soll die Rechnung für den größten deutschen Domainname- Hoster, Strato AG, aufgemacht werden. Strato, mit derzeit 800.000 Kunden, könnte durch direkte Ansprache nach gemäß den Annahmen 1-2% seiner Kunden für eine ePH Lösung gewinnen. Bei monatlichen Kosten für einen Anbieter gemäß der Modellrechnung von 158 DM pro Monat ergäben sich jährliche Einnahmen von 22,8 Mio. DM für Strato. Damit wären Projektkosten in der Größenordnung von unter 20 Mio. DM (Annahme) bereits im ersten Jahr vollständig amortisiert. Darüber hinaus würde das ePH-Angebot sowohl das Kundenwachstum als auch den angestrebten Börsenwert der Strato AG positiv beeinflussen.

Beschreibung der Geschäftsprozesse Benutzersicht

1. Ein Benutzer gelangt beim Surfen im Internet zur Seite eines IA, der ePH zur Zahlung nutzt.
2. Der Benutzer entscheidet, etwas von diesem IA zu kaufen.
3. Dem Benutzer wird mitgeteilt, daß er vorher bereits bei ePH angemeldet sein muß, um bei diesem IA bezahlen zu können.
4. Ist der Benutzer bereits bei ePH angemeldet, so zahlt er einfach durch Eingabe seines Benutzernamens und Paßwortes (und gegebenenfalls durch Auswahl einer Zahlungsmethode, falls der Benutzer mehrere Zahlungsmethoden beim ePH abgespeichert hat).
5. Ist der Benutzer noch nicht angemeldet, so wird er zu einer ePH-Seite weitergeleitet, wo er die Daten zu einer bestimmten Zahlungsmethode (Bankeinzug, verschiedene Kreditkarten) eingeben kann. Nach Verifizierung seiner Daten erhält der Benutzer einen Benutzernamen und ein Paßwort zur Benutzung von ePH. Der Benutzer kann nun bei ePH die vom IA gewünschte Information/Datei bezahlen; dabei wird die im SalesMate-WebTool hinterlegte Spezifikation (siehe IA-Sicht) für den Preis verwendet.
6. Dem Benutzer wird ein temporärer Link zur Verfügung gestellt, der auf die gewünschte Information/Datei verweist. Dieser Link wird speziell für den zahlenden Benutzer erzeugt und nur diesem mitgeteilt (daß das allein den Benutzer in keiner Weise daran hindert, diesen Link oder die darauf erhaltene Information an Dritte weiterzugeben, ist bekannt). Dieser Link ist gemäß der Spezifikation des IA im SalesMate-WebTool nur für eine bestimmte Zeit erreichbar. Dadurch wird ein gewisser Schutz vor Weitergabe an Dritte erreicht. (Zu erweiterten Schutzmöglichkeiten siehe Abschnitt Sicherheit".)

IA-Sicht

1. Anmelden des IA beim ePH als Kunde über das SalesMate-WebTool. Der IA muß sich mit den Geschäftsbedingungen des ePH einverstanden erklären, muß den bestimmten Bedingungen bei der Eröffnung eines IA-Kontos zustimmen, und es erfolgt eine Zuordnung von IA-Benutzername und Paßwort.
2. Der IA muß weiterhin festlegen, welche Informationen er im Netz anbieten bzw. verkaufen möchte.

Funktionale Architektur

Die Hauptkomponente der funktionalen Architektur ist das SalesMate-WebTool. SalesMate wurde entwickelt, um einem IA den Einstieg in den eCommerce so einfach wie möglich zu machen.

IA-Sicht SalesMate-WebTool IA-Anmeldung

Ein IA, der über ePH Zahlungen empfangen möchte, muß sich zunächst bei ePH anmelden. Für den IA wird ein Konto angelegt; er erhält einen IA-Namen (Benutzernamen) und ein Paßwort. Die Stammdaten werden eingegeben.

Anbieten von Informationen

ePH schaltet sich zwischen eine Angebotsseite eines IA und die tatsächlich angebotene Datei. Dazu führt ePH die folgenden Schritte durch:

1. Anlegen eines oder mehrerer, geschützter Verzeichnisse, die Dateien, welche verkauft werden sollen, enthalten.
2. Der IA erteilt ePH Schreibzugriff auf alle die Verzeichnisse, in denen Dateien zum Verkauf liegen; weiterhin erteilt er ebenfalls Schreibzugriff auf die Verzeichnisse mit HTML-Seiten, in denen die bisher nicht kostenpflichtigen Links auf die Dateien zum Verkauf liegen.
3. ePH kopiert diese Dateien in ein ePH-internes, geschütztes Verzeichnis und löscht sie beim IA im ursprünglichen Verzeichnis. (Der IA wird natürlich aufgefordert, Sicherungskopien anzulegen, kann die Dateien aber auch von ePH rückbeziehen.)
4. Der IA trägt die folgenden Angaben in SalesMate-WebTool ein:
- - Verzeichnis, in dem die Datei ursprünglich war, also wohin alle Links bisher zeigten.
- - Name der Datei.
- - Verzeichnis, wo die aufrufende HTML-Seite steht.
- - Name der HTML-Seite.
- - Beschreibung der Datei, weitere Informationen (HTML ohne Links) zur Integration in den SalesMate-Dummy.
- - Preis.
- - Zeit, die der Link verfügbar sein soll.
5. ePH generiert nun sogenannte SalesMate-Dummies, die den Platz der ursprünglichen Dateien einnehmen (exakt gleicher Dateiname, aber mit der Endung .htm statt .gif oder .jpg oder .avi oder .doc oder .mp3 usw.), basierend auf den Angaben des Informationsanbieters.
6. ePH ändert ebenfalls die aufrufenden Dateien ab, d. h. alle Endungen, die nicht ".htm" sind, werden zu ".htm".
7. Der IA erhält einen Bericht, detailliert, über alle vorgenommenen Änderungen.

Der IA kann nun die Dateien, die er zum Kauf anbieten möchte, in einer WebMaske des SatesMate-WebTools abspeichern. Er braucht dazu in den weitaus meisten Fällen nichts an seiner WebSite zu ändern. Der IA muß dem ePH-System lediglich mitteilen:

- In welchem Verzeichnis die Dateien zu finden sind und erteilt ePH Zugriff (Übermittlung von Benutzername für das Verzeichnis und Paßwort über eine gesicherte Verbindung) auf dieses Verzeichnis.
- Die Namen der Dateien, die verkauft werden sollen.
- Wie lange ein Link, den ePH bei Bedarf temporär zu einer solchen Datei erzeugt, existieren darf.
- Zu welchem Preis der Benutzer die Datei abrufen darf.

Das ePH-System antwortet, indem es zuerst die Abrufbarkeit der Dateien überprüft, gemäß den vom IA gemachten Angaben. Kann eine Datei nicht kopiert werden, wird der IA durch eine Fehlermeldung darauf aufmerksam gemacht. Ansonsten wird die Datei durch das ePH-System in ein internes Sammelverzeichnis kopiert. Dies ist besonders einfach, wenn ePH und VDHP eine Einheit bilden (beispielsweise im gleichen Rechnercluster), aber auch dann möglich, wenn die Dateien weit entfernt auf einem externen System liegen. Hierbei muß beachtet werden, daß ein Kopieren und Umbenennen von Dateien, also "on demand", nur bei einer wirklichen High- Speed-Datenanbindung in Frage kommt. Ansonsten wären die Wartezeiten für den Benutzer nicht annehmbar. In jedem Fall sollte das Kopieren von Dateien zwischen dem privaten Verzeichnis des IA und dem ePH-System über eine gesicherte Verbindung erfolgen. Bei externen Verzeichnissen sollte das ePH von dem IA eine Gebühr für den erforderlichen Dateitransfer erheben. Updates sollten dem ePH System durch den IA mitgeteilt werden.

Für umfangreichere Dateilisten wird das Uploaden (SalesMate-Uploader) von Excel- oder einfach strukturierten Textdateien in das ePH-System, parallel zur Nutzung des SalesMate-WebTools, ermöglicht.

Verkaufsstatistiken

Sind alle Angaben korrekt, kann der IA die Verkaufsstatistiken seiner Dateien ansehen. Weitere Statistiken, die den IA über den Geschäftsverlauf informieren, können eingerichtet werden.

Benutzersicht

Nahezu analog zu QPass.com

Systemsicht

- Weitergabe von Billing-Events (Anbieterschlüssel, Produktschlüssel, Preis, Benutzer) vom Appl. S. an Infranet ("System Product").
- Integration von SalesMate mit dem Infranet Pricing-Tool.
- Einrichten neuer Benutzer durch "Account_Create" in Infranet (Web-Page über Appl. Server) (bzw.
- Update), allgemeine Benutzerverwaltung.
- Rating und Billing eines Benutzers in einem Abrechnungszeitraum.

Technische Architektur

Die Aufgabe der Technischen Architektur besteht in der Unterstützung der funktionalen Aufgaben.

Web-Server

Standard-Web-Server (z. B. Apache oder Netscape-Enterprise) mit SSL- Verschlüsselung (128-bit Schlüssellänge wünschenswert) zum Aufbau gesicherter Verbindungen zu Kunden, die ihre Zahlungsinformationen eingeben möchten.

Application-Server

Plattform zur Abwicklung der für den Benutzer sichtbaren Business-Logic. Die Plattform sollte der Enterprise Java Beans-Spezification von SUN genügen (z. B. BEA WebLogic, iPlanet Application-Server).

Billing-System

PORTAL-Infranet.

Schnittstellen zu den Abrechnungssystemen

- SAP. . .
- XML. . .

Sicherheitsaspekten kommt bei Zahlungssystemen naturgemäß ein sehr hoher Stellenwert zu. Die folgenden Bereiche und Rechte sind zu schützen:

- Das Recht des Kunden auf Schutz vor Mißbrauch seiner, dem ePH anvertrauten Kreditkarten und anderer Zahlungsinformationen.
- Das Bedürfnis des IA, daß seine Dateien ausschließlich dem zahlenden Benutzer zur Verfügung gestellt werden und nicht (zumindest nicht in breitem Umfang) für Dritte verfügbar werden.
- Das Bedürfnis des ePH, Mißbrauch und Verluste zu minimieren, da diese den Gewinn und das Bild der Firma in der Öffentlichkeit negativ beeinflussen würden.

Authentifizierung

Benutzername und Paßwort versus Certificate.
Password-Policy (Verhinderung des "Hackens" des Accounts durch Brute Force und durch einfaches Ausspähen).
Anti-Dictionary-Attack-Mechanism (Verhinderung des "Hackens" des Accounts durch Brute Force).
Ticketing-Mechanism für einen angemeldeten Benutzer (Verhinderung des Mißbrauchs einer einmal erfolgten Authentifizierung durch andere Personen).

Firewall

Sender-Empfänger-Kontrolle; dadurch kann festgestellt werden, ob mehr als eine IP- Adresse die Information abruft.

Anzahl der übertragenen Bytes, um festzustellen, wenn die Datei mehr als einmal über einen bestimmten PORT abgerufen wird (sicherheitstechnische Erweiterung).

Autorisierung

Wasserzeichen (!) gegen Verfolgung der unberechtigten Weitergabe an Dritte.

Kreditkartenmißbrauch

In Zusammenarbeit mit dem OTAZ muß die Sperrung bestimmter Benutzer und bestimmter IA möglich sein.

Rechtliche Aspekte Allgemeine Geschäftsbedingungen

Recht zur Kündigung eines IA ohne Angabe von Gründen.

Datenschutz Benutzer-Management

Ausschließen von Benutzern von der Benutzung von ePH bei Mißbrauch von Zahlungsmitteln.

Claims

1. Schnittstelle zwischen zumindest einem Informationsanbieter und zumindest einem Diensteanbieter zum kontrollierten Bereitstellen, Verwalten, Speichern, Übertragen und/oder Verkaufen einer vom Informationsanbieter angebotenen Information im Internet oder einem anderen Netz, aufweisend:
ein Schnittstellenmittel, das zu einem ersten Zeitpunkt den Informationsanbieter beim Diensteanbieter einrichtet, und
ein Kontrollmittel zum kontrollierten Bereitstellen, Verwalten, Speichern, Übertragen und/oder Verkaufen der Information automatisch generiert.

2. Schnittstelle nach Anspruch 1, wobei das Kontrollmittel zum ersten Zeitpunkt weiterhin ein Informationsangebot generiert, und das Informationsangebot beim Informationsanbieter an die Position der Information tritt.

3. Schnittstelle nach Anspruch 2, wobei das Kontrollmittel weiterhin aufweist:
ein Authentifizierungsmittel zum Authentifizieren eines Kunden, der zu einem zweiten Zeitpunkt auf das Informationsangebot zugreift,
eine erste Verbindung (link) von dem Informationsangebot zum Authentifizierungsmittel,
eine zweite Verbindung (link) vom Authentifizierungsmittel zu der Information.

4. Schnittstelle nach Anspruch 3, wobei das Kontrollmittel weiterhin aufweist:
ein Freigabemittel zum Freigeben der Information, wenn die Authentifizierung erfolgreich war, wobei das Freigabemittel die zweite Verbindung steuert, indem bei Freigabe die zweite Verbindung verfügbar und damit die Information abrufbar ist, und bei Nichtfreigabe die zweite Verbindung gesperrt ist.

5. Schnittstelle nach Anspruch 4, wobei das Kontrollmittel weiterhin aufweist:
eine dritte Verbindung (link) vom Authentifizierungsmittel zum Diensteanbieter, wobei das Authentifizierungsmittel über die dritte Verbindung beim Diensteanbieter eine Authentifizierung des Kunden erfragt und der Diensteanbieter das Freigabemittel über das Ergebnis der Authentifizierung informiert.

6. Schnittstelle nach einem der vorhergehenden Ansprüche, zwischen einer Vielzahl von Informationsanbietern und einem Diensteanbieter, wobei die Informationen der Informationsanbieter von einem Bereitstellungsanbieter (Hosting Provider) gespeichert und vom Bereitstellungsanbieter im Netz bereitgestellt werden, und der Bereitstellungsanbieter in der Schnittstelle zwischen den Informationsanbietern und dem Diensteanbieter angeordnet ist, wobei der Bereitstellungsanbieter den Datenazustausch zum kontrollierten Bereitstellen, Verwalten, Speichern, Übertragen und/oder Verkaufen der Informationen zwischen den Informationsanbietern und dem Diensteanbieter steuert und kanalisiert.

7. Schnittstelle nach Anspruch 6, weiterhin aufweisend:
eine vierte Verbindung vom Bereitstellungsanbieter und/oder Diensteanbieter zu einer Transktionsakzeptanzstelle und
ein Speichermittel zum Speichern einer Vielzahl von Transaktionen, die über die Schnittstelle zu übertragen sind.

8. Schnittstelle nach Anspruch 7, weiterhin aufweisend:
ein Steuermittel zum Steuern des Datenaustausch über die Schnittstelle.

9. Schnittstelle nach Anspruch 8, wobei das Steuermittel ein Zeitgeber und/oder ein Füllstandsanzeiger für das Speichermittel aufweist, wobei der Zeitgeber zu einem definierten Zeitpunkt bzw. die Füllstandsanzeige bei einem kritischen Füllstand des Speichermittels dem Steuermittel signalisiert, die im Speichermittel gespeicherten Transaktionen zur Transaktionsakzeptanzstelle zu übertragen.

10. Schnittstelle nach einem der vorhergehenden Ansprüche, wobei der Diensteanbieter ein Diensteanbieter für Zahlungen im Internet (Electronic Payment-Provider) ist.

11. Schnittstelle nach einem der vorhergehenden Ansprüche, wobei die Transaktionsakzeptanzstelle eine Online-Transaktionsakzeptanzstelle für Zahlungen ist.

12. Schnittstelle nach einem der vorhergehenden Ansprüche, wobei der Informationsanbieter seine Informationen auf einer Internet-Seite (Web-Site) anbietet und das Kontrollmittel zum ersten Zeitpunkt in der Web-Site des Informationsanbieters Konfigurationen automatisch durchführt.

13. Schnittstelle nach einem der vorhergehenden Ansprüche, wobei die Authentifizierung des Kunden durch eine elektronische Zahlung erfolgt.

14. Schnittstelle nach einem der vorhergehenden Ansprüche, wobei der Diensteanbieter die Transaktionsakzeptanzstelle umfaßt.

15. Verfahren zum kontrollierten Bereitstellen, Verwalten, Speichern, Übertragen und/oder Verkaufen zumindest einer von zumindest einem Informationsanbieter angebotenen Information im Internet oder einem anderen Netz, umfassend die Schritte zu einem ersten Zeitpunkt:
Speicherung der Koordinaten des Informationsanbieters bei einem Diensteanbieter,
automatische Generierung eines Kontrollmittels zum kontrollierten Bereitstellen, Verwalten, Speichern, Übertragen und/oder Verkaufen der Information.

16. Verfahren nach Anspruch 15, wobei die Generierung des Kontrollmittels weiterhin folgende Schritte umfaßt:
Generierung eines Informationsangebotes, enthaltend wesentliche Angaben zu der Information,
Austauschen der Information mit dem Informationsangebot und
Generierung einer steuerbaren Verbindung (link) vom Informationsangebot zu der Information.

17. Verfahren nach einem der Ansprüche 15 oder 16, das zu einem zweiten Zeitpunkt, zu dem ein Kunde auf das Informationsangebot zugreift, folgende weitere Schritte umfaßt:
Authentifizierung des Kunden,
Freigeben der steuerbaren Verbindung, wenn die Authentifizierung erfolgreich war, und
Darstellen der Information, auf die die steuerbare Verbindung verweist.

18. Verfahren nach Anspruch 17, wobei die Authentifizierung weiterhin folgende Schritte umfaßt:
Bereitstellung eines Eingabemittels und
Überprüfung einer vom Kunden in das Eingabemittel eingegebenen Authentifizierungsdaten.

19. Verfahren nach Anspruch 18, wobei die Authentifizierung von dem Diensteanbieter durchgeführt wird, umfassend die Schritte:
Senden der vom Kunden eingegebenen Authentifizierungsdaten an den Diensteanbieter,
Vergleichen der Authentifizierungsdaten mit vom Kunden beim Diensteanbieter hinterlegten Kundendaten und
Senden einer Freigabe an die stuerbaren Verbindung bei Übereinstimmung der Authentifizierungsdaten mit den Kundendaten.

20. Verfahren nach einem der Ansprüche 15 bis 19, wobei die Informationen einer Vielzahl von Informationsanbietern von einem Bereitstellungsanbieter (Hosting Provider) gespeichert und von Bereitstellungsanbieter im Netz bereitgestellt werden.

21. Verfahren nach Anspruch 20, wobei der Bereitstellungsanbieter die Verwaltung, Steuerung und Kanalisierung des Datenaustausches zwischen Informationsanbietern und Diensteanbieter übernimmt.

22. Verfahren nach einem der Ansprüche 17 bis 21, wobei die Authentifizierung des Kunden durch eine elektronische Zahlungstransaktion erfolgt.

23. Verfahren nach einem der Ansprüche 20 bis 22, wobei die Zahlungstransaktionsdaten vom Bereitstellungsanbieter und/oder vom Diensteanbieter gespeichert werden und in einstellbaren Intervallen zu einer Transaktionsakzeptanzstelle gesendet werden.

24. Verfahren nach Anspruch 23, wobei der Diensteanbieter ein Diensteanbieter für Zahlungen im Internet (Electronic Payment-Provider) und die Transaktionsstelle eine Online-Transaktionsakzeptanzstelle für Zahlungen ist.

25. Verfahren nach einem der Ansprüche 20 bis 24, wobei der Informationsanbieter seine Informationen auf einer Internet-Seite (Web-Site) anbietet und das Kontrollmittel zum ersten Zeitpunkt in der Web-Site des Informationsanbieters Konfigurationen automatisch durchführt.

26. Verfahren zum Anbieten und Verkaufen von Informationsinhalten im Internet, die von zumindest einem Informationsanbieter bereitgestellt werden, bei dem ein Bereitstellungsanbieter die Informationsinhalte speichert und im Internet darstellt und gegenüber einem Zahlungsdiensteanbieter die Bezahlung im Auftrag der Informationsanbieter abwickelt.

27. Zahlungsabwicklungssystem im Internet, aufweisend:
einen Bereitstellungsanbieter (Virtual Domain Hosting-Provider) und
Zahlungsdiensteanbieter (Payment House).

28. Zahlungsabwicklungssystem nach Anspruch 26, wobei der Bereitstellungsanbieter weiterhin aufweist:
einen Bereitstellungsserver (Virtual Domain Hosting-Server) zum Speichern und Darstellen von im Internet von zumindest einem Informationsanbieter zu verkaufenden Informationsinhalten und
ein Rechnungssystem (Invoicing System) zum Abrechnen von Zahlungen zum Kauf der Informationsinhalte mit dem Zahlungsdienstanbieter.

29. Zahlungsabwicklungssystem nach einem der Ansprüche 27 oder 28, wobei der Zahlungsdiensteanbieter weiterhin aufweist:
einen Internet-Server zum Anschluß des Zahlungsdiensteanbieters an das Internet,
einen Anwendungsserver zum Anbieten und Freigeben der Informationsinhalte und
ein Zahlungssystem zum Abwickeln der Zahlungen mit dem Rechnungssystem des Bereitstellungsanbieters und einer Online-Transaktionsakzeptanzstelle.

30. Datenstruktur, speicherbar auf einem computerlesbaren Datenträger, auf die mittels einer Datenverarbeitungsanlage zugegriffen werden kann, wobei die Datenstruktur auf der Datenverarbeitungsanlage die Schnittstelle nach einem der Ansprüche 1 bis 14 und/oder das Zahlungsabwicklungssystem nach einem der Ansprüche 27 bis 29 implementiert.

31. Computerprogramm, speicherbar auf einem computerlesbaren Datenträger, das, wenn es auf einer Datenverarbeitungsanlage ausgeführt wird, die Verfahren nach einem der Ansprüche 15 bis 26 verwirklicht.