-
URHEBERRECHTSAUTORISIERUNG
-
Ein
Teil der Offenbarung des vorliegenden Patentdokuments enthält Material,
das urheberrechtlich geschützt
ist. Der Urheberrechtsbesitzer hat keine Einwände gegen jedwede Faksimilevervielfältigung
des Patentdokumentes oder der Patentoffenbarung, wie sie in den
Akten oder Aufzeichnungen des Patent- und Markenzeichenamtes erscheint,
behält
sich jedoch ansonsten alle Urheberrechte vor.
-
BEREICH DER
ERFINDUNG
-
Die
vorliegende Erfindung betrifft allgemein Systeme und Verfahren für elektronische
Kommunikation. Die vorliegende Erfindung betrifft spezieller Systeme
und Verfahren zum Verwalten von Kommunikationen zwischen Computersystemen,
die an einer Transaktion beteiligt sind.
-
HINTERGRUND
DER ERFINDUNG
-
Kürzliche
Fortschritte in der Computer- und Vernetzungstechnik haben eine
Reihe verschiedener neuer Typen von kommerziellen Transaktionen
zwischen physisch voneinander entfernten Parteien ermöglicht.
So betreiben beispielsweise viele Verkäufer Internet-Webseiten, auf
denen Verbraucher die Waren des Verkäufers mit einer Kreditkarte
oder einer anderen Zahlungsweise kaufen können. Die Waren werden nach
dem Eingang der Zahlung an den Verbraucher versandt. Eine Klasse
von Transaktionen, die immer mehr an Bedeutung zunimmt, beinhaltet
den Verkauf von digitalen Waren, wie z.B. von digital aufgezeichneten
Liedern, Kinofilmen, Bildern, Büchern,
Berichten und dergleichen. Aufgrund der Beschaffenheit von digitalen
Waren können
diese relativ leicht über
ein Computernetz transportiert und/oder auf leicht erhältlichen
und kostenarmen Speichermedien wie Disketten, CDs und dergleichen
gespeichert werden. So können
digitale Waren involvierende Transaktionen praktisch sofort erfolgen,
da digitale Waren vom Computersystem des Verkäufers in kurzer Zeit über das
Netzwerk zum Computersystem des Käufers übertragen werden können.
-
In
anderen Transaktionstypen könnte
sich eine Kopie einer digitalen Arbeit zu dem Zeitpunkt, an dem sie
der Verbraucher kaufen möchte,
bereits auf seinem Computersystem befinden. So könnte beispielsweise der Verbraucher
eine Kopie von einem Freund erhalten, vom Internet heruntergeladen
oder sich mit anderen Mitteln beschafft haben. Der Inhalt kann verschlüsselt oder
auf andere Weise verpackt sein, so dass ohne Zahlung nicht darauf
zugegriffen werden kann, und der Verbraucher muss daher möglicherweise
mit dem Inhaltseigentümer
oder dem Vertreter des Besitzers, um Zugang zu erhalten, Kontakt
aufnehmen. So könnte
beispielsweise der Verbraucher möglicherweise
eine Kreditkartenzahlung als Gegenleistung für einen kryptografischen Key
oder ein anderes Mittel zum Auspacken des Inhalts an den Inhaltseigentümer leisten.
-
Es
wächst
auch der Bedarf an immer flexibleren Geschäftsarrangements. So möchte es
z.B. ein Inhaltsverkäufer
möglicherweise
Verbrauchern gestatten, Inhalt auf einer Pay-per-Use-Basis zu kaufen, und/oder
er möchte
es möglicherweise
Verbrauchern gestatten, für
Inhalt auf eine nicht traditionelle Weise zu zahlen – beispielsweise
indem sie es dem Verkäufer
gestatten, Informationen über
die Inhaltsgebrauchsgewohnheiten des Verbrauchers zu sammeln. Um
Arrangements wie diese zu erleichtern, kann ein Inhaltsverkäufer dem
Verbraucher ein Sonderrechtmanagement-Anwendungsprogramm zur Verfügung stellen,
das auf dem Computersystem des Verbrauchers läuft und die Vertragsbedingungen
des Verbrauchers mit dem Verkäufer
durchsetzt.
-
Ein
Problem, das bei verteilten elektronischen Transaktionen wie den
oben beschriebenen entsteht, besteht darin, das Risiko zu kontrollieren,
das Inhaltsschöpfer
und -verteiler tragen, wenn ihr Inhalt von Verbrauchern benutzt
oder an diese verteilt wird. So werden beispielsweise Inhaltseigentümer gewöhnlich verhindern
wollen, dass Verbraucher ihren Inhalt stehlen und an andere verteilen,
und sie werden auch verhindern wollen, dass Verbraucher die technischen
Mechanismen umgehen, mit denen Transaktionen durchgeführt und durchgesetzt
werden. Es ist jedoch wünschenswert,
dieses Risiko auf eine Weise zu kontrollieren, die die Inhaltsgebrauchserfahrung
des Verbrauchers nicht über
Gebühr
mindert, denn je schwieriger es für den Verbraucher ist, auf
elektronischen Inhalt zuzugreifen und ihn zu benutzen, desto unwahrscheinlicher
ist es, dass ihn der Verbraucher benutzen wird, und so können Schutzmaßnahmen
gegen Piraterie, die Einkommensverluste für den Inhaltsanbieter verhüten sollen,
den gegenteiligen Effekt haben. Daher werden Systeme und Methoden benötigt, um
es Inhaltsanbietern zu ermöglichen,
ihr Risiko flexibel und effizient auf eine Weise zu verwalten, die
den Einfluss, den Risikomanagemententscheidungen auf die Erfahrung
des Endbenutzers und somit auf die allgemeine Wünschenswertigkeit und Verteilung
des Inhalts haben, berücksichtigt
und reduziert.
-
Die
WO 9301550 beschreibt ein Lizenzverwaltungssystem, das einen Datensatz
der empfangenen Datagramme verwaltet und die empfangenen Datagramme
mit in seiner Lizenznehmerdatenbank gespeicherten Daten vergleicht.
Demzufolge sendet das Lizenzkontrollsystem Antwort-Datagramme entweder
mit einer Verweigerungs- oder einer Genehmigungsmeldung zum Monitor.
Der Monitor beendet eine weitere Benutzung des Produkts, wenn er
eine Verweigerungsmeldung erhält.
Der Monitor erzeugt seine eigene Verweigerungsmeldung, wenn seine
angeforderten Datagramme nach einem vorbestimmten Zeitintervall
unbeantwortet bleiben.
-
Die
vorliegende Erfindung stellt Systeme und Verfahren bereit, um es
Inhaltseigentümern
zu ermöglichen,
elektrische Transaktionen effizient, sicher und auf eine Weise durchzuführen, die
es individuellen Inhaltseigentümern
gestattet, nuancierte Entscheidungen über das Risikoniveau zu fällen, das
sie in einer bestimmten Transaktion zu tragen bereit sind. In einem
Ausgestaltungssatz wird ein Kommunikationsprotokoll offenbart, wie
auch Systeme und Verfahren zum Benutzen dieses Protokolls zum Verwalten
von Kommunikation zwischen an einer elektronischen Transaktion beteiligten
Sites. Ein anderer Ausgestaltungssatz offenbart eine Schwellenwertfunktion,
um Offline-Transaktionen
zu ermöglichen
und das Risikoniveau zu verwalten, das der Inhaltsverkäufer beim
Durchführen
derselben trägt.
Es ist zu verstehen, dass die vorliegende Erfindung auf zahlreiche
Weisen ausgeführt
werden kann, einschließlich
als Verfahren, als Vorrichtung, als System, als Gerät, als Methode,
als rechnerlesbares Medium oder als eine Kombination davon. Es werden
nachfolgend mehrere erfinderische Ausgestaltungen der vorliegenden
Erfindung beschrieben.
-
In
einer Ausgestaltung wird ein Kommunikationsprotokoll bereitgestellt,
das zuverlässige
Transaktionszustandssynchronisation für an einer verteilten Transaktion
teilnehmende Peers ermöglicht.
Eine Transaktionsverarbeitungsanwendung wird auf einem lokalen Computersystem
zum Verwalten von Transaktionen darauf eingesetzt. Das lokale Computersystem
nimmt Kontakt mit einem Ferncomputersystem auf, um eine Berechtigung
zur Ausführung
einer Transaktion einzuholen. Das lokale Computersystem kann einen
Fehlererholungsjob einleiten, der die Aufgabe hat, automatisch Statussignale
und andere Informationen erneut zum Fernsystem zu senden, wenn die
Kommunikation mit dem Fernsystem bestimmte vordefinierte Fehlerbedingungen zeigt.
Das Fernsystem kann die Definition der vordefinierten Fehlerbedingungen
einstellen. Wenn die Transaktion ohne Auslösung der vordefinierten Fehlerbedingungen
beendet wird, dann wird der Fehlererholungsjob storniert. Die Transaktionsverarbeitungsanwendung
kann auch verzögerte
Transaktionen zwischen Fernparteien zulassen. Die Transaktionsverarbeitungsanwendung
kann einen Datensatz der vom Verbraucher auf dessen lokalem System
durchgeführten
Transaktionen führen.
Nach dem Eintreten von vordefinierten Bedingungen können Transaktionsdatensätze zu einem
Fernverkäufer
oder zu einer Clearingstelle gesendet werden. Der Verkäufer oder
die Clearingstelle kann das getragene Risiko durch geeignetes Festlegen
der vordefinierten Bedingungen verwalten.
-
In
einer anderen Ausgestaltung wird ein Synchronisationsprotokoll für Peer-to-Peer-Transaktionen
offenbart. Es wird ein lokales Computersystem mit einem Speichermedium
und einem Kommunikationsport bereitgestellt, wie auch ein Ferncomputersystem
mit einem Speichermedium und einem Kommunikationsport. Das Speichermedium
des lokalen Systems enthält
eine bedingt zugängige
Datei und das Fernsystem ist kommunikativ mit einer Datenbank gekoppelt,
die Berechtigungsdatensätze
in Bezug auf den Zugriff auf die bedingt zugängige Datei enthält. Das
lokale Computersystem ist so konfiguriert, dass es mit dem Ferncomputersystem
kommuniziert, um die Berechtigung zum Zugreifen auf den Inhalt der
bedingt zugängigen
Datei zu erhalten. Das Synchronisationsprotokoll hat die Aufgabe,
die Führung
einer synchronisierten Kopie, im Wesentlichen in Echtzeit, des Transaktionszustands
der Kommunikation zwischen dem lokalen Computersystem und dem Ferncomputersystem
zu ermöglichen.
In einer Ausgestaltung hat das Fernsystem die Aufgabe, die Zahlung
nach dem Erhalt einer Berechtigung von der Berechtigungsdatensätze enthaltenden
Datenbank und nach dem Erhalt einer Bestätigung vom lokalen Computersystem
einzuholen, dass ein Benutzer des lokalen Computersystems erfolgreich
auf die bedingt zugängige
Datei zugreifen konnte.
-
In
noch einer weiteren Ausgestaltung wird ein Verfahren zum Durchführen von
Peer-to-Peer-Transaktionen offenbart. Ein Fernsystem empfängt eine
Anforderung, einem Benutzer eines lokalen Computersystems die Berechtigung
zum Zugreifen auf Daten zu geben, die auf dem lokalen System des
Benutzers gespeichert sind. Das Fernsystem prüft, ob der Benutzer zum Zugreifen
auf die Daten berechtigt ist und genügend Mittel auf seinem Konto
hat, um für
diesen Zugriff zu zahlen. Das Fernsystem sendet die Berechtigung
zum lokalen Computersystem, um dem Benutzer den Zugriff auf die
Daten zu gestatten. Das lokale Computersystem hat die Aufgabe, die
Berechtigung zu empfangen, dem Benutzer Zugriff auf die Daten zu
gewähren
und eine Bestätigung
zum Fernsystem zu senden, dass dem Benutzer der Zugriff auf die
Daten gewährt
wurde. Das Fernsystem hat die Aufgabe, die Bestätigung zu empfangen, Mittel vom
Konto des Benutzers zu nehmen und ein Signal zum lokalen System
zu senden, das anzeigt, dass die Transaktion abgeschlossen ist.
Wenn das lokale System dieses Signal nicht innerhalb eines vordefinierten
Zeitraums nach dem Senden der Bestätigung empfängt, dann hat das lokale System
die Aufgabe, eine zweite Bestätigung
zum Fernsystem zu senden. In einer Ausgestaltung kann ein Benutzer
des Fernsystems den vordefinierten Zeitraum einstellen, den das
lokale Computersystem abwartet, bevor es die zweite Bestätigung sendet.
In noch einer weiteren Ausgestaltung hat das Fernsystem ferner die
Aufgabe, die Berechtigung erneut zum lokalen Computersystem zu senden,
wenn das Fernsystem nicht innerhalb eines vordefinierten Zeitraums
eine Bestätigung
vom lokalen System erhält, dass
das lokale System dem Benutzer Zugang zu dem Inhalt gewährt hat.
-
In
einer anderen Ausgestaltung wird ein Verfahren zum Übermitteln
von Transaktionsdatensätzen
zu einer oder mehreren Clearingstellen mittels intermittierender
Kommunikation und abgefragter Bestätigungen mit von Anbieterparteien
vorgegebenen Übermittlungsanforderungen
beschrieben. Anbieter definieren ihre Toleranz für ein akzeptables Risikoniveau,
das mit unverarbeiteten Datensätzen
assoziiert ist, durch Vorgeben von Schwellenwerten. Diese Schwellenwerte
können
gemeinsam wirksam sein und Alter, Datensatzzahl, Finanzwert, Durchschnittsalter,
einen altersgewichteten Wert und andere vordefinierte Charakteristiken
vorgeben. Datensätze
werden immer übermittelt,
wenn eine Kommunikation erfolgen soll, und Bestätigungen werden auf derselben
Basis abgefragt oder erneut abgefragt. Datensätze können mehrere Verarbeitungsstufen – z.B. Empfang,
Zahlungseinleitung, erfolgreiche Zahlung – in einem oder mehreren Zielsystemen
durchlaufen; jede dieser Stufen sendet eine Bestätigung zurück und jede dieser Stufen kann
von unterschiedlichen Schwellenwerten reguliert werden.
-
Die
vorliegende Erfindung stellt ein Verfahren zum Gewähren von
Zugang zu einem Stück
Inhalt auf einem ersten Computersystem in einer vernetzten Umgebung
bereit, die das genannte erste Computersystem und ein zweites Computersystem
beinhaltet, wobei das Verfahren die folgenden Schritte umfasst:
Senden einer Anforderung vom ersten Computersystem zum zweiten Computersystem,
wobei die Anforderung um Genehmigung zum Zugreifen auf den Inhalt
ersucht wird; Einleiten der Ausführung
eines Bestätigungsüberwachungsprozesses
am ersten Computersystem, wobei der Bestätigungsüberwachungsprozess die folgenden Aufgaben
hat: (a) Erfassen einer zweiten Bestätigung vom zweiten Computersystem,
wobei die zweite Bestätigung
anzeigt, dass das zweite Computersystem eine erste Bestätigung vom
ersten Computersystem erhalten hat; und (b) Senden einer dritten
Bestätigung
zum zweiten Computersystem, wenn die zweite Bestätigung vom ersten Computersystem
als Reaktion auf die erste Bestätigung
nicht erhalten wurde und wenn eine vordefinierte Bedingung erfüllt ist;
Empfangen der Anforderung am zweiten Computersystem; Ermitteln am
zweiten Computersystem, ob der Anforderung entsprochen werden soll;
Senden eines Statusindikators vom zweiten Computersystem zum ersten
Computersystem, wobei der Statusindikator eine Anzeige beinhaltet,
dass der Anforderung entsprochen wurde; Empfangen des Statusindikators
am ersten Computersystem und Freigeben des Inhalts an einen Benutzer;
Senden der ersten Bestätigung
vom ersten Computersystem zum zweiten Computersystem, wobei die
erste Bestätigung
anzeigt, dass der Inhalt dem Benutzer erfolgreich freigegeben wurde;
Empfangen der ersten Bestätigung
am zweiten Computersystem; Senden der zweiten Bestätigung vom zweiten
Computersystem zum ersten Computersystem; Empfangen der zweiten
Bestätigung
am ersten Computersystem; Beenden der Ausführung des Bestätigungsüberwachungsprozesses.
Es wird auch ein entsprechendes Computerprogrammprodukt bereitgestellt.
Gemäß einer
Ausgestaltung sendet ein erstes Computersystem eine Anforderung
zu einem zweiten Computersystem, wobei die Anforderung um Genehmigung
zum Zugreifen auf den Inhalt ersucht. Das erste Computersystem leitet
auch die Ausführung
eines Überwachungsprozesses
ein. Der Überwachungsprozess
kann Bestätigungen
vom zweiten Computersystem erfassen. Das zweite Computersystem empfängt die
Anforderung vom ersten Computersystem und ermittelt, ob es der Anforderung
entsprechen oder sie ablehnen soll. Wenn das zweite Computersystem
entscheidet, der Anforderung zu entsprechen, dann sendet es ein
Statussignal zum ersten Computersystem. Nach dem Erhalt des Statussignals
gibt das erste Computersystem den Inhalt für den Gebrauch frei und sendet
eine erste Bestätigung zum
zweiten Computersystem. Der Überwachungsprozess
hat die Aufgabe, die erste Bestätigung
erneut zum zweiten Computersystem zu senden, wenn das erste Computersystem
nicht innerhalb einer vordefinierten Zeitperiode eine Antwort auf
die erste Bestätigung
erhalten hat.
-
Eine
Ausgestaltung der Erfindung stellt ein Verfahren und ein Computerprogrammprodukt
bereit, das die folgenden Schritte umfasst: Einleiten der Kommunikation
zwischen dem ersten Computersystem und dem zweiten Computersystem,
wobei die Kommunikation die Anforderung vom ersten Computersystem
zum zweiten Computersystem beinhaltet; Einleiten eines Fehlererholungsjobs
am ersten Computersystem, wobei der Fehlererholungsjob die Aufgabe
hat, automatisch ein Statussignal zum zweiten Computersystem zu
senden, wenn die Kommunikation zwischen dem ersten Computersystem
und dem zweiten Kommunikationssystem eine vordefinierte Fehlerbedingung
aufweist; Empfangen eines Signals vom zweiten Computersystem; Verwenden
des Signals zum Modifizieren einer Definition der vordefinierten
Fehlerbedingung.
-
In
einer anderen Ausgestaltung wird ein Verfahren zum Verwalten der Übertragung
von Transaktionsprüfdatensätzen von
einem ersten Computersystem zu einer Clearingstelle offenbart. Gemäß dieser
Ausgestaltung wird im ersten Computersystem eine erste Zahl für die Anzahl
der Prüfdatensätzen geführt, die
sich im ersten Computersystem angesammelt haben. Wenn die erste
Zahl einen vordefinierten Betrag übersteigt, dann werden die
Prüfdatensätze für eine Übermittlung
zur Clearingstelle geplant. Wenn die Prüfdatensätze zur Clearingstelle übermittelt
werden, dann kann die Clearingstelle eine Bestätigung zum ersten Computersystem senden,
wobei die Bestätigung
die Anzahl der Prüfdatensätzen identifiziert,
die die Clearingstelle verarbeitet hat. Nach dem Eingang dieser
Bestätigung
dekrementiert das erste Computersystem die erste Zahl um einen Betrag,
der gleich der Anzahl der Prüfdatensätze ist,
die in der Bestätigung
von der Clearingstelle identifiziert ist. In einer Ausgestaltung
führt das
erste Computersystem auch eine zweite Zahl, wobei die zweite Zahl
den Gesamtwert der unbezahlten Eingänge von Transaktionen verfolgt,
die auf dem ersten Computersystem durchgeführt wurden. Wenn die Prüfdatensätze, die
diesen Transaktionen entsprechen, von der Clearingstelle verarbeitet
werden, dann sendet die Clearingstelle eine Bestätigung zum ersten Computersystem
zurück,
die anzeigt, dass diese Eingänge
bezahlt wurden. Das erste Computersystem dekrementiert dann die
zweite Zahl entsprechend.
-
Somit
stellt eine Ausgestaltung der Erfindung ein Verfahren und ein Computerprogramprodukt
bereit, die ferner zum Verwalten der Übertragung von Transaktionsprüfdatensätzen vom
ersten Computersystem zum zweiten Computersystem gestaltet ist,
wenn das zweite Computersystem eine Clearingstelle umfasst, wobei das
Verfahren die folgenden Schritte umfasst: Führen einer ersten Zahl der
Anzahl der Prüfdatensätzen, die sich
am ersten Computersystem angesammelt haben; Akkumulieren einer vordefinierten
Anzahl von Prüfdatensätzen am
ersten Computersystem; Erzeugen eines Prüfdatensatzes am ersten Computersystem;
Erhöhen der
ersten Zahl; Vergleichen der ersten Zahl mit einem ersten vordefinierten
Schwellenwert; Übertragen
von wenigstens der vordefinierten Anzahl von Prüfdatensätzen zu der Clearingstelle;
Empfangen einer ersten Bestätigung
von der Clearingstelle; Verringern der ersten Zahl. Diese sowie
weitere Merkmale und Vorteile der vorliegenden Erfindung werden
in der folgenden detaillierten Beschreibung ausführlicher anhand der Begleitzeichnung
dargelegt, die beispielhaft die Grundsätze der Erfindung illustrieren.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Die
vorliegende Erfindung wird anhand der folgenden detaillierten Beschreibung
in Verbindung mit den Begleitzeichnungen besser verständlich,
bei denen gleiche Strukturelemente dieselben Bezugsziffern erhielten.
Dabei zeigt:
-
1 ein
System zum Durchführen
von Transaktionen gemäß den Grundsätzen der
vorliegenden Erfindung;
-
2 ein
Computersystem zum Umsetzen von Ausgestaltungen der vorliegenden
Erfindung;
-
3A, 3B, 3C, 3D, 3E, 3F und 3G verschiedene
Aspekte eines Kommunikationsprotokolls gemäß einer Ausgestaltung der vorliegenden
Erfindung;
-
4 die
Struktur und Funktion eines Schwellenobjekts gemäß einer Ausgestaltung der vorliegenden Erfindung;
-
5 die
Verwendung von Schwellenwerten gemäß einer Ausgestaltung der vorliegenden
Erfindung;
-
6A, 6B und 6C die
Form mehrerer Typen von bedingten Ausdrücken, die mit Schwellenwerten
benutzt werden können,
gemäß Ausgestaltungen
der vorliegenden Erfindung;
-
7 den
Fluss von Prüfdatensätzen und
Bestätigungen
zwischen einer Clearingstelle und einem Verbrauchersystem;
-
8 die
Verwendung von Schwellenwerten in einer elektronischen Transaktion
gemäß einer
Ausgestaltung der vorliegenden Erfindung.
-
AUSFÜHRLICHE BESCHREIBUNG
-
Es
folgt eine ausführliche
Beschreibung der Erfindung. Die Erfindung wird zwar in Verbindung
mit mehreren Ausgestaltungen beschrieben, aber es ist zu verstehen,
dass die Erfindung nicht auf irgendeine Ausgestaltung begrenzt ist.
Ganz im Gegenteil, der Umfang der Erfindung ist lediglich durch
die beiliegenden Ansprüche
begrenzt und umfasst zahlreiche Alternativen, Modifikationen und Äquivalente.
So wurden zwar beispielsweise Ausgestaltungen in Zusammenhang mit
Systemen und Verfahren zum Kommunizieren zwischen physisch voneinander
entfernten Computersystemen über
ein Netzwerk beschrieben, aber die Fachperson wird erkennen, dass
die offenbarten Systeme und Methoden auch leicht für breitere
Anwendungen adaptierbar sind. So könnten die Systeme und Verfahren
der vorliegenden Erfindung beispielsweise, ohne Einschränkung, leicht
in Zusammenhang mit Kommunikationen zwischen Komponenten in einem
integrierten Computersystem angewendet werden. Darüber hinaus
wurden zwar in der folgenden Beschreibung zahlreiche spezifische
Einzelheiten dargelegt, um ein tief greifendes Verständnis der
vorliegenden Erfindung zu vermitteln, aber die vorliegende Erfindung
kann gemäß den Ansprüchen ohne
einige oder alle dieser Details umgesetzt werden. Schließlich wurde
der Deutlichkeit halber bestimmtes technisches Material, das in
der Technik bekannt ist, nicht ausführlich beschrieben, damit die
vorliegende Erfindung nicht unklar wird.
-
Die
vorliegende Erfindung stellt Systeme und Verfahren zum Durchführen von
elektronischen Transaktionen zwischen entfernten Parteien auf eine
Weise bereit, die die Rechte und Interessen der beteiligten Parteien
schützt,
ohne die Effizienz der Transaktion übermäßig zu mindern. Es wird fehlertolerantes
Kommunikationsprotokoll beschrieben, das Soforttransaktionen zwischen
ortsfernen Parteien erleichtert. Das Kommunikationsprotokoll besteht
aus einer Folge von Signalen, die zwischen einem Verbrauchersystem
und einem Verkäufersystem
gesendet werden. Das Protokoll ist so ausgelegt, dass für den Verbraucher
sichergestellt ist, dass ihm ein Artikel erst dann in Rechnung gestellt
wird, wenn er ihn erhalten hat, und für den Verkäufer auf effektive Weise gewährleistet
wird, dass der Verbraucher für
Artikel bezahlt, die er erhält.
-
In
einer anderen Ausgestaltung werden Systeme und Verfahren zum Ermöglichen
von verzögerten Transaktionen
zwischen ortsfernen Parteien bereitgestellt. Gemäß dieser Ausgestaltung kann
ein Verbraucher elektronischen Inhalt kaufen und benutzen, ohne
sich zuerst an das Fernsystem des Verkäufers anschließen zu müssen. Eine
Transaktionsverarbeitungsanwendung befindet sich auf dem Verbrauchersystem,
und diese Anmeldung führt
einen Datensatz der vom Verbraucher durchgeführten Aktionen. Wenn vordefinierte
Bedingungen eingetreten sind, dann werden Transaktionsdatensätze zum
Verkäufer
oder zu einer Clearingstelle gesendet. Der Verkäufer oder die Clearingstelle
kann das getragene Risiko durch geeignetes Einstellen der vordefinierten
Bedingungen verwalten.
-
1 zeigt
ein System zum Durchführen
von elektronischen Transaktionen gemäß Ausgestaltungen der vorliegenden
Erfindung. Wie in 1 gezeigt, sendet ein Verkäufer 102 elektronischen
Inhalt 118 zu einem Verbraucher zur Verwendung auf dem
Computersystem 104 des Verbrauchers. So könnte beispielsweise
ein Verbraucher eine verschlüsselte
Audio- oder Videodatei von der Internet-Website des Verkäufers herunterladen
oder könnte
sich eine Diskette oder CD beschaffen, die eine solche Datei enthält. Der
Inhalt 118 kann mit bestimmten Regeln assoziiert sein,
die die Benutzung des Inhalts durch den Verbraucher bestimmen sollen. So
möchte
z.B. der Verkäufer
eines Audio-Track dem Benutzer jedes Mal, wenn er sich den Track
anhört, $0,10
berechnen. Um eine solche Regel durchzusetzen, kann dem Verbraucher
ein Anwendungsprogramm 112 gegeben werden, wobei das Anwendungsprogramm
Transaktionen für
den Verkäufer
verwalten kann. Wenn ein Verbraucher versucht, heruntergeladenen
Inhalt 118 durch Aufrufen eines Wiedergabeprogramms 110 wie
z.B. einer elektronischen Jukebox zu benutzen, dann verarbeitet
die Anwendung 112 die Anforderung des Verbrauchers, belastet
das Konto des Verbrauchers, erzeugt einen Datensatz der Transaktion,
entschlüsselt
den Inhalt und gibt ihn zur Wiedergabeanwendung 110 frei.
Die Anwendung 112 kann auch Datensätze senden, die die Transaktion 122 auf
eine oder mehrere Clearingstellen 106 beziehen, deren Verantwortlichkeit es
ist zu gewährleisten,
dass der Verkäufer
bezahlt und der Verbraucher entsprechend belastet wird. Datensätze 122 können beispielsweise
Informationen über
die Benutzung des Inhalts durch den Verbraucher enthalten, wie z.B.
der Betrag, der dem Verbraucher in Rechnung zu stellen ist, oder
Informationen, die der Benutzer über
seine Gebrauchsgewohnheiten zu geben eingewilligt hat. Clearingstellen 106 und/oder
Verkäufer 102 können auch
mit einer Finanzautorisierungszentrale, z.B. einer Bank 114,
kommunizieren, um Informationen über
den Kreditstand des Verbrauchers einzuholen und das Konto des Verbrauchers
zu belasten. Wie nachfolgend ausführlicher beschrieben wird,
stellt die vorliegende Erfindung Systeme und Verfahren zum Verwalten solcher
Transaktionen auf eine effiziente, flexible und sichere Weise bereit.
-
In
einer Ausgestaltung umfasst Transaktionsverarbeitungssoftware 112 eine
Instanz der InterRights PointTM Software,
die von InterTrust Technologies Corporation aus 4750 Patrick Henry
Drive, Santa Clara, Kalifornien 95054 hergestellt wird. In dieser
Ausgestaltung können
Inhalt 118 und/oder Prüfdatensätze 122 in
DigiBox® sicheren
Behältern
verpackt werden, die ebenfalls von InterTrust entwickelt wurden.
Man wird jedoch verstehen, dass für die Zwecke der Umsetzung
der vorliegenden Erfindung jeder Inhaltscontainer oder jede(s) Dateiformat
und/oder Transaktionsverarbeitungsanwendung zum Einsatz kommen kann.
Ferner ist zu verstehen, dass in einer bevorzugten Ausgestaltung
Kommunikationen zwischen Verbrauchern 104, Verkäufern 102 und/oder
Clearingstellen 106 zwar verschlüsselt, digital signiert, in
sicheren Behältern
verpackt oder auf andere Weise geschützt sind, dass ein solcher
Schutz aber nicht erforderlich ist.
-
So
ist zu verstehen, dass 1 lediglich eine Diskussion über die
vorliegende Erfindung vereinfachen soll und dass eine Reihe verschiedener
Modifikationen an der darin gezeigten Grundarchitektur vorgenommen werden
können.
So können
beispielsweise in einigen Ausgestaltungen Verkäufer 102 Transaktionsdaten 122 direkt
von Verbrauchern 104 sammeln und so die Notwendigkeit für separate
Clearingstellen 106 vermeiden. Als weiteres Beispiel, 1 zeigt
zwar, wie Verkäufer 102 und
Clearingstellen 106 mit Verbrauchern 104 über ein
Netzwerk 108 wie das Internet kommunizieren, aber es ist
zu verstehen, dass jede geeignete Kommunikationsform zur Anwendung
kommen kann. So könnte
das Verbrauchersystem 104 beispielsweise ein elektronisches
Taschengerät
wie z.B. einen Portable Digital Assistant, einen digitalen Taschen-Media-Player
oder dergleichen und die Clearingstelle 106 ein relativ
sicheres Computersystem am Ort des Verbrauchers umfassen (z.B. einen
Personal Computer mit einem speziellen Chip- oder Smartcard-Zusatz) – das möglicherweise über eine
dedizierte Verbindung (z.B. DSL oder eine gewöhnliche Einwählverbindung)
mit einem Fernserver verbunden ist. In einer solchen Ausgestaltung
könnte
das Verbrauchersystem 104 die Systeme und Verfahren der vorliegenden
Erfindung zum Kommunizieren mit dem lokalen System 106 der
Clearingstelle über
ein Infrarot- oder Funkwellensignal oder einfach durch Anschließen eines
Kabels von dem Verbrauchersystem zu dem lokalen System der Clearingstelle
benutzen. Das lokale System der Clearingstelle könnte dann mit dem Fernsystem
der Clearingstelle mit den Systemen und Verfahren der vorliegenden
Erfindung und/oder mit Hilfe hinlänglich bekannter Mittel für eine sichere
Kommunikation (z.B. SSL) kommunizieren.
-
2 gibt
eine ausführlichere
Illustration des Aufbaus und Betriebs des Verbrauchersystems 104 gemäß einer
Ausgestaltung der vorliegenden Erfindung. Wie oben erwähnt, kann
das System 104 aus einem beliebigen geeigneten Gerät einschießlich, ohne
Begrenzung, einem Personal Computer, einem tragbaren Audio- oder
Video-Player, einer Fernseh-Set-Top-Box, einem Telefon, einem Personal
Digital Assistant oder dergleichen bestehen. Wie in 2 gezeigt,
beinhaltet das System 104 typischerweise Folgendes:
- • eine
Zentraleinheit 216;
- • einen
Systemspeicher 218, der vorzugsweise sowohl einen schnellen
Arbeitsspeicher (RAM) als auch einen nichtflüchtigen Festwertspeicher (ROM)
zum Speichern von Programmen und Daten für die Verwendung und Ausführung durch
die Zentraleinheit 216 beinhaltet;
- • eine
nichtflüchtige
Massenspeichereinheit 270, die löschbaren nichtflüchtigen
Speicher wie z.B. eine magnetische Festplatte (z.B. eine Harddisk)
und/oder Flash-Memory zum Speichern von geschützten Inhaltsdateien, Anwendungsprogrammen,
Daten und dergleichen umfasst;
- • ein
oder mehrere Ein-/Ausgabegeräte
wie z.B.:
• Netzschnittstelle 210 zum
Kommunizieren mit anderen Systemen über ein Netzwerk 108 wie
das Internet;
• E/A-Port 212 für den Anschluss
an ein oder mehrere Peripheriegeräte; und/oder
• ein oder
mehrere Diskettenlaufwerke 214 zum Lesen von und/oder Schreiben
auf Disketten, CDs, DVDs und/oder andere rechnerlesbare Medien;
- • eine
Benutzeroberfläche 226 wie
z.B. ein Display 228 und ein oder mehrere Eingabegeräte wie eine
Tastatur 206 und eine Maus 208; und
- • einen
oder mehrere interne Busse 240 zum Verbinden der oben genannten
Elemente des Systems miteinander.
-
Der
Betrieb des Systems 104 wird hauptsächlich durch Programme gesteuert,
die im Systemspeicher 218 enthalten sind und von der Zentraleinheit 216 des
Systems ausgeführt
werden. So könnte
das System 104 beispielsweise ein oder mehrere Wiedergabeanwendungen 110 enthalten,
deren Aufgabe es ist, den Inhalt dem Benutzer anzuzeigen oder auf
andere Weise darzustellen. Im Falle von geschütztem Inhalt 118 submittieren
Wiedergabeanwendungen 110 in einer Ausgestaltung Anforderungen
um Zugriff auf den Inhalt dem Transaktionsverarbeitungsanwendungsprogramm 112.
Die Transaktionsverarbeitungsanwendung 112 kommt dann der
Anforderung mit den an anderer Stelle hierin beschriebenen Techniken
entweder nach oder lehnt sie ab.
-
Programmiercode
zum Ausführen
der hierin beschriebenen elektronischen Transaktionsverfahren ist vorzugsweise
in die Transaktionsverarbeitungsanwendung 112 (z.B. direkt
oder durch eine Verbindung mit einem Bibliotheksmodul) integriert.
Die Methoden der vorliegenden Erfindung schützen zwar gegen bestimmte Formen
von Attacken und/oder Umgehung, z.B. Abtrennen des Verbrauchersystems 104 vom
Netz 108 während
bestimmten kritischen Punkten einer Transaktion, aber einen Teil
ihrer Sicherheit erhalten diese Verfahren auch von der Integrität der Transaktionsverarbeitungsanwendung 112 selbst.
Demgemäß können bevorzugte Ausgestaltungen
der vorliegenden Erfindung mittels Hardware- und/oder Software-Sicherheitstechniken
sicherstellen, dass die Transaktionsverarbeitungsanwendung 112 plangemäß arbeitet.
-
So
kann beispielsweise in einer Ausgestaltung das System 104 eine
spezielle geschützte
Verarbeitungsumgebung 288 wie z.B. die beinhalten, die
von einer integrierten Schaltung in einem eingriffssicheren Hardware-Paket
bereitgestellt wird. Wie in 2 gezeigt,
kann die geschützte
Verarbeitungsumgebung 288 einen nichtflüchtigen Speicher 289,
einen flüchtigen
Speicher 290, einen Prozessor 291, eine eingriffssichere Barriere 293 und
einen Kommunikationsport 294 für die Kommunikation mit anderen
Komponenten des Systems 104 beinhalten. Die Verwendung
einer geschützten
Verarbeitungsumgebung ist dahingehend von Vorteil, dass sie einen
Bereich bereitstellt, der gegen eine unberechtigte Beobachtung oder
Modifikation abgeschirmt ist, in der schutzwürdige Programme laufen und
kryptografische Keys und andere Informationen gespeichert werden
können.
So können
beispielsweise Transaktionsverarbeitungsanwendungen 112,
oder gewählte
Teile davon, in den RAM 290 der geschützten Verarbeitungsumgebung 288 geladen
und von der CPU 291 ausgeführt werden, wodurch der Betrieb
der Transaktionsverarbeitungsanwendung 112 vor einem Eingriff
oder einer sonstigen Modifikation geschützt wird. Weitere Informationen über Implementationen
einer geschützten
Verarbeitungsumgebung befinden sich im gemeinsam zugewiesenen US-Patent
Nr. 5,892,900 „Systems
and Methods for Secure Transaction Management and Electronic Rights
Protection", das
am 6. April 1999 erteilt wurde („das '900 Patent"), und in der gemeinsam zugewiesenen provisorischen
US-Anmeldung Nr. 60/150,126, „Secure
Processing Unit Systems and Methods", die am 20. August 1999 eingereicht
wurde.
-
In
einer anderen, etwas weniger sicheren Ausgestaltung nutzt die Transaktionsverarbeitungsanwendung
112 Software-Vernebelung
und andere Software-Selbstverteidigungstechniken,
um sich vor einem unentdeckten Eingriff zu schützen. Zusätzliche Informationen über geeignete
Software-Vernebelungs- und Selbstverteidigungstechniken befinden
sich im '900 Patent
sowie im gemeinsam zugewiesenen US-Patent
US 6 668 325 mit dem Titel „Obfuscation
Techniques for Enhancing Software Security", eingereicht am 9. Juni 1998, und in
der gemeinsam zugewiesenen US-Patentanmeldung Nr. 09/629,546 mit
dem Titel „Software Self-Defense Systems and
Methods", die am
31. Juli 2000 eingereicht wurde.
-
Darüber hinaus
könnte
das System 104 vorteilhafterweise Hardware und/oder Software
zum Bereitstellen von sicherem Massenspeicher für schutzwürdige Buchhaltungs-, Gebrauchs-
oder sonstige Informationen beinhalten. So kann können beispielsweise
eine spezialisierte Hardware-Datenbank und/oder relativ sichere
Software-Speicherschutzmechanismen (oder Software-und-Hardware-Hybridmechanismen)
wie z.B. die verwendet werden, die im '900 Patent und in der gemeinsam zugewiesenen
US-Patentanmeldung Nr. 09/617,148 mit dem Titel „Trusted Storage Systems and
Methods" von Maheshwari
et al., eingereicht am 17. Juli 2000 („die Maheshwari-Anwendung") dargelegt sind.
-
2 zeigt
zwar die allgemeine Architektur eines typischen Verbrauchersystems 104,
aber man wird verstehen, dass eine Reihe von Modifikationen an der
darin gezeigten Grundstruktur vorgenommen werden können, ohne
von den Grundsätzen
der vorliegenden Erfindung abzuweichen. Außerdem wird man verstehen, dass
Clearingstellen 106 und Verkäufer 102 ähnliche
oder identische Systeme nutzen können.
-
Soforttransaktionsprotokoll
-
Bei
einer „Soforttransaktion" zahlt ein Verbraucher
für elektronischen
oder sonstigen Inhalt zu dem Zeitpunkt, an dem der Inhalt an den
Verbraucher freigegeben wird. Zu Illustrationszwecken wird eine
beispielhafte Technik zum Ausführen
einer solchen Transaktion in Zusammenhang mit einer Transaktion
zwischen dem Verbraucher 104 und der Clearingstelle 106 beschrieben,
aber man wird verstehen, dass eine solche Transaktion ebenso leicht
zwischen beliebigen geeigneten Parteiengruppen erfolgen könnte, einschließlich, aber
ohne Beschränkung,
Verbraucher 104 und Verkäufer 102, Verkäufer 102 und
Clearingstelle 106 usw.
-
Beim
Durchführen
einer Soforttransaktion ist es wichtig, die Synchronisation zwischen
dem Zustand des Verbrauchersystems 104 und dem Zustand
der Clearingstelle 106 aufrechtzuerhalten. So wäre es beispielsweise
nicht wünschenswert,
wenn Datensätze
auf dem Verbrauchersystem 104 anzeigen, dass der Verbraucher
ein Stück
Inhalt gekauft hat, während
Datensätze
an der Clearingstelle 106 anzeigen, dass der Verbraucher
dies nicht getan hat. Genauso wenig wäre es wünschenswert, wenn Datensätze an der
Clearingstelle 106 anzeigen würden, dass der Inhalt dem Verbraucher
nicht freigegeben wurde, wenn er in der Tat doch freigegeben wurde.
-
Die
Aufrechterhaltung von Synchronisation zwischen Peers in einer elektronischen Peer-to-Peer-Kommunikation,
wie z.B. die Kommunikation zwischen Verbraucher 104 und
Clearingstelle 106, ist jedoch eine schwierige Aufgabe.
Wenn beispielsweise das Verbrauchersystem ein Signal zur Clearingstelle sendet,
dann gibt es im Allgemeinen keine Möglichkeit für das Verbrauchersystem zu
wissen, ob die Clearingstelle das Signal empfangen hat, es sei denn,
dass eine Bestätigung
von der Clearingstelle eingeht, die anzeigt, dass das Signal empfangen
wurde. Die Clearingstelle weiß jedoch
dann ebenfalls nicht, ob das Verbrauchersystem diese Bestätigung erhalten
hat, es sei denn, dass das Verbrauchersystem nach dem Erhalt der Bestätigung selbst
eine Bestätigung
zurück
zur Clearingstelle sendet. Diese zweite Bestätigung erfordert eine dritte
Bestätigung
usw., so dass der Systemdesigner vor einer Aufgabe mit einer potentiell
unendlichen Rekursion steht.
-
Eine
Möglichkeit,
die Rekursion zu unterbrechen, besteht darin, dass sowohl der Verbraucher
als auch die Clearingstelle ihre Bestätigung zu einer dritten Partei
senden, die dann ein Signal zurück
zu beiden Parteien sendet, dass die Bestätigung von der anderen Partei
empfangen wurde. Der Overhead für
das Hinzuziehen einer dritten Partei zur Transaktion kann jedoch
relativ groß sein,
und dies kann auch aus Sicherheitsgründen nicht immer möglich oder
wünschenswert
sein. Und natürlich
leiden Kommunikationen zwischen der Drittpartei und jeder der anderen
Parteien immer noch an dem ursprünglichen
Problem der unendlichen Rekursion. Die Hinzuziehung eines Fremdvermittlers
ist daher gewönlich
an sich noch keine ausreichende Lösung.
-
Das
Zustandssynchronisationsproblem ist besonders in Zusammenhang mit
verteilten Computerumgebungen akut, wie z.B. dem in 1 gezeigten,
die zum Durchführen
von finanziellen oder anderen schutzwürdigen Transaktionen verwendet
werden. In diesem Zusammenhang gibt es gewöhnlich einen Anreiz für eine oder
beide der Parteien, die andere durch Eingreifen in das System zu
betrügen.
So könnte
beispielsweise ein Verbraucher – der
sich möglicherweise
im Ausland befindet – Inhalt
vom Verkäufer
empfangen und dann die Zahlung verweigern, so dass der Verkäufer keine
wirksame Handhabe hat. Ebenso könnte
ein Verkäufer eine
Zahlung annehmen und sich dann weigern, den gekauften Inhalt zu
liefern. Außerdem
könnte
es einen Anreiz für
Fremdparteien geben, sich in Transaktionen einzumischen, zum Schaden
einiger oder aller legitimen Parteien. Schließlich könnten gelegentliche Systemausfälle auftreten,
die ohne böse
Absicht, verhindern können,
dass Transaktionen auf rechtzeitige oder effiziente Weise ausgeführt werden.
-
Die
vorliegende Erfindung stellt Systeme und Verfahren zum Ausführen von
elektronischen Transaktionen auf eine effektiv gleichzeitige Weise
vom Standpunkt der Teilnehmer bereit, und ermöglicht die Ausführung von
Soforttransaktionen, ohne dass eine Vermittlung durch eine dritte
Partei notwendig wäre.
In einer bevorzugten Ausgestaltung erhalten die Parteien genügend Informationen über den
Fortschritt der Transaktion, um im Falle eines unerwarteten Ereignisses
auf effiziente und vorhersehbare Weise eine Erholungsmaßnahme durchführen zu
können.
-
Ein
illustratives Kommunikationsprotokoll gemäß einer Ausgestaltung der vorliegenden
Erfindung wird nachfolgend mit Bezug auf die 3A – 3G beschrieben,
die die Aktionen und die Kommunikationsfolge zeigen, die von einem
lokalen Computersystem und einem Ferncomputersystem durchgeführt werden.
Das lokale Computersystem könnte
beispielsweise das Computersystem (104) eines Verbrauchers
repräsentieren, und
das Ferncomputersystem könnte
beispielsweise das Computersystem (102) eines Inhaltsverteilers
oder das System einer Partei – z.B.
einer Clearingstelle 106 – sein, die mit dem Eintreiben
von Zahlungen für
den Inhaltsverteiler (102) beauftragt ist. Es ist jedoch
zu verstehen, dass das lokale Computersystem und das Ferncomputersystem
von jeder beliebigen geeigneten Entität sein können. So werden zwar einige
Aktionen, um die Erläuterung
zu erleichtern, als vom lokalen System oder vom Fernsystem eingeleitet
oder durchgeführt
beschrieben, aber man wird verstehen, dass diese Aktionen typischerweise
durch geeignete Software wie die Transaktionsverarbeitungsanwendung 112 oder
in diesen Systemen enthaltene Hardware durchgeführt werden.
-
Wie
in 3A gezeigt, kann ein Verbraucher Inhalt, der verschlüsselt oder
auf eine andere Weise gespeichert ist, die ihn praktisch unzugänglich macht
(302), herunterladen oder sich auf andere Weise beschaffen.
Nach dem Eingang der Anforderung des Verbrauchers um Zugang zu dem
Inhalt (304) erzeugt das lokale System 104 des
Verbrauchers einen oder mehrere Prüfdatensätze und setzt einen Job 305 (nachfolgend
ausführlicher
erläutert)
in eine von der Anwendung 112 geführte Job-Warteschlange (306). So könnte z.B.
die Transaktionsverarbeitungsanwendung 112 einen Thread
beinhalten, der als Manager von Hintergrundtasks dient, die in die
Warteschlange gesetzt wurden. Job 305 beinhaltet vorzugsweise
eine Identifikation des Prüfdatensatzes,
dem er entspricht, und eine Anzeige, ob die mit dem Prüfdatensatz
assoziierte Transaktion erfolgreich oder erfolglos war (z.B. ein
Zweizustands-Statusflag, der Erfolg oder Misserfolg anzeigt). Wenn
der Job zum ersten Mal in die Jobwarteschlange gesetzt wird, wird
sein Flag auf Misserfolg gesetzt. Das lokale System 104 leitet
dann die Kommunikation mit einem Fernsystem, wie z.B. einer Clearingstelle 106 oder
einem Verkäufer 102,
ein, um eine Berechtigung zum Zugreifen auf den Inhalt einzuholen.
Darüber
hinaus wird eine Kopie des Prüfdatensatzes 307 zum
Fernsystem (308) gesendet.
-
Wie
in 3B gezeigt, empfängt das Fernsystem den Prüfdatensatz 307 und
beginnt mit der Verarbeitung der Transaktion, der der Prüfdatensatz
enspricht (310). So kann beispielsweise das Fernsystem
mit einer Bank 114 oder einer anderen Finanzbehörde Kontakt
aufnehmen, um zu ermitteln, ob die Kreditkarte des Verbrauchers
gültig
ist und über
einen ausreichenden Kredit verfügt,
um die von dem Prüfdatensatz 307 beschriebene
Transaktion abzudecken. Wie in 3B gezeigt,
kann das Fernsystem in einigen Ausgestaltungen ein optionales Signal 314 zum
lokalen System senden, um diesem eine Schätzung der Zeit zu geben, die
zum Vollenden des Autorisierungsvorgangs (312) benötigt wird.
Nach dem Eingang eines solchen Signals kann das lokale System beispielsweise
dem Verbraucher eine Meldung anzeigen, die besagt, wie lange der
Autorisierungsvorgang voraussichtlich dauern wird. Darüber hinaus
kann das lokale System eine Rückbestätigung zum Fernsystem
senden.
-
Wieder
mit Bezug auf 3B, wenn das Fernsystem die
Verarbeitung des Ermittelns, ob die Transaktion autorisiert werden
soll, beendet, dann sendet es eine Transaktionsstatusmeldung 318 zum
lokalen System, die entweder anzeigt, dass die Berechtigung erhalten
wurde (z.B. ein OK-Signal) oder dass die Berechtigung nicht erhalten
wurde (z.B. ein Verweigert-Signal) (316). Wenn die Berechtigung
erhalten wurde, dann kann das Fernsystem auch eine Anzeige 320 darüber senden,
wie lange das lokale System warten soll, bis das Fernsystem ein
weiteres Signal – das „Neusendebestätigung"-Signal – sendet,
dessen Zweck nachfolgend beschrieben wird. Ferner kann, wenn eine
Berechtigung erhalten wurde, das Fernsystem das Konto des Verbrauchers
sperren, um zu verhindern, dass das Guthaben des Verbrauchers unter
das zum Vollenden der Transaktion nötige Niveau abfällt, wodurch
gewährleistet
wird, dass genügend
Mittel vorhanden sind, wenn das Fernsystem die Erlaubnis hat, Mittel
vom Konto des Verbrauchers einzuziehen.
-
Wenn
die Berechtigung für
die Transaktion verweigert wurde, dann sendet das Fernsystem eine
entsprechende Statusmeldung zum lokalen System. Nach dem Eingang
einer solchen Meldung bricht das lokale System die Transaktion ab
und kann dem Verbraucher eine Meldung anzeigen, die angibt, was
passiert ist. Wenn das Verbrauchersystem ein Signal erhält, das
anzeigt, dass die Berechtigung verweigert wurde, dann wird der angeforderte
Inhalt nicht an den Verbraucher freigegeben.
-
Wenn
jedoch die Berechtigung erhalten wurde, dann aktualisiert, wie in 3C gezeigt,
das lokale System nach dem Eingang eines Transaktionsstatussignals 318 (342)
den Statusflag von Job 305, so dass er Erfolg anzeigt,
und aktualisiert jedwede relevante Schwellenwerte, wie nachfolgend
ausführlicher
beschrieben wird (322). Das lokale System schließt dann
seinen Teil der Transaktion ab, z.B. indem es den Inhalt entschlüsselt und
ihn an den Verbraucher freigibt (324). Nach dem Freigeben
des Inhalts sendet das lokale System eine Bestätigung 328 zum Fernsystem,
die anzeigt, dass die Transaktion erfolgreich abgeschlossen wurde
(326). In einer Ausgestaltung werden die Schritte, die
das lokale System nach dem Eingang der Berechtigung 318 durchführt (342), „asynchron" durchgeführt. Das
heißt,
der Vorgang des Entschlüsselns
und Freigebens des Inhalts erfolgt unabhängig von den übrigen Schritten
im Protokoll, so dass der Verbraucher schnelleren Zugang zu dem
Inhalt erhält,
da der Verbraucher nicht zuerst zu warten braucht, bis die Kommunikationsfolge zwischen
dem lokalen System und dem Fernsystem abgeschlossen ist.
-
Wie
in 3D gezeigt, schließt das Fernsystem nach dem
Erhalt der Bestätigung 328 (368)
seinen Teil der Transaktion dadurch ab, dass es z.B. die Transaktion
auf der Kreditkarte des Verbrauchers verbucht und die Mittel vom
Konto des Kunden abzieht und/oder eine andere geeignete Aktion durchführt (332).
Das Fernsystem sendet auch eine Bestätigung 336 – d.h. das
Neusendebestätigungssignal – zum lokalen
System, das anzeigt, dass das Fernsystem die Bestätigung 328 des
lokalen Systems empfangen und seinen Teil der Transaktion abgeschlossen
hat (334).
-
Wie
in 3E gezeigt, nimmt das lokale System nach dem Erhalt
des Neusendebestätigungssignals 336 (338)
den Job 305 aus seiner Hintergrund-Jobwarteschlange (339). In
einigen Ausgestaltungen kann das lokale System auch eine Anforderung
für eine
Session-Schließung
(z.B. RSCX) zum Fernsystem senden (und eine Bestätigung darauf empfangen), bevor
es die Kommunikationsleitung schließt (340). 3F fasst
die Kommunikationsfolge zwischen dem lokalen und dem Fernsystem
in der oben beschriebenen Ausgestaltung zusammen.
-
Aufgrund
von Ineffizienzen, Ausfällen
oder Angriffsversuchen auf das System – die am lokalen System, am
Fernsystem und/oder am Netzwerk auftreten – kann die Kommunikation zwischen
dem lokalen System und dem Fernsystem möglicherweise nicht unbedingt
immer in der oben beschriebenen Weise ablaufen. So können beispielsweise
ein oder mehrere der Signale zwischen dem lokalen System und dem
Fernsystem verloren gehen, sich verzögern, umgeleitet oder verfälscht werden.
Die vorliegende Erfindung stellt Mechanismen bereit, um effizient
auf solche Ausfälle
in einer Weise zu reagieren, die mit den Systemregeln und Sicherheitsbeschränkungen
im Einklang steht. Es folgen Beispiele für mehrere Fehlerbedingungen
und die Reaktion des Systems darauf.
-
Lokales
System empfängt
kein Statussignal 318. Nachdem das lokale System einen
Prüfdatensatz zum
Fernsystem gesendet hat (d.h. Block 308 in 3A),
wartet das lokale System auf das Transaktionsstatussignal 318 vom
Fernsystem (d.h. Block 342 in 3C). Wenn
das lokale System das Statussignal nicht erhält (oder es nicht innerhalb
einer vordefinierten Zeitperiode erhält), sendet das lokale System
in einer Ausgestaltung den Prüfdatensatz
erneut (oder eine Meldung, die anzeigt, dass kein Statussignal empfangen
wurde), so dass dieser Vorgang eine vorbestimmte Anzahl von Malen
wiederholt wird, bevor aufgegeben und der Verbraucher beispielsweise
darüber
informiert wird, dass das Fernsystem nicht antwortet oder dass die
Netzwerkverbindung abgebrochen ist. Dieser Vorgang kann in den Neusendejob 305 integriert
werden, der vom Hintergrundmanager der Anwendung 112 ausgeführt wird,
oder er kann unabhängig
durchgeführt
werden. In anderen Ausgestaltungen gibt das lokale System ohne Neuversuch
auf, wenn eine vordefinierte Zeitperiode verstrichen ist. Wenn das
lokale System kein Transaktionsstatussignal 318 erhält, dann
gibt das lokale System den Inhalt nicht an den Verbraucher frei
oder führt
eine andere Tätigkeit
nicht durch, für
die eine Berechtigung gesucht wurde. Außerdem wird, da das lokale
System so keine Bestätigung 328 zum
Fernsystem sendet, das Fernsystem das Konto des Verbrauchers nicht
belasten.
-
Fernsystem
erhält
keine Bestätigung 328.
Ebenso wartet das Fernsystem, nachdem es ein Transaktionsstatussignal 318 zum
lokalen System gesendet hat, das anzeigt, dass die Transaktion autorisiert
wurde, auf eine Bestätigung 328 vom
lokalen System, die besagt, dass die Transaktion vollständig abgeschlossen
ist (d.h. Block 368 von 3D). Wie
oben beschrieben, fährt
das Fernsystem nach dem Erhalt der Bestätigung 328 mit dem
Abschließen
seines Teils der Transaktion beispielsweise durch Einziehen der
autorisierten, und möglicherweise
gesperrten, Mittel fort (d.h. Block 332 von 3D).
Wenn das Fernsystem jedoch keine Bestätigung 328 erhält, dann
autorisiert das Fernsystem den Einzug der Mittel nicht. Außerdem sendet
das Fernsystem kein Signal 336 zum lokalen System, das,
wie nachfolgend beschrieben, das lokale System veranlasst, das Signal 328 erneut
zu senden (wenn es denn schon einmal gesendet wurde).
-
Außerdem könnte, wenn
das Fernsystem die Anzeige 328 vom lokalen System nicht
erhalten hat, dass die Transaktion abgeschlossen (oder erfolglos
verlaufen) ist, der Operator des Fernsystems eine geeignete Verteidigungsmaßnahme ergreifen – z.B. mit
dem Verbraucher oder Eigentümer
des lokalen Systems Kontakt aufnehmen, das Konto des Verbrauchers
einstweilen sperren, das Netzwerk und/oder das Fernsystem auf Störungen prüfen usw. – und so
einen betrügerischen
Eingriff in das System durch einen Angreifer verhüten und somit
eine rasche Diagnose von Geräteproblemen
ermöglichen.
-
Lokales
System erhält
keine Bestätigung 336.
Wenn das lokale System nicht innerhalb einer vordefinierten Periode
(z.B. 1, 2 oder 5 Minuten) nach der Freigabe von Inhalt an den Verbraucher
und dem Senden der Bestätigung 328 zum
Fernsystem (und/oder eine vordefinierte Zeitperiode nach dem Einleiten
des Neusendejobs 305) kein Neusende-Bestätigungssignal 336 erhält, dann
sendet das lokale System die Bestätigung 328 automatisch
neu und/oder eine Kopie des Prüfdatensatzes 307,
der besagt, dass die Transaktion vollständig abgeschlossen ist. Wie
oben beschrieben, erfasst das Fernsystem nach dem Eingang dieses
Signals die in Block 316 von 3B reservierten
Mittel und/oder trifft eine andere entsprechende Maßnahme.
-
Der
Ablauf des Neusendejobs 305, der für diese Funktion verantwortlich
ist, ist in 3G dargestellt. Wie oben angedeutet,
umfasst der Neusendejob 305 in einer Ausgestaltung einen
Hintergrundthread oder einen anderen parallelen Vorgang in der Anwendung 112,
der eingeleitet wird, wenn der Verbraucher Zugang zu geschütztem Inhalt
(370) anfordert. Wie in 3G gezeigt,
hat der Neusendejob 305 die Aufgabe, automatisch zu versuchen,
eine Bestätigung 377 (wie
z.B. die Bestätigung 328)
und/oder einen Prüfdatensatz
auf periodischer Basis zum Fernsystem zu senden (oder erneut zu
senden), bis das Neusende-Bestätigungssignal
empfangen wird (372 – 380).
Der Hintergrundjob kann auch die Aufgabe haben, eine Fehlermeldung
oder Warnung (379) zum Fernsystem zu senden, wenn eine
vordefinierte Periode verstreicht, ohne dass das Neusende-Bestätigungssignal
eingeht, und/oder wenn eine vordefinierte Anzahl an unbestätigten Versuchen
vorgenommen wird, die Bestätigung 377 zu
senden (378). Der Neusendejob 305 ist somit ein
Mechanismus zum Abschließen einer
Transaktion trotz des Auftretens von vorübergehenden Störungen,
die den Verlust oder die Verzögerung der
Bestätigung 328 verursachen.
Darüber
hinaus kann der Neusendejob 305 vorteilhafterweise einem
Versuch eines Angreifers entgegenwirken, eine Zahlung durch Abtrennen
oder Unterbrechen der Kommunikation des lokalen Systems mit dem
Fernsystem und/oder durch Abfangen der Bestätigung 328 des lokalen
Systems zu umgehen. Der Neusendejob erschwert eine solche Attacke,
da er die Anzahl der Signale erhöht,
die der Angreifer abfangen oder verfälschen muss, um eine Erfassung
zu umgehen, und indem der Angreifer effektiv gezwungen wird, vom
Netzwerk getrennt zu bleiben, da der Hintergrund-Neusendejob bei
jedem Anschluss des Angreifers an das Netzwerk die Bestätigung (oder
eine Fehlermeldung) neu zum Fernsystem sendet, so dass das Fernsystem
die Mittel einziehen und/oder die verdächtige Aktivität entdecken
kann.
-
In
einer Ausgestaltung kann die Transaktionsverarbeitungsanwendung 112 des
Verbrauchers auch einen sicheren Datensatz davon speichern, dass
sie kein Neusende-Bestätigungssignal 336 erhalten
hat, was später
bei der Ermittlung der Ursache für
die Systemstörung
verwendet werden kann. Das Fernsystem kann diesen Datensatz später vom
lokalen System zurückholen
und/oder der Verbraucher kann ihn dem Operator des Fernsystems vorzeigen,
um einen Nachweis für
das Geschehene zu erhalten und/oder um den ordnungsgemäßen Betrieb
des lokalen Systems des Verbrauchers zu demonstrieren.
-
In
einer bevorzugten Ausgestaltung kann der Operator des Fernsystems
die Zeit x vorgeben, die der Hintergrund-Neusendejob des lokalen
Systems abwarten soll, bevor er die Bestätigung 328 erneut
sendet (und/oder die Anzahl y von unbestätigten Übertragungen von Bestätigung 328/377,
die er tolerieren soll, bevor er einen Fehler oder eine Meldung 381 sendet/speichert).
So kann beispielsweise eine Spezifikation dieser Zeitperiode 320 zusammen
mit der Berechtigung zur Freigabe des Inhalts 318 zum lokalen System
gesendet oder zu einem anderen geeigneten Zeitpunkt bereitgestellt
werden. So erhalten Inhaltseigentümer und Verteiler einen Mechanismus,
um das Verhalten der Transaktion und ihre Risiko für Systemstörungen zu
kontrollieren.
-
Lokales
System gibt Inhalt trotz Erhalt eines negativen Statussignals 318 frei.
In einer bevorzugten Ausgestaltung sendet das lokale System automatisch
einen Statusbericht an das Fernsystem, wenn der Inhalt freigegeben
wird und/oder wenn der Status eines Prüfdatensatzes von Misserfolg
auf Erfolg wechselt (es sei denn, das Fernsystem fordert an, dass
dieser Bericht nicht gesendet wird). Diese Kommunikation wird vorzugsweise
in den Hintergrundkommunikationsprozess 305 integriert,
der immer in eine Warteschlange gesetzt wird, wenn Inhalt angefordert
(oder in einigen Ausgestaltungen freigegeben) wird. Wie oben beschrieben, bleibt
der Hintergrundprozess 305 so lange aktiv, bis eine Mitteilung
vom Fernsystem empfangen wird, die besagt, dass das Fernsystem seinen
Teil der Transaktion abschließen
konnte. Wenn also das lokale System den Anweisungen des Fernsystems,
den Inhalt nicht freizugeben, nicht Folge leistet, dann wird der
Operator des Fernsystems darüber
informiert und kann sofort Verteidigungsmaßnahmen ergreifen. Um eine
Entdeckung durch das Fernsystem zu vermeiden, muss ein Angreifer
daher möglicherweise
das lokale System von jedem Kommunikationsmedium (wie dem Internet)
getrennt halten, über
das der Hintergrundverarbeitungsjob die Meldung zum Fernsystem senden
kann. Dies ist gewöhnlich
keine sehr attraktive Option für
den Angreifer, besonders dann, wenn der Wert des gekauften Inhalts
in Bezug auf die Lästigkeit
der Tatsache, dass er das lokale System nicht im vollen Umfang benutzen
kann, relativ gering ist.
-
Die
durchschnittliche Fachperson wird erkennen, dass der Deutlichkeit
halber auf eine Beschreibung bestimmter bekannter Signale, die durch
das/die zu Grunde liegende Netzwerkprotokoll oder Transportschicht (z.B.
TCP/IP, HTTP, FTP, AAL 5 usw.) bestimmt werden, in der obigen Erörterung
verzichtet wurde. Ferner konzentrierte sich die Diskussion zwar
hauptsächlich
auf eine Transaktion zwischen zwei Parteien, aber man wird verstehen,
dass die vorliegende Erfindung auch leicht auf Transaktionen angewendet
werden kann, die mehr als zwei Parteien involvieren. Darüber hinaus
wurde zwar implizit angenommen, dass sich der bedingt zugängige Inhalt
während
des oben beschriebenen Prozesses auf dem lokalen System des Verbrauchers
befindet, aber man wird verstehen, dass dieser Inhalt auch während des
ganzen oder eines Teils des Prozesses an einer entfernten Stelle,
einschließlich
auf dem Fernsystem 102 oder 106, gespeichert sein
kann, ohne von den Grundsätzen
der vorliegenden Erfindung abzuweichen.
-
Außerdem wurde
zwar ein Kommunikationsprotokoll in Zusammenhang mit Soforttransaktionen
zwischen einem Verbraucher 104, Verkäufer 102 und/oder
der Clearingstelle 106 dargestellt, die den Kauf von elektronischem
Inhalt beinhalten, aber man wird verstehen, dass das Protokoll auch
leicht auf andere Situationen angewendet werden kann. So könnte das
Protokoll beispielsweise verwendet werden, um die Übertragung
von Mitteln von der Clearingstelle 106 zum Verkäufer 102 zu
verwalten, um den Transfer von Prüfdatensätzen zwischen Verbraucher 104 und
Clearingstelle 106 in einer Nicht-Sofort-Transaktion zu
verwalten und/oder um eine Reihe verschiedener anderer Typen von
Transaktionen oder Kommunikationen zu ermöglichen.
-
Verzögerte Transaktionen: Schwellenwerte
-
Die
obige Erörterung
konzentrierte sich hauptsächlich
auf Transaktionen, in denen erwartet wird, dass der Verbraucher
für Inhalt
dann bezahlt, wenn dieser für
den Gebrauch freigegeben wird (oder effektiv zur selben Zeit). Wie
oben beschrieben, erfordern solche Transaktionen im Allgemeinen
eine Verbindung zwischen dem System des Verbrauchers und dem des
Verkäufers
(oder der Clearingstelle). Um jedoch Leistung und Fehlertoleranz
zu verbessern und um eine breitere Palette an Geschäftsbeziehungen
zwischen Verkäufer
und Verbraucher zu ermöglichen,
kann es auch wünschenswert
sein, es dem Verbraucher zu gestatten, Inhalt ohne eine Verbindung
mit dem Verkäufersystem
zu kaufen und zu benutzen und die Zahlung auf einen späteren Zeitpunkt
zu verzögern,
wenn eine Verbindung mit dem Verkäufersystem praktischer ist.
Verzögerte
Transaktionen bieten dem Verbraucher zwar mehr Flexibilität und geben
somit dem Inhaltsverkäufer
bessere Verkaufschancen, aber verzögerte Transaktionen bedeuten
auch ein höheres
Risiko für
den Verkäufer,
da ein Angreifer die relative Isolation des Computersystems des
Verbrauchers für
einen Versuch nutzen könnte,
geschützten
Inhalt zu modifizieren oder zu stehlen, Transaktionsdatensätze zu löschen oder
zu verändern oder
in den Betrieb der Transaktionsverarbeitungsanwendung einzugreifen.
Die vorliegende Erfindung stellt Systeme und Verfahren bereit, die
es Inhaltseigentümern
und -verkäufern
ermöglichen,
ihre Gefährdung
für solche
Angriffe zu verwalten.
-
In
einer bevorzugten Ausgestaltung werden sichere verzögerte Transaktionen
ermöglicht,
indem dem Verbraucher eine Transaktionsverarbeitungsanwendung 112 zur
Verfügung
gestellt wird, die sich auf dem Verbrauchersystem 104 befindet
und die Transaktionen für
den Verkäufer
durchführt
und verwaltet. Wenn der Verbraucher ein Stück Inhalt kauft, dann entschlüsselt die
Anwendung 112 den Inhalt und gibt ihn an den Verbraucher
frei. Wie in den 1 und 5 dargestellt,
erzeugt die Anwendung 112 auch einen oder mehrere Prüfdatensätze 122,
die unter anderem den Preis aufführen,
den der Verbraucher für
den Inhalt bezahlt hat, die Identität der Clearingstelle 106,
zu der die Prüfdatensätze zur
Verarbeitung zu senden sind, und dergleichen. Um eine unentdeckte
Löschung
oder Modifikation zu verhüten,
speichert die Anwendung 112 vorzugsweise Prüfdatensätze in einem
sicheren, eingriffsresistenten Speicher wie z.B. dem, der im '900 Patent oder der
Maheshwari-Anmeldung beschrieben ist, die beide zuvor durch Bezugnahme
eingeschlossen wurden. Außerdem beinhaltet
die Anwendung 112 vorzugsweise Software-Selbstverteidigungstechniken
und/oder läuft
in einer sicheren Umgebung wie z.B. die geschützte Verarbeitungsumgebung 288 in 2.
-
Wie
in 5 gezeigt, können
in einer Ausgestaltung Prüfdatensätze 122 ein
oder mehrere Clearingstelleninformations-(CHInfo)-Objekte 510 und/oder
Budgets 512 referenzieren, die wiederum einen oder mehrere
Schwellenwerte 514 referenzieren können. Ein CHInfo-Objekt 510 ist
ein Programmierkonstrukt, das mit geschütztem Inhalt 118 assoziiert
und/oder verpackt sein kann. Ein CHInfo-Objekt 510 identifiziert
die mit dem Inhalt assoziierte Clearingstelle, die von der Clearingstelle
akzeptierten Zahlungsweisen, sowie eine Liste von Schwellenwerten,
die die Lieferung von Zahlungen oder Prüfdatensätzen an die Clearingstelle
regeln. Ebenso ist ein Budget-Objekt 512 ein
Programmierkonstrukt, das der Transaktionsverarbeitungsanwendung 112 des Verbrauchers
von einem Kreditgeber oder einem Provider von Debitkonten oder elektronischem
Bargeld bereitgestellt (und oder darin instanziiert) wird. Das Verbraucherbudget
enthält
Informationen über
das Konto des Verbrauchers (z.B. Kontostand, verfügbarer Kredit
usw.) sowie eine Liste von Schwellenwerten, die die Zahlung von
aufgelaufenen Saldos und dergleichen regulieren.
-
Allgemein
ausgedrückt,
die Schwellenwertfunktion 514 bietet einen Mechanismus
zum Überwachen von
Transaktionen auf dem Verbrauchersystem und zum Triggern vordefinierter
Aktionen, wenn bestimmte Bedingungen eintreten. So kann beispielsweise
die Schwellenwertfunktion 514 die Beträge von Offline-Gebühren oder
Prüfdatensätzen begrenzen,
die der Verbraucher auflaufen lassen kann, bevor er sich beim Computersystem
einer Clearingstelle, eines Budget-Providers oder eines Verkäufers anschließt. So kann
ein Schwellenwert 514b auf dem Budget 512 so angesehen
werden, dass er das Risiko des Budget-Providers begrenzt, während ein
Schwellenwert 514a auf dem CHInfo-Objekt 510 so
angesehen werden kann, dass er die Rechte der Clearingstelle schützt.
-
4 zeigt
eine ausführlichere
Illustration der Struktur eines Schwellenwertobjekts 514 gemäß einer Ausgestaltung
der vorliegenden Erfindung. Wie in 4 gezeigt,
beinhaltet eine Schwellenwertfunktion 514 typischerweise
eine Typdefinition 412 (z.B. eine Bestätigung, bezahlt oder gesteuert),
einen oder mehrere Trigger 401 und eine Reihe verschiedener
Statusinformationen 406 – wie z.B. einen aktuellen
Wert (z.B. einen Währungsbetrag),
eine aktuelle Zahl (z.B. eine Zahl von aufgelaufenen Prüfdatensätzen) und
eine letzte Bestätigung
(z.B. eine Anzeige der letzten Uhrzeit, wann das Verbrauchersystem
mit einer Clearingstelle kommuniziert hat).
-
Die
durchschnittliche Fachperson wird erkennen, dass die in 4 dargestellte
Struktur und Funktionalität
leicht in einer oder mehreren Datenstrukturen ausgeführt werden
kann, die von der Transaktionsverarbeitungsanwendung 112 geführt werden.
So werden beispielsweise in einer Ausgestaltung Schwellenwerte als Objekte
in einer objektorientierten Programmiersprache wie C++ oder Java
implementiert. Die durchschnittliche Fachperson wird jedoch erkennen,
dass die in 4 dargestellten Funktionsbeziehungen
leicht in jeder geeigneten Weise implementiert werden können, ohne
von den Grundsätzen
der vorliegenden Erfindung abzuweichen.
-
Die
Variablen, die den Zustand eines Schwellenwerts umfassen, können inkrementiert
werden, wenn eine Transaktion auftritt (z.B. wenn ein Verbraucher
ein Stück
Inhalt kauft oder benutzt), und können als Reaktion auf Ereignisse
wie die erfolgreiche Übermittlung
von Prüfdatensätzen zu
einer Clearingstelle zurückgesetzt
oder aktualisiert werden. Wenn beispielsweise ein Kunde ein Stück Inhalt
für $5,00
kauft und zwei Prüfdatensätze in dem
Prozess erzeugt, dann würde
die VALUE-Variable des entsprechenden Schwellenwertes um $5,00 erhöht, und
die COUNT-Variable des Schwellenwertes würde um zwei erhöht. Wenn
die Prüfdatensätze zur
Clearingstelle übermittelt
werden, würde
die COUNT-Variable des Schwellenwertes um zwei reduziert und die
Variable LAST_ACKNOWLEDGMENT (letzte Bestätigung) des Schwellenwertes
könnte
so aktualisiert werden, dass sie Datum und Uhrzeit der Übermittlung
der Datensätze
reflektiert. Ebenso würde,
wenn die $5,00 bezahlt sind (z.B. wenn die Prüfdatensätze als von der Clearingstelle
verarbeitet bestätigt
sind), die VALUE-Variable des Schwellenwertes um $5,00 reduziert.
-
Tabelle
1 zeigt eine illustrative Liste der Typen von Schwellenwerten, die
in einer Ausgestaltung der vorliegenden Erfindung verwendet werden,
sowie der Bedingungen, unter denen die Statusvariablen der Schwellenwerte
aktualisiert werden.
-
-
Wie
in Tabelle 1 gezeigt und nachfolgend ausführlicher in Verbindung mit 7 beschrieben,
werden in einer Ausgestaltung Bestätigungsschwellenwerte und Bezahlt-Schwellenwerte als
Reaktion auf von einer Clearingstelle eingegangene Bestätigungen
aktualisiert. Im Gegensatz dazu werden in einer bevorzugten Ausgestaltung
Gesteuert-Schwellenwerte
von speziellen Steuerprogrammen aktualisiert. So könnte beispielsweise
ein Gesteuert-Schwellenwert an ein vorbezahltes Budget-Objekt angehängt werden,
und der Budget-Provider könnte
ein spezielles Steuerprogramm zum Verwalten des Budgets verwenden – z.B. zum
Hinzufügen zusätzlicher
Mittel zu dem vorbezahlten Budget als Reaktion auf eine Verbraucheranforderung.
Dieser Mechanismus gibt somit dem Budget-Provider explizite Kontrolle
darüber,
wann und wie der Gesteuert-Schwellenwert und somit das Budget aktualisert
wird. Zusätzliche
Informationen über
die Erzeugung und Verwendung von Steuerprogrammen wie die, auf die
in diesem Beispiel Bezug genommen wird, befinden sich in der gemeinsam
zugewiesenen US-Patentanmeldung Nr. 09/628,958 mit dem Titel „Systems
and Methods for Controlling, Managing, Identifying and/or Creating
Objects in a Distributed Computing Environment", die am 31. Juli 2000 eingereicht wurde.
-
Wieder
mit Bezug auf 4, in einer Ausgestaltung beinhalten
Trigger 401 jeweils einen bedingten Ausdruck 402 und
eine Aktion 404. Wenn der bedingte Ausdruck erfüllt ist,
dann wird der Trigger aktiviert und die Aktion wird ausgeführt. Tabelle
2 illustriert drei Typen von Bedingungen, die in einem bedingten
Ausdruck 402 beurteilt werden können.
-
-
Die 6A–6C illustrieren
die Form von mehreren Typen von bedingten Ausdrücken, die mit Schwellenwerten
gemäß Ausgestaltungen
der vorliegenden Erfindung verwendet werden können. So könnte beispielsweise, wie in 6A gezeigt,
eine Bedingung wie folgt aussehen:
value > 200USD
-
Dieser
bedingte Ausdruck enthält
ein Ziel 602, einen Operator 604 und eine Grenze 606.
In diesem Beispiel wird ein VALUE (WERT) beurteilt, und die Grenze
ist ein Währungsbetrag.
Wenn eine ACKAGE (BESTÄTIGUNG)
beurteilt würde,
dann könnte
die Grenze ein Zeitintervall sein, und wenn eine COUNT (ZAHL) beurteilt
würde,
dann wäre
die Grenze eine ganze Zahl.
-
Wie
in 6B gezeigt, könnte
der Trigger-Ausdruck auch logische Operatoren 610 enthalten.
Darüber hinaus
ist es, wie in 6C gezeigt, möglich, zusammengesetzte
Trigger-Bedingungen zu haben, wobei der Trigger-Ausdruck als eine
Liste von Listen dargestellt wird und wobei die Inhalte jeder Reihe
logisch AND-verknüpft
und die Reihen logisch OR-verknüpft
werden, um die boolesche Beurteilung des Trigger-Ausdrucks zu bilden. In 6C gibt
die Liste 620 z.B. vor, dass, wenn das Verbrauchersystem
in den letzten 30 Tagen keine Bestätigung von der Clearingstelle
erhalten hat, der Verbraucher $500 an verzögerten Zahlungen auflaufen lassen
darf. Wenn das System in den letzten 60 Tagen keine Bestätigung erhalten
hat, dann beträgt
die Grenze $100, und wenn es in den letzten 90 Tagen keine Bestätigung erhalten
hat, dann beträgt
die Grenze $10.
-
Wie
zuvor angedeutet, wenn ein mit einem der Trigger einer Schwelle
assoziierter bedingter Ausdruck erfüllt ist, dann hat die Schwellenwertfunktion
die Aufgabe, die Transaktionsverarbeitungsanwendung 112 zur Ausführung einer
vordefinierten Aktion anzuweisen. Eine illustrative Liste von Trigger-Aktionen
befindet sich in Tabelle 3.
-
-
Man
beachte, dass die Aktionen FAIL und FAIL & NOTIFY einen Abbruch der Transaktion
verursachen (z.B. der Benutzer erhält keinen Zugang zu dem angeforderten
Inhalt und es wird ihm nichts berechnet). Diese Aktionen begrenzen
somit das Gesamtrisiko des Inhalts- und/oder Budget-Providers dadurch,
dass verhindert wird, dass der Verbraucher zusätzliche Gebühren auflaufen lassen oder
zusätzliche
Prüfdatensätze akkumulieren
kann.
-
Schwellenwerte
werden beurteilt, wenn Transaktionen auftreten (wie z.B. der Kauf
von Inhalt) und wenn Transaktionsbestätigungen von einer Clearingstelle
verarbeitet werden. Wenn ein Schwellenwert beurteilt wird, dann
wird jeder seiner Trigger beurteilt. In einer Ausgestaltung löst ein Trigger
seine Aktion aus oder ruft sie auf, wenn sich die Trigger-Bedingung
von FALSE auf TRUE ändert.
Wenn ein Trigger ausgelöst
hat, dann kann er nicht nochmals auslösen (d.h. er wird „unscharf"), bis die Bedingung
sich wieder von TRUE zurück
auf FALSE ändert,
und an dieser Stelle wird der Trigger wieder „scharf" und kann wieder auslösen, wenn die
Bedingung erfüllt
ist.
-
Tabelle
4 illustriert das Verhalten eines Schwellenwertes als Reaktion auf
eine Folge von Ereignissen. In dem in Tabelle 4 gezeigten Beispiel
beträgt
der Schwellenwert zunächst
$90, die Trigger-Bedingung lautet: value > $100.
-
-
Die
Trigger aller mit einer Transaktion assoziierten Schwellenwerte
werden vorzugsweise als eine Gruppe in zwei Durchgängen beurteilt.
Im ersten Durchgang werden Trigger beurteilt, die die Aktionen FAIL oder
FAIL & NOTIFY
beinhalten. Wenn einer dieser Trigger auslöst, wird die Transaktion abgebrochen
und es erfolgt keine weitere Schwellenwertverarbeitung. Es werden
keine Werte aktualisiert und es ist so, als hätte es die Transaktion nie
gegeben. Im zweiten Durchgang werden alle anderen Trigger beurteilt.
-
Wieder
mit Bezug auf 4, es folgt jetzt ein ausführlicheres
Beispiel der Funktionalität
und der Verwendung der Schwellenwertfunktion 514. Wie in 4 gezeigt,
zeigt die Typendefinition 412 an, dass der Schwellenwert 514 ein
Bestätigung-Schwellenwert ist.
So wird, wie in Tabelle 1 angedeutet, der Status des Schwellenwertes 514 aktualisiert,
wenn Prüfdatensätze erfolgreich
zu der entsprechenden Clearingstelle gesendet werden. Der Schwellenwert 514 könnte zunächst eine
COUNT-Variable von 0 enthalten. Immer wenn eine Transaktion auftritt,
dann wird die COUNT-Variable des Schwellenwertes 514 so
inkrementiert, dass sie die Anzahl der von der Transaktion erzeugten
Datensätze
reflektiert, und die Trigger des Schwellenwertes werden beurteilt.
Wenn beispielsweise der Verbraucher 20 Prüfdatensätze angesammelt
hat und versucht, eine Transaktion durchzuführen, die zur Speicherung des
einundzwanzigsten Prüfdatensatzes
führen
würde,
dann beurteilt der bedingte Ausdruck 402a mit TRUE und
Trigger 401a löst
aus und bewirkt dadurch, dass die DELIVER-Aktion 404a ausgeführt wird.
Das Ergebnis ist, dass die 20 angesammelten Prüfdatensätze zur Clearingstelle übermittelt
(oder für
die Übermittlung
geplant) werden. Die COUNT-Variable des Schwellenwertes wird um
20 dekrementiert, wenn eine Bestätigung
von der Clearingstelle eingeht, die angibt, dass die Prüfdatensätze empfangen/verarbeitet
wurden. Auch die Variablen ACKAGE und VALUE des Schwellenwertes
können
eingestellt werden.
-
7 zeigt
eine Folge von Bestätigungen,
die von der Clearingstelle 106 zum Verbrauchersystem 104 gesendet
werden. Wenn die Clearingstelle zunächst einen Satz von Prüfdatensätzen 710 erhält, dann
sendet sie eine Bestätigung 712 zum
Verbrauchersystem. Wie in 7 gezeigt,
wenn das Verbrauchersystem diese Bestätigung erhält, dann aktualisiert es den
Zustand der entsprechenden ACK-Schwellenwerte.
Wenn die Clearingstelle jeden Prüfdatensatz öffnet (z.B.
entschlüsselt),
sendet sie eine Bestätigung 714 zum
Verbrauchersystem, die den Eingang anzeigt (den das Verbrauchersystem
in einigen Ausgestaltungen zum Aktualisieren bestimmter Schwellenwerte
verwenden kann). Später
sendet die Clearingstelle eine zweite Bestätigung 716 für jeden
Prüfdatensatz,
die angibt, dass der Prüfdatensatz
vollständig
verarbeitet ist und jetzt archiviert oder gelöscht werden kann. Wie in 7 gezeigt,
aktualisiert das Verbrauchersystem den Zustand der PAID-(BEZAHLT)-Schwellenwerte, die
den verarbeiteten Prüfdatensätzen entsprechen,
wenn diese Bestätigungen 716 empfangen
werden. So wird ersichtlich, dass Datensätze mehrere Verarbeitungsstufen – z.B. Empfang,
Zahlungseinleitung, erfolgreiche Zahlung – in einer oder mehreren Clearingstellen
oder anderen Zielsystemen durchlaufen können. In jeder Stufe kann eine
Bestätigung
zurückgegeben
werden, die zum Aktualisieren eines Schwellenwertes verwendet werden
kann.
-
In
einer Ausgestaltung hat die Clearingstelle nach dem Eingang einer
Kommunikation 710 vom Verbrauchersystem auch die Aufgabe,
eine Anzeige 711 dafür
zu senden, wann das Verbrauchersystem wieder mit der Clearingstelle
in Kontakt treten soll, um die mit den Prüfdatensätzen 710 assoziierten
Bestätigungen zu
erhalten (714, 716). Dies ist beispielsweise dann
nützlich,
wenn das Verbrauchersystem vom Netzwerk abgetrennt oder auf andere
Weise unerreichbar ist, wenn die Clearingstelle versucht, Bestätigungen 714 oder 716 zu
senden. Die Transaktionsverarbeitungsanwendung 112 des
Verbrauchers empfängt
die Zeit-(oder Intervall-)Anzeige 711 und stellt sicher,
dass zu diesem Zeitpunkt eine Verbindung mit der Clearingstelle
hergestellt wird (oder dass dies in den vorgegebenen Intervallen
versucht wird) und/oder dass der Verbraucher aufgefordert wird,
eine solche Verbindung herzustellen.
-
8 illustriert
ferner die Verwendung von Schwellenwerten gemäß einer Ausgestaltung der vorliegenden
Erfindung. Wie in 8 gezeigt, erzeugt eine Transaktion 801 (wie
z.B. der Kauf eines Stücks
Inhalt) zwei Arten von Prüfdatensätzen 802, 804.
Prüfdatensatz 802 bezieht
sich auf CHInfo-Objekt 806, das sich wiederum auf die Schwellenwerte 808 und 810 bezieht.
Der Prüfdatensatz 802 referenziert
auch ein Budget-Objekt 812, das den Schwellenwert 814 referenziert.
Ebenso referenziert Prüfdatensatz 804 CHInfo-Objekt 816, das
den Schwellenwert 818 referenziert. Tabelle 5 zeigt eine
Reihe von illustrativen Szenarios auf der Basis der in 8 gezeigten
beispielhaften Anordnung und beschreibt, welche Trigger unter verschiedenen
Bedingungssätzen
auslösen
würden.
-
-
In
dem in Reihe 3 von Tabelle 5 gezeigten Fall besagt die erste Spalte,
dass der Gesamtwert der akkumulierten Prüfdatensätze in Verbindung mit CHInfo 806 $450
beträgt.
Aber der Schwellenwert 808 weist zur Übermittlung der Prüfdatensätze an,
wenn der akkumulierte Gesamtwert $20 oder höher ist. Die in Reihe 3 gezeigte
Situation könnte
beispielsweise dann auftreten, wenn Prüfdatensätze aus irgendeinem Grund nicht an
der Clearingstelle verarbeitet wurden. Der zusätzliche Schwellenwert bei CHInfo-Objekt 806 – d.h. Schwellenwert 810 – ist somit
deshalb nützlich,
weil er die Gebührenmenge,
die ein Kunde auflassen lassen kann, bevor die Rechnung bezahlt
werden muss, mit einer FAIL-Grenze beaufschlagt.
-
So
wird ersichtlich, dass Schwellenwerte einen Mechanismus bieten,
mit dem Verkäufer,
Clearingstellen, Budget-Provider und dergleichen ihr Risiko für den Verlust
von Geld, Inhalt oder Transaktionsinformationen aufgrund von bösartigen
Attacken oder Computerfehlfunktionen begrenzen können. Darüber hinaus können durch
Verwenden von aufeinander bezogenen Schwellenwerten oder Trigger-Bedingungen
relativ feinkörnige
Schutzfunktionen erhalten werden, da, wenn ein Schwellenwert oder
eine Bedingung aufgrund von Systemausfällen oder Attacken funktionsunfähig gemacht
wird, andere Schwellenwerte oder Bedingungen weiterhin in der Lage
sein können,
nachfolgende Transaktionen zu regulieren.
-
Die
obige Erfindung wurde zwar der Deutlichkeit halber ausführlich beschrieben,
aber es ist klar, dass bestimmte Änderungen und Modifikationen
im Rahmen der beiliegenden Ansprüche
durchgeführt
werden können.
Demgemäß sind die
vorliegenden Ausgestaltungen als illustrativ und nicht als einschränkend anzusehen und
die Erfindung ist nicht auf die hierin gegebenen Details begrenzt,
sondern kann innerhalb des Umfangs und der Äquivalente der beiliegenden
Ansprüche
modifiziert werden.