DE60132254T2 - Ein Informationsverwaltungssystem - Google Patents

Ein Informationsverwaltungssystem Download PDF

Info

Publication number
DE60132254T2
DE60132254T2 DE60132254T DE60132254T DE60132254T2 DE 60132254 T2 DE60132254 T2 DE 60132254T2 DE 60132254 T DE60132254 T DE 60132254T DE 60132254 T DE60132254 T DE 60132254T DE 60132254 T2 DE60132254 T2 DE 60132254T2
Authority
DE
Germany
Prior art keywords
data
encryption strength
outgoing data
application
computer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60132254T
Other languages
English (en)
Other versions
DE60132254D1 (de
Inventor
Peter Bryan Okehampton Malcolm
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CA Inc
Original Assignee
Orchestria Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orchestria Ltd filed Critical Orchestria Ltd
Application granted granted Critical
Publication of DE60132254D1 publication Critical patent/DE60132254D1/de
Publication of DE60132254T2 publication Critical patent/DE60132254T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4012—Verifying personal identification numbers [PIN]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/214—Monitoring or handling of messages using selective forwarding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2113—Multi-level security, e.g. mandatory access control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/212—Monitoring or handling of messages using filtering or selective blocking

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Marketing (AREA)
  • Tourism & Hospitality (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Development Economics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Game Theory and Decision Science (AREA)
  • Educational Administration (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Selective Calling Equipment (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)
  • Alarm Systems (AREA)
  • Circuits Of Receivers In General (AREA)

Description

  • HINTERGRUND DER ERFINDUNG
  • Die vorliegende Erfindung betrifft die Bereitstellung von erweiterter Managementfunktionalität für Internetanwendungen, insbesondere in den Bereichen Informationssicherheit, Transaktionsprüfung und -berichte, zentralisierte Richtlinien und Anwendungsverknüpfbarkeit.
  • Elektronischer Handel („eCommerce"), insbesondere zwischen Unternehmen („B2B"), aber auch zwischen Unternehmen und Kunden („B2C"), ist ein schnell wachsender Markt, auf dem Käufer und Verkäufer über das Internet, einem weltweiten Netzwerk von verknüpften Computersystemen, anstatt über traditionelle Mittel wie Post, Telefon und persönliches Zusammenkommen kommunizieren. Verkäufer werben für ihre Produkte und Dienste mit digitalen Broschüren und Katalogen, die über eine Internetverbindung, durch Seiten auf dem World Wide Web oder über elektronische Märkte, die in Waren und Diensten eines bestimmten Marktsektors handeln, betrachtet oder heruntergeladen werden können. Käufer können Lieferanten finden, Waren auswählen, Angebote einholen, Bestellungen aufgeben und verfolgen und sogar Zahlungen vollkommen elektronisch und jederzeit vornehmen. eCommerce verspricht erhöhte Flexibilität, Auswahl und Effizienz zu drastisch reduzierten Beschaffungskosten.
  • Es gibt zwei universell akzeptierte Mittel, über die Benutzer mit dem Internet Verbindung aufnehmen können. Das erste ist der „Webbrowser", der es Benutzern gestattet, Seiten auf dem World Wide Web durch Zugreifen auf einzelne Websites zu betrachten, deren Adressen gewöhnlich weit verbreitet mit traditionellen Mitteln veröffentlicht werden, oder auf die auf einer andere Website verwiesen wird. Der am weitesten verbreitete Webbrowser ist der „Internet Explorer" von Microsoft.
  • Das zweite Mittel zur Verbindungsaufnahme ist die Verwendung eines Electronic-Mail-Programms, mit dem der Benutzer eine Nachricht verfasst, Email genannt, die dann elektronisch über das Internet zur Adresse des beabsichtigten Empfängers geleitet wird. Gut bekannte Electronic-Mail-Programme sind z. B. „Lotus Notes" von IBM und „Gutlook" von Microsoft.
  • In einem typischen eCommerce-Szenario könnte ein Käufer ein bestimmtes Produkt zusammen mit Preis- und Lieferinformationen auf der Website des Verkäufers identifizieren. Er könnte dann einen Auftrag erteilen, entweder durch Ausfüllen eines elektronischen Auftragsformulars auf der Website oder durch Senden einer Email direkt zum Verkäufer. Der Auftrag würde dann typischerweise eine Zahlungsverpflichtung beinhalten, möglicherweise in Form von Kreditkartendetails oder mit einem anderen elektronischen Zahlungsmittel. Der Verkäufer würde dann typischerweise eine Email zum Bestätigen der Annahme des Auftrags zurücksenden.
  • Webbrowser arbeiten gemäß anerkannten Normen, insbesondere dem Hypertext Transfer Protocol („HTTP"), das im Internet-Standarddokument RFC2616 umfassend beschrieben ist. Electronic-Mail-Programme arbeiten gemäß anerkannten Normen, insbesondere dem Simple Mail Transfer Protocol das im Internet-Standarddokument RFC0821 umfassend beschrieben ist, und dem Multipurpose Internet Mail Extensions („MIME"), das im Internet-Standarddokument RFC2045-2049 umfassend beschrieben ist.
  • eCommerce bietet zwar enorme Vorteile, aber seine Praxis wirft auch viele neue Fragen auf, die angegangen werden müssen, um seine dauerhafte Nutzung zu gewährleisten, besonders dann, wenn traditionelle Methoden irgendwann ersetzt werden sollen. Eine der zentralen Fragen ist Sicherheit.
  • Das Internet ist ein offenes Kommunikationsnetzwerk, das definitionsgemäß unsicher ist, da es von jedermann benutzt werden kann. Mittel zum Sichern empfindlicher Informationen, die über das Internet ausgetauscht werden sollen (z. B. in einer eCommerce-Transaktion), kamen mit der Ankunft sicherer Übertragungsprotokolle und Messaging. Sichere Punkt-zu-Punkt-Übertragungsprotokolle, wie sie beispielsweise zwischen einem Webserver und einem Webbrowser benutzt werden, beinhalten die ,Secure Socket Lager' („SSL"), die von Netscape Communications definiert wird, und ihren Nachfolger ,Transport Lager Security' („TLS"), die im Internet-Standarddokument RFC2246 definiert ist. Sichere Email-Nachrichtenstandards sind z. B., Secure Multipurpose Internet Mail Extensions' („S/MIME"), im Internet-Standarddokument RFC2633 umfassend beschrieben, und „Pretty Good Privacy", ein von Philip Zimmerman entwickeltes sicheres Public-DomainMessaging-System.
  • Um den Zugang zu Informationen auf mit dem Internet verbundenen Servern zu kontrollieren, wurde weithin ein System von Benutzernamen und Passwörtern benutzt. So kann beispielsweise der Zugang zu Rabattpreislisten auf einem bestimmten Webserver auf Handelsbenutzer beschränkt sein, denen zuvor ein Benutzername und ein Passwort zum Zugreifen gegeben wurde. Ebenso benutzen Online-Informationsdienste typischerweise häufig Benutzernamen und Passwörter zum Beschränken des Zugangs auf Personen, die für den Dienst bezahlt haben. Indem jedem Benutzer ein eindeutiger Benutzername und ein änderbares Passwort gegeben werden, kann der Dienst gewährleisten, dass nur zahlende Abonnenten auf das System zugreifen können, und kann den Zugriff auf die von dem Dienst gespeicherten persönlichen Daten durch Andere verhindern.
  • In eCommerce-Anwendungen ist ein bedeutendes Problem die Frage von Identität und Vertrauen. Wenn ein Lieferant einen Auftrag über das Internet erhält, dann ist es vollkommen möglich, ja sogar wahrscheinlich, dass er keinerlei Vorkenntnisse über den Kunden hat. Der Lieferant muss feststellen, ob der Kunde a) der ist, für den er sich ausgibt, mit anderen Worten, dass er sich nicht als jemand anderes ausgibt, und dass er b) vertrauenswürdig ist und schließlich für die zu liefernden Waren oder Dienste bezahlen kann. Diese Fragen wurden im B2C-Markt vornehmlich durch die Verwendung von Kreditkarten gelöst. Der Kunde gibt seine Kreditkartennummer und Adresse mit dem Auftrag an, die der Lieferant dann mit dem Kreditkartenunternehmen verifiziert und eine Autorisierung für den Betrag erhält. Der gesamte Vorgang läuft typischerweise online ohne menschlichen Eingriff ab. Das Verfahren ist weitgehend dort wirksam, wo ein Lieferant Waren zur Adresse des Karteninhabers versendet, da ein potentieller Dieb nicht nur die Details des Karteninhabers stehlen, sondern auch die Lieferung der Waren abfangen müsste. Es ist weitaus weniger wirksam im Falle von Diensten, die keine physische Lieferung beinhalten.
  • Es ist also klar, dass die Benutzung von Kreditkarten in eCommerce zwar weit verbreitet, aber auf Transaktionen im kleinen Umfang beschränkt ist, potentiell mit Beträgen von beispielsweise bis $10.000. Für über diese Beträge hinaus gehende Transaktionen (deren Gesamtgeldwert den unterhalb dieses Betrags weit übersteigen), muss eine beidseitig vertrauenswürdige Drittpartei zum Feststellen von Identität und Vertrauen in Anspruch genommen werden.
  • Eine zentrale Rolle bei der Feststellung der Identität spielen digitale Zertifikate. Dem Kunden kann von einer vertrauenswürdigen Drittpartei ein digitales Zertifikat gegeben werden, das dann zum elektronischen ,Signieren' von Kommunikationen verwendet wird. Nach dem Erhalt einer signierten Nachricht kann der Empfänger (in diesem Fall der Lieferant) positiv a) die Identität des Senders, b) die Tatsache, dass die Nachricht nicht verändert wurde, und c) die Tatsache, dass der Sender nachfolgend nicht bestreitet, dass er die Nachricht gesendet hat, feststellen. Anerkannte Normen für digitale Zertifikate sind im ITU-Dokument X.509, ihre Verwendung in Internet-Kommunikationen in den Internet-Standarddokumenten RFC2312, RFC2459, RFC2510, RFC2511, RFC2527, RFC2560, RFC2585 und RFC2632 beschrieben.
  • Es können gebührenpflichtige Drittparteidienste wie z. B. die von Valicert Inc. bereitgestellten zum Überprüfen benutzt werden, dass ein digitales Zertifikat nicht widerrufen wurde, z. B. wenn das Zertifikat auf irgendeine Weise kompromittiert wurde.
  • Wenn die Echtheit von Nachrichten festgestellt ist, kann der Lieferant eine andere Drittpartei mit der Feststellung der Vertrauenswürdigkeit beauftragen, oder dieselbe Drittpartei kann zum Feststellen von Echtheit und Vertauenswürdigkeit benutzt werden. So stellt z. B. „Identrus", ein Konsortium der weltweit größten Banken, ein System bereit, so dass ein Lieferant, der eine mit einem von Identrus ausgegebenen digitalen Zertifikat signierte Nachricht erhält, unabhängig prüfen kann, ob der Kunde ein gültiger Kontoinhaber mit gutem Ruf bei einer anerkannten Bank ist. Schließlich muss das System erweitert werden, so dass die Bank zusätzlich die Transaktion und somit die Bezahlung des Lieferanten garantiert. Man wird verstehen, dass die Begriffe „Kunde" und „Lieferant" für beliebige zwei Parteien einer Internet-Kommunikation gelten können.
  • Es ist ersichtlich, dass geeignete Kombinationen der beschriebenen Systeme ein sicheres Fundament für den Gebrauch des Internets und der darüber verfügbaren Dienste und Funktionen bietet. Wir haben jedoch erkannt, dass es in der Praxis von eCommerce nur mit diesen Systemen eine Reihe von Problemen gibt, die nachfolgend erörtert werden.
  • Bei den oben erwähnten sicheren Übertragungsprotokollen und beim Messaging werden Daten gewöhnlich vor der Übertragung verschlüsselt und vor dem Betrachten durch den beabsichtigten Empfänger entschlüsselt. So sind sie, falls die Daten bei der Übertragung abgefangen werden sollten, vor der Einsicht durch unbefugte Drittparteien sicher, es sei denn, dass diese den geheimen Verschlüsselungskey des Verschlüsselungsalgorithmus kennen oder ermitteln können.
  • Das Ver- und Entschlüsseln von Daten an jedem Ende einer sicheren Verbindung oder Nachricht erfordert erhebliche Verarbeitungsleistung. Zusätzlich müssen die sendende und die empfangende Partei im Besitz desselben Verschlüsselungskey des Verschlüsselungsalgorithmus, mit derselben kryptografischen Stärke, sein, damit das System erfolgreich arbeiten kann. Dies stellt häufig ein Problem dar, beispielsweise dann, wenn Vorschriften für den Import oder Export von Daten in ein oder aus einem Computersystem die Verwendung von stärkeren Algorithmen verbieten, so dass die Verbindung oder Nachricht mit einer geringeren kryptografischen Stärke verschlüsselt werden muss oder eine sichere Kommunikation insgesamt verhindert wird. Demzufolge werden sichere(s) Verbindungen und Messaging häufig nur dort verwendet, wo dies notwendig ist.
  • Bei Kommunikationen über das World Wide Web wird die Forderung zum Sichern von Übertragungen durch den Webserver ermittelt und initiiert. Wenn beispielsweise die Übertragung eines Auftragsformulars zum Ausfüllen durch den Kunden durch den Server bevorsteht, dann kann dieser eine sichere Verbindung herstellen, so dass die Auftragsinformationen vor der Rücksendung zum Server verschlüsselt werden. Ebenso kann der Server nach der Erledigung des Auftrags die sichere Verbindung beenden und zur normalen unverschlüsselten Kommunikation zurückkehren.
  • Typischerweise ist die einzige Anzeige, die der Benutzer hat, dass eine Verbindung gesichert ist, ein im Browser-Fenster erscheinendes Icon (gewöhnlich in Form eines Vorhängeschlosses). Wenn das Icon erscheint, kann der Benutzer den Browser gewöhnlich abfragen, um die Stärke des verwendeten Verschlüsselungsalgorithmus festzustellen, und kann entscheiden, ob er eintritt oder nicht, und kann dann empfindliche Informationen wie z. B. Kreditkarten- und Adressdetails senden.
  • In der Praxis prüfen jedoch Benutzer häufig nicht, ob die Verbindung sicher ist, und noch viel weniger, ob sie die geeignete kryptografische Stärke hat, um die übertragenen Informationen zu schützen. Zur Lösung dieses Problems bieten Email-Anwendungen wie z. B. „Gutlook" von Microsoft die Fähigkeit zum vorgabemäßigen Verschlüsseln aller Emails.
  • Durch die weit verbreitete Verwendung von Benutzernamen und Passwörtern ist ein Managementproblem für viele Internet-Benutzer aufgrund der riesigen Zahl entstanden, die man sich merken muss, besonders dann, wenn gute Sicherheitspraktiken ein häufiges Ändern von Passwörtern verlangen. Ebenso müssen Benutzer häufig viele verschiedene Benutzernamen benutzen, da jemand anders bereits auf einer bestimmten Site ihren ,Favorit' benutzt hat. Möglichkeiten zum Merken und automatischen Ausfüllen von Benutzernamen- und Passwortfeldern bei nachfolgenden Gelegenheiten werden in Webbrowsern wie z. B. dem „Internet Explorer" von Microsoft und durch zusätzliche ,Helper'-Dienstprogramme wie „Gator" von Gator.com bereitgestellt. Diese Einrichtungen führen typischerweise eine Datei von Benutzernamen, Passwörtern und der Webseite, für die sie gelten. Diese Dateien werden verschlüsselt, um zu gewährleisten, dass nur der richtige Benutzer darauf zugreifen kann. Wenn solche Benutzernamen- und Passwortdateien verloren gehen oder unverfügbar werden, z. B. dann, wenn der autorisierte Benutzer den Verschlüsselungskey vergessen hat oder nicht mehr erreichbar ist, um ihn zu geben, oder wenn die Datei versehentlich oder betrügerisch verloren, zerstört oder verfälscht wurde, dann kann der Zugang zu Internet-Konten und -Diensten verloren gehen und jede Site muss individuell besucht werden, um den/das notwendige(n) Benutzernamen und/oder Passwort zu ersetzen oder zurückzugewinnen. Dies kann ein sehr kostspieliges Problem für Firmen im Hinblick auf verlorenen Zugang und Administrationszeit bedeuten. Zudem sind solche gemerkten Benutzernamen und Passwörter nur für die Verwendung auf der Maschine verfügbar, auf der sie ursprünglich benutzt wurden. Wenn der Benutzer zu einer anderen Maschine geht oder mehrere Maschinen benutzt, dann sind die gespeicherten Benutzernamen und Passwörter für ihn von diesen anderen Maschinen aus nicht zugängig.
  • Alle Unternehmen, und viele individuelle Benutzer, sind gesetzlich verpflichtet, genaue Aufzeichnungen über die von ihnen unternommenen Transaktionen zu führen, aber für eCommerce-Transaktionen kann sich dies als schwierig erweisen. Unternehmen müssen Aufzeichnungen für Prüfzwecke führen, z. B. um im Falle eines Disputs die Bedingungen nachzuweisen, unter denen Waren bestellt wurden. Solche Aufzeichnungen lassen sich in einer eCommerce-Umgebung weitaus schwerer führen, die es erfordert, dass der Benutzer beispielsweise Kopien von per Email gesendeten Aufträgen aufbewahrt oder die Webseitenquittung von einem Website-Kauf ausdruckt. Für den Benutzer ist dies arbeitsaufwändig und es gibt keine Garantie, dass solche erzeugten Aufzeichnungen vollständig oder zuverlässig sind.
  • Eine automatisierte Lösung für das Führen von Aufzeichnungen von eCommerce-Transaktionen bietet die „Max Manager" Anwendung von Max Manager. Max Manager erfasst Quittungsseiten auf bekannten Websites, extrahiert Transaktionsinformationen von diesen Quittungsseiten und speichert dann lokal sowohl die Quittungsseite als auch die extrahierten Transaktionsinformationen auf der Maschine, auf der die Anwendung läuft. Um jedoch arbeiten zu können, müssen dem Max Manager die genaue Adresse und das genaue Layout der Quittungsseite gegeben werden. Max Manager stellt fest, dass eine eCommerce-Transaktion stattgefunden hat, indem er entweder die Adresse der Empfangsseite erfasst oder die gerade mit einem Browser betrachtete Seite mit dem Layout der Quittungsseite vergleicht, mit der er gefüttert wurde. Wenn er eine Quittungsseite identifiziert hat, dann werden die relevanten Transaktionsdetails von der Quittungsseite mit Hilfe des bekannten Layout der Seite als Schablone für Vergleichszwecke extrahiert. Ein erheblicher Nachteil mit Max Manager ist, dass er nur zum Extrahieren von Daten von den Seiten verwendet werden kann, für die er mit Details gefüttert wurde. Dazu kommt, wenn sich das Layout der Quittungsseite ändert, dann kann Max Manager Daten von der Seite erst dann sinnvoll extrahieren, wenn er mit einer neuen Schablone für das geänderte Layout gefüttert wird. Da sich Websites häufig ändern, muss Max Manager ständig auf dem neuesten Stand gehalten werden, um solche Änderungen zu berücksichtigen. Dies ist im großen Maßstab unpraktisch und führt unweigerlich dazu, dass Transaktionen ausgelassen oder, was noch schlimmer ist, inkorrekt gemeldet werden.
  • Probleme entstehen auch durch die Tatsache, dass Computer-Terminals verteilt sind, was häufig bedeutet, dass sich Terminals und Benutzer an unterschiedlichen Orten befinden. In Multiuser-Umgebungen können Benutzermaschinen physisch miteinander verbunden sein, z. B. über ein Ortsnetz („LAN"), das als Gateway zur Verbindung mit dem Internet dient. Sie können auch mit lokalen Servern wie z. B. dem „Exchange Server" von Microsoft verbunden sein, der als zentrale Sammel- und Verteilungsstelle für Email-Nachrichten dient, und mit dem „Proxy Server” von Microsoft, der sowohl als Cache zum Verbessern der Leistung häufig besuchter Websites als auch als Filter zum Verhüten des Zugriffs auf bestimmte Websites dient, die möglicherweise als unerwünscht designiert wurden. Was den Austausch von Informationen betrifft, ausgenommen dann, wenn eine Nachricht zwischen zwei lokalen Benutzern gesendet wird, so arbeitet jedoch jeder Benutzer völlig isoliert von anderen am selben Ort. Dies bedeutet ein ernsthaftes Managementproblem für Firmen und andere Organisationen, die kein Mittel haben, um von zentraler Stelle aus Mitarbeiteraktivitäten zu kontrollieren, und sie können nicht von signifikanten Kosteneinsparungen profitieren, die durch die gemeinsame Nutzung von Informationen erzielt werden können. So könnten z. B. zwei Benutzer in einer Organisation unabhängig Email-Nachrichten empfangen, die vom selben Sender digital signiert wurden. Beide Empfänger müssen das digitale Zertifikat separat validieren, so dass zwei Validierungsgebühren anfallen, von denen wenigstens eine unnötig wäre.
  • Ein System und ein Verfahren zum Erzeugen, Bearbeiten und Verteilen von Regeln zum Verarbeiten von elektronischen Nachrichten ist aus dem US-Patent Nr, US 5,917,489 bekannt. Solche Regeln werden von Workstationbenutzern als Hilfe beim Löschen, Ablegen und Antworten auf ihre Nachrichten aufgestellt.
  • Die US 5,947,149 offenbart ein Steuersystem für Netzwerkressourcen-Sicherheitsdienste mit einem Event-Manager, der das Niveau an kryptografischer Komplexität ändert.
  • Die vorliegende Erfindung stellt zusätzliche Funktionalität für die oben erwähnten Systeme bereit, um deren inhärente Probleme abzumildern und ein einzelnes integriertes Informationsaustauschsystem bereitzustellen.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die Erfindung ist in den Hauptansprüchen dargelegt, auf die nunmehr Bezug genommen werden sollte. Vorteilhafte Merkmale der Erfindung sind in den Nebenansprüchen dargelegt.
  • Das Informationsmanagementsystem bietet viele Vorteile in der eCommerce-Umgebung für online handelnde Unternehmen, die davon profitieren können, dass sie die von ihrem Personal durchgeführten Transaktionen gemäß ihren in den Richtliniendaten codierten Anweisungen regulieren, Aufzeichnungen von Passwörtern und online getätigten Geschäften automatisch führen, die Bezahlung für unnötige Überprüfungen der Gültigkeit von digitalen Zertifikaten vermeiden und eine allzeit sichere Übertragung von Daten durch ihr Personal gewährleisten können.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Die bevorzugte Ausgestaltung der Erfindung wird nachfolgend ausführlicher beispielhaft und mit Bezug auf die Begleitzeichnungen beschrieben. Dabei zeigt:
  • 1 eine schematische Darstellung der derzeitigen Anordnung von Systemen und Betriebsmitteln, aus denen sich das Internet zusammensetzt, gemäß dem Stand der Technik;
  • 2 eine schematische Darstellung der bevorzugten Ausgestaltung der Erfindung, in einer Firmenumgebung ausgeführt;
  • 3 eine schematische Darstellung des Betriebs eines Webbrowsers gemäß der bevorzugten Ausgestaltung der Erfindung;
  • 4 eine Darstellung eines von einem Webbrowser erzeugten typischen Eingabefensters;
  • 5 eine schematische Darstellung des Betriebs eines Email-Client gemäß der bevorzugten Ausgestaltung der Erfindung;
  • 6 ein den Betrieb eines Einsteckmoduls illustrierendes Fließschema gemäß einer bevorzugten Ausgestaltung der Erfindung zum Erfassen von Benutzernamen- und Passwortwerten, die von einem Benutzer zu einer fernen Website übertragen werden;
  • 7 eine Darstellung von beispielhaften Richtliniendaten, die Kontrollbedingungen zum Aufzeichnen von Daten vorgeben;
  • 8 ein den Betrieb eines Einsteckmoduls illustrierendes Fließschema gemäß einer bevorzugten Ausgestaltung der Erfindung zum Erkennen von in Daten enthaltenen Kreditkartennummern, die zu oder von einem Webserver oder einem Email-Client übertragen wurden;
  • 9 ein den Betrieb eines Einsteckmoduls illustrierendes Fließschema gemäß einer bevorzugten Ausgestaltung der Erfindung zum Feststellen der Gültigkeit eines von einem Benutzer empfangenen digitalen Zertifikats;
  • 10 eine Illustration von beispielhaften Richtliniendaten zum Ermitteln, ob ein digitales Zertifikat verifiziert werden soll oder nicht;
  • 11 ein Fließschema, das illustriert, wie die in 10 gezeigten beispielhaften Richtliniendaten benutzt werden, um zu ermitteln, ob eine Verifizierung für ein digitales Zertifikat nötig ist oder nicht;
  • 12 ein den Betrieb eines Einsteckmoduls illustrierendes Fließschema gemäß einer bevorzugten Ausgestaltung der Erfindung zum Identifizieren von Übertragungen von einem Benutzer oder zu einem Benutzer, die einen Teil einer eCommerce-Transaktion beinhalten;
  • 13 eine Illustration von beispielhaften Richtliniendaten, die mit dem in 12 illustrierten Verfahren benutzt werden sollen, um eine Transaktion zu identifizieren;
  • 14 ein den Betrieb eines Einsteckmoduls illustrierendes Fließschema gemäß einer bevorzugten Ausgestaltung der Erfindung zum Aufzeichnen von Übertragungen, die als einen Teil einer einzelnen Transaktion umfassend identifiziert wurden, um einen Datensatz der Transaktion zu bilden;
  • 15 ein den Betrieb eines Einsteckmoduls illustrierendes Fließschema gemäß einer bevorzugten Ausgestaltung der Erfindung zum Zulassen oder Ablehnen von identifizierten Transaktionen auf der Basis einer vorbestimmten Richtlinieneinstellung; und
  • 16 eine Illustration von beispielhaften Richtliniendaten zum Ermitteln, ob eine identifizierte Transaktion eine Zulassung erfordert, und zum Identifizieren eines geeigneten Billigers (Approver);
  • 17 ein den Betrieb eines Einsteckmoduls illustrierendes Fließschema gemäß einer bevorzugten Ausgestaltung der Erfindung zum Ermitteln eines geeigneten Verschlüsselungsniveaus für eine Übertragung, und um es zuzulassen, dass die Übertragung nur dann erfolgt, wenn dieses Niveau gegeben ist;
  • 18 eine Illustration von beispielhaften Richtliniendaten, die die benötigte Verschlüsselungsstärke für verschiedene Datentypen vorgibt;
  • 19 eine Illustration von beispielhaften Richtliniendaten zum Steuern des Umleitens von abgehenden Nachrichten;
  • 20 ein den Betrieb eines Einsteckmoduls illustrierendes Fließschema gemäß einer bevorzugten Ausgestaltung der Erfindung zum Umleiten von abgehenden Nachrichten zu einer Drittpartei zum Prüfen vor der Übertragung anhand der in 19 gezeigten Richtliniendaten;
  • 21 ein den Betrieb eines Einsteckmoduls illustrierendes Fließschema gemäß einer bevorzugten Ausgestaltung der Erfindung zum Steuern des Heraufladens von Informationen auf eine firmenexterne Website anhand der in 19 gezeigten Richtliniendaten;
  • 22 eine Illustration von beispielhaften Richtliniendaten zum Steuern des Weiterleitens von Nachrichten zu firmeninternen oder -externen Empfängern;
  • 23 ein den Betrieb eines Einsteckmoduls illustrierendes Fließschema gemäß einer bevorzugten Ausgestaltung der Erfindung unter Anwendung der in 22 gezeigten Richtliniendaten;
  • 24 eine Illustration von beispielhaften Richtliniendaten zum Steuern, ob eine abgehende Nachricht digital signiert werden soll oder nicht; und
  • 25 ein den Betrieb eines Einsteckmoduls illustrierendes Fließschema gemäß der bevorzugten Ausgestaltung der Erfindung unter Anwendung der in 24 gezeigten Richtliniendaten.
  • BESCHREIBUNG DER BEVORZUGTEN AUSGESTALTUNG
  • Das bevorzugte System bietet Benutzern des Internets eine automatische Möglichkeit zum Verwalten des Flusses von Informationen auf einem Computersystem. Es stellt Einrichtungen zum Verwalten des Sicherheitsniveaus, auf dem Übertragungen stattfinden, Einrichtungen zum Aufzeichnen von Online-Transaktionen und zum Verweisen von vor der Ausführung stehenden Transaktionen an Drittparteien zur Billigung sowie Mittel zum Stoppen von Transaktionen bereit, wenn die Billigung verweigert wird; es bietet auch Einrichtungen zum Extrahieren und Aufzeichnen von relevanten Daten von empfangenen oder kurz vor dem Absenden stehenden Übertragungen und zum intelligenten Verwalten der Übertragung von Emails bereit.
  • Das bevorzugte System bietet Lösungen für viele der Probleme, mit denen über das Internet handelnde eCommerce-Unternehmen konfrontiert werden; demzufolge betrifft die nachfolgende beispielhafte Erörterung vornehmlich die Implementation und Verwendung des Systems durch ein Unternehmen einer sinnvollen Größe, das wenigstens einige seiner Geschäfte über das Internet tätigt. Man wird verstehen, dass jedoch jedermann, inklusive Unternehmen jeder Größe oder Art und Privatpersonen, die das Internet benutzen, von den von dem bevorzugten System bereitgestellten Funktionen profitieren können.
  • Die Funktionalität des bevorzugten Systems wird über Code-Module implementiert, die in den Webbrowser oder den Email-Client ,eingesteckt' werden. Diese ,Einsteck'-Module können zum Steuern und Verändern des Verhaltens des Webbrowsers oder Email-Clients beim Betrieb verwendet werden.
  • Viele existierende Webbrowser und Email-Clients sind möglicherweise bereits mit solchen Einsteckmodulen integriert. Im Falle des Internet Explorer von Microsoft ist das Einsteckmodul als ,Browser Helper' bekannt und ist in dem Dokument „Browser Helper Objects: The Browser the Way You Want It" von Dino Esposito umfassend beschrieben, herausgegeben von der Microsoft Corporation im Januar 1999. Im Falle von Microsoft Gutlook und Exchange-Email-Clients ist das Einsteckmodul als eine ,Extension' bekannt und ist ausführlicher im Dokument „Microsoft Gutlook and Exchange Client Extensions" von Sharon Lloyd beschrieben, herausgegeben von der Microsoft Corporation im März 1998. Die Verwendung der Einsteckmodule ,Browser Helper Object' und ,Extension' im bevorzugten System wird nachfolgend ausführlicher beschrieben.
  • Die Verwendung von Browser- oder Email-Client-Einsteckmodulen zum Ausführen der Funktionalität des bevorzugten Systems hat den zusätzlichen Vorteil, dass, da eine Verschlüsselung von Nachrichteninhalt gewöhnlich durch den Browser oder Email-Client selbst erfolgt, eine Untersuchung des Übertragungsinhalts, um z. B. Passwortinformationen zu extrahieren oder das gewünschte Verschlüsselungsniveau zu bestimmen, stattfinden kann, bevor der Inhalt übertragungsbereit verschlüsselt wurde, oder sogar nachdem er empfangen und entschlüsselt wurde.
  • 1 zeigt die Beziehung zwischen Diensteanbietern, typischerweise Unternehmen, die Waren und Dienste über das Internet 10 verkaufen, und Benutzern, die solche Waren und Dienste kaufen möchten. Mit Webbrowsern 22, 24 und 26 ausgestattete Benutzer können sich über das Internet zuschalten und Webseiteninformationen von Webservern 14 und 18 abrufen. Alternativ können Benutzer mit Email-Anwendungen 20, 30 und 32 Email-Nachrichten mit abc.com und xyz.com über Email-Server 12 und 16 senden und empfangen.
  • In einem Firmenkontext wie z. B. dem, der in der rechten unteren Ecke von 1 illustriert ist, sind Webbrowser 24 und 26 eines Firmenbenutzers über einen Proxy-Server 28 mit dem Internet verbunden. Der Proxy-Server 28 dient zum Cachen von Webseiten und zum Steuern des Zugriffs -auf Websites. Ebenso hat das Unternehmen Email-Clients 30 und 32, die mit dem Internet über den Email-Server 34 verbunden sind, der als eine zentrale Sammelstelle für am Unternehmen ankommende Emails dient und die Verteilung der Emails zu einzelnen Benutzern steuert. Man wird verstehen, dass 1 zwar abc.com und xyz.com als Verkäufer beschreibt, aber ein Unternehmen kann auch sowohl Käufer als auch Verkäufer sein, und die Käufer abc.com und xyz.com würden für die Zwecke dieser Beschreibung als Unternehmensbenutzer beschrieben.
  • Im Falle von Emails, die durch eine persönliche Email-Anwendung 20 gesendet und empfangen werden, ist zu bemerken, dass die Mail typischerweise von einem fernen Email-Server gesammelt und verteilt wird, der vom Anbieter des Internet-Verbindungsdienstes bereitgestellt wird, bei dem der persönliche Benutzer abonniert ist.
  • Während viele der Merkmale und Funktionen des vorliegenden Systems erhebliche Vorteile für einen individuellen Benutzer bieten, bietet das System den maximalen Vorteil, wenn es in einer Mehrbenutzer-Umgebung arbeitet, bei der Transaktionsinformationen von vielen Benutzern gesammelt werden. 2 zeigt ein schematisches Diagramm der bevorzugten Konfiguration des Systems in einer Mehrbenutzer-Umgebung. Das bevorzugte System umfasst einen zentralen Managementserver 40, der mit einer Datenbank 42 und Operatorkonsolen 44 verbunden ist. Der zentrale Managementserver 40 ist auch mit Back Office Application Einsteckmodulen verbunden, die Anwendungsschnittstellen 50, 52 und eine offene Anwendungsprogrammschnittstelle 54 umfassen, sowie mit Gateway-Komponenten 60, 62 und 64. In der Figur ist die Gateway-Komponente 62 als mit Benutzeranwendungseinsteckmodulen verbunden dargestellt, die sich auf einem oder mehreren Benutzermaschinen befinden, die die Einsteckmodule Internet Explorer 70, Netscape Navigator 72, Microsoft Gutlook 74 und Lotus Notes 76 umfassen. Diese Einsteckmodule bieten die Funktionalität des bevorzugten Systems in dem Hosting-Programm, in dem sie integriert sind. Es sind vier mögliche Hosting-Programme dargestellt, Internet Explorer, Netscape Navigator, Microsoft Gutlook und Lotus Notes, aber es kann auch jedes andere Programm mit der Fähigkeit benutzt werden, sich am Internet anzuschließen, vorausgesetzt, sein Verhalten kann zum Ausführen der Funktionalität des bevorzugten Systems modifiziert werden.
  • Der Anschluss an das Internet 10 erfolgt über die Benutzeranwendungseinsteckmodule und ihre jeweiligen Hosting-Programme.
  • Die Gateway-Komponenten 70, 72 und 74 sind fakultativ, werden aber bevorzugt, da sie eine Skalierung des gesamten Systems ermöglichen, wobei jedes Gateway Informationen speichert und weiterleitet und es gestattet, dass eine beliebige Anzahl von Benutzern zugeschaltet wird.
  • Informationen von den mehreren Anwendungseinsteckmodulen 70, 72, 74 und 76 für die verschiedenen Anwendungen auf mehreren Benutzermaschinen werden vom zentralen Managementserver 40 gesammelt und in einer assoziierten Datenbank 42 gespeichert.
  • Die Back Office Application Einsteckmodule 50, 52 und 54 ermöglichen eine Verbindung des Systems mit Drittpartei-Managementanwendungen wie z. B. Auftragsbearbeitungs- und Buchhaltungssystemen. So können Transaktionsinformationen von solchen Systemen automatisch eingegeben und verarbeitet werden.
  • Operatorkonsolen 44 werden für administrative Zwecke und insbesondere für die Zulassung von Transaktionen bereitgestellt. Während sie in 2 logisch als direkt mit dem zentralen Managementserver verbunden dargestellt sind, könnten solche Konsolen auf jeder vernetzten Maschine laufen. Wo ein Email- oder Webbrowser-Einsteckmodul ermittelt, dass eine bestimmte Transaktion eine Zulassung erfordert, wird eine Anforderung zum zentralen Managementserver gesendet und bis zur Zulassung durch einen autorisierten Operator in eine Warteschlange gesetzt.
  • Der Betrieb des Systems wird durch Richtliniendaten gesteuert, in denen die Vorschriften des Unternehmens in Bezug auf Sicherheit, Autorisierung und die Aktionen, die Benutzer ausführen dürfen, sowie Betriebsinformationen gespeichert sind. Die Richtliniendaten werden vorzugsweise in einer Richtliniendatei auf dem zentralen Managementserver für den Zugriff durch irgendeine der Operatorkonsolen 44, Back Office Application oder Benutzeranwendungs-Einsteckmodule gespeichert. Der Systemadministrator oder Netzwerk-Supervisor kann eine oder mehrere Richtlinien oder Einstellungen der Richtliniendatei definieren und kann einzelne Benutzer oder Benutzergruppen unterschiedlichen Richtlinien zuordnen und so die Interaktionsfähigkeit eines Benutzers oder sogar die einer Workstation mit dem Internet steuern, ohne Notwendigkeit für ein direktes Einstellen von Parametern und Controls auf jeder Benutzermaschine. Ein Benutzer in der Buchhaltungsabteilung eines Unternehmens kann beispielsweise einer „Buchhaltungsrichtlinie" zugeordnet werden; jede nachfolgende Änderung an dieser Richtlinie führt dann automatisch zu einer Änderung der Fähigkeiten aller dieser Richtlinie zugeordneten Benutzer.
  • Es wird bevorzugt, dass die Fähigkeit zum Bearbeiten oder Festlegen der Richtliniendaten auf den Netzwerk-Supervisor oder eine oder mehrere andere autorisierte Personen beschränkt wird. Dies kann dadurch erzielt werden, dass eine oder mehrere Supervisor-Workstations im Netzwerk für einen Zugriff zum Bearbeiten der Richtliniendaten bestimmt werden, wie z. B. Operatorkonsolen 44.
  • Die Richtlinie hat vorzugsweise eine baumartige Struktur, so dass Einstellungen zwangsweise abwärts zu individuellen Richtlinienknoten des Baums gelangen und globale Änderungen rasch vorgenommen werden können, z. B. dann, wenn der Geschäftsführer (CEO) wünscht, dass alle Käufe seine Zulassung erfordern, wenn der Bargeldfluss des Unternehmens zu einem Problem wird. Ein solches richtliniengestütztes System reduziert stark die Latenz, die sowohl in traditionellen Einkaufssystemen als auch in derzeitigen eCommerce-Kaufumgebungen inhärent sind.
  • Jeder Benutzer des Netzwerks hat seine eigene Darstellung von Richtliniendaten. Vorzugsweise werden nur die Zweige und Blätter der Richtlinie jedes Benutzers gespeichert, die sich von einer Master-Netzwerkrichtlinie unterscheiden, da dies Speicherplatz spart. Die Richtliniendaten werden zwar vorzugsweise in Dateiform auf dem zentralen Managementserver gespeichert, aber es ist nicht beabsichtigt, dass eine Speicherung der Richtliniendaten nur auf die Dateiform beschränkt ist. Im bevorzugten System kann jede andere Repräsentation oder Codierung von Richtlinieneinstellungen zum Einsatz kommen.
  • Die Implementation des Systems in einem Webbrowser oder in einem Email-Client wird nachfolgend ausführlicher beschrieben.
  • Benutzung des bevorzugten Systems in einem Webbrowser 3 zeigt den vereinfachten Betrieb eines Webbrowsers. Der Webbrowser wird in Schritt S100 als Reaktion auf eine Startanforderung entweder vom Benutzer oder automatisch von der Startdatei des Benutzercomputers gestartet. Die Startdatei enthält Befehle zum automatischen Abarbeiten bestimmter Programme beim Booten des Computers. Der Webbrowser fordert nach dem Start typischerweise eine ,Homepage' an, die vorgabemäßige Ansichtswebseite, gemäß einer vorbestimmten Einstellung. Dies ist in Schritt S102 dargestellt.
  • Die Anforderung wird zum richtigen Webserver 90 gesendet, dessen genaue Internet-Adresse gewöhnlich durch Bereichsnamensdienste bestimmt wird; der Webserver 90 antwortet mit den die Webseite definierenden geeigneten Daten. Dieser Vorgang wird jeweils als Schritte S104 und S106 repräsentiert, was in Schritt S108 resultiert.
  • Die die Webseite definierenden Daten bestehen aus dem HTML-Skript und anderen möglichen Datentypen wie XML oder ActiveX und Javascript, das ablauffähige Programme codiert. Der Browser interpretiert diese Daten, zeigt sie an und/oder arbeitet sie ab, je nachdem, was in Schritt S110 angemessen ist.
  • Der Browser wartet dann typischerweise auf eine Benutzereingabe in Schritt S112. Eine solche Eingabe kann das Ausfüllen von angezeigten Feldern, das Anklicken einer Hyperlink oder das Eingeben der URL-Adresse einer neuen Webseite beinhalten. Schließlich führen solche Aktionen dazu, dass in Schritt S114 und Schritt S116 eine weitere Anforderung zum Webserver 90 gesendet wird. Die Anforderung kann einfach eine andere Webseitenadresse sein oder sie kann zusätzliche Daten wie z. B. die enthalten, die der Benutzer in die angezeigten Felder eingetastet hat.
  • 4 zeigt ein Beispiel für eine Webseitenanzeige, in der dem Benutzer eine GUI dargeboten wird, um Benutzernamen und Email-Adresse zu empfangen. Wie aus 4 ersichtlich ist, hat der Benutzer bereits seinen Namen als ,Fred Smith' in das vorgesehene Namensanforderungsfeld und seine Email-Adresse als ,fsmith@xyz.com' in das Email-Adressfeld eingegeben.
  • Wenn der Benutzer die ,Submit'-Schaltfläche im Anforderungsfenster anklickt, dann werden die eingegebenen Benutzerdetails in den zum Webserver 90 gesendeten Befehl einbezogen. Ein solcher Befehl könnte wie folgt lauten:
    http:_//www.sample.com/_sample2.htm?
    UserID=Fred
    +Smith&email=fsmith@xyz.com&submit=submit
  • Aus dem Obigen ist ersichtlich, dass der Benutzername in den Befehl als Wert einer Variablen namens ,UserID' integriert wird, und seine Email-Adresse wird als der Wert einer Variable namens ,Email' integriert.
  • Der Befehl wird in Schritt S114 zusammengesetzt und in Schritt S116 zum Webserver 90 gesendet. In Schritt S116 können Benutzername und Email-Adressinformationen z. B. zum Senden von Produktinformationen zum Benutzer per Email oder zwecks Zugang zu anderen Webseiten benutzt werden.
  • Das von der bevorzugten Ausgestaltung der Erfindung bereitgestellte Einsteckmodul in Form eines Browser Helper Object (BHO) bietet zusätzliche Funktionalität zur Erweiterung der des standardmäßigen Webbrowsers. Das BHO wird zum Reagieren auf eine Reihe von signifikanten Events implementiert, die beim Arbeiten mit dem Webbrowser auftreten und die vom Benutzer zwecks Interaktion mit verschiedenen Websites und Seiten angewiesen wird.
  • Das BHO wird zum Überwachen von dem Webserver vom Browser submittierten Navigationsanforderungen und Daten und zum Identifizieren von für den Benutzer eindeutigen Daten implementiert. Dies kann einfach durch Absuchen des abgehenden Datenstroms nach vorbestimmten Wörtern oder Ausdrücken geschehen. In dem in 4 gezeigten obigen Fall kann nach zwei Variablendefinitionen ,UserID' und ,Email' gesucht werden und die darauf folgenden Daten können extrahiert und gespeichert werden. Alternativ kann das BHO nach dem ,?' Symbol suchen, das das Ende der verbundenen URL-Adresse und die Tatsache anzeigt, dass danach Daten folgen. Das BHO kann auch den von der Webseite, mit der es verbunden ist, empfangenen eingehenden Datenstrom überwachen.
  • Das BHO kann auch zum Überwachen des Betriebs des Webbrowsers selbst verwendet werden. während des Betriebs des Webbrowsers erzeugt dieser ,Events', um mitabhängigen Software-Modulen oder Objekten mitzuteilen, dass gerade etwas Signifikantes aufgetreten ist oder dass eine Aktion soeben beendet wurde. Der Name des Events ist gewöhnlich an sich beschreibend für das, was gerade aufgetreten ist; normalerweise sind auch zusätzliche Daten verfügbar, die das Event ausführlicher beschreiben. Das BHO wird zum Einfangen dieser Events und zum Treffen von Maßnahmen in Abhängigkeit davon implementiert.
  • Ein solches Event, für dessen Beantwortung das BHO implementiert wird, heißt ,BeforeNavigate2', das der Webbrowser startet, wenn der Benutzer anfordert, dass der Browser zu einer neuen Seite navigiert. Das Event wird ausgegeben und kann vom BHO erkannt werden, bevor die angeforderte Seite heruntergeladen wird, so dass das BHO jede geeignete Maßnahme ergreifen kann, bevor der Benutzer die Seite sieht. Eine solche Aktion könnte die Aufzeichnung der Seite und eventueller Daten sein, die als Reaktion auf diese Seite in einer Datenbank submittiert wurden. Eine andere solche Aktion könnte die Identifikation der URL-Adresse der angeforderten Seite von dem Event oder das Verhüten des Herunterladens der Seite sein.
  • Ein anderes Event, das das BHO einfängt, ist das ,DocumentComplete'-Event, das vom Webbrowser eingeleitet wird, wenn eine neue Seite vollständig von der Website in den Speicher heruntergeladen wurde. Die Seite wird in Form eines Document Object codiert, entsprechend dem Document Object Model (DOM) von Microsoft. Das DOM bietet umfassenden Zugang zu den die Seite umfassenden Daten, so dass das BHO für es interessante Datenelemente extrahieren kann. So kann das BHO beispielsweise Daten vom DOM anfordern, um zu ermitteln, ob die Seite Teil einer eCommerce-Transaktion bildet. Es kann dies durch Absuchen von Objekten im DOM nach Begriffen wie ,Quittung' oder ,Kontonummer' tun.
  • Das BHO kann das DOM auch zum Ermitteln der Feldnamen oder Feldtypen von Daten benutzen, die auf einer Webseite angefordert werden. Die vom Benutzer in solche Felder eingegebenen Daten können dann vom DOM extrahiert und gespeichert oder es kann darauf reagiert werden. Feldnamen sind typischerweise für das Gespeicherte beschreibend; Passwörter werden beispielsweise oft in einem Feld namens ,Passwort' gespeichert, daher kann auf einer Webseite danach gesucht werden. Nach Kreditkartennummern kann auf ähnliche Weise gesucht werden. Gewöhnlich sind Passwortfelder von einem solchen Typ, dass eingegebene Daten als Sternchen angezeigt werden. Auch dies kann anhand einer Analyse des DOM bestimmt und zum Identifizieren relevanter Daten verwendet werden.
  • In einer von einer Website heruntergeladenen Webseite würde es normalerweise keine Benutzerdaten geben, aber sie würden vom Benutzer in ein HTML-Formular eingegeben. Die potentiell empfindlichen Benutzerdaten werden gewöhnlich über den Webserver zur Website übertragen, wenn der Benutzer eine ,Submit'-Schaltfläche anklickt. In dieser Stufe kann das BHO das vom Webbrowser ausgegebene ,Submit'-Event einfangen und auf das DOM zugreifen, um die Benutzerdaten zu extrahieren, und kann bei Bedarf verhindern, dass diese Daten gesendet werden.
  • Ver- und Entschlüsselung auf einer sicheren Verbindung erfolgen jeweils nach Punkt C und vor Punkt A in 3. So kann das BHO die Daten analysieren, bevor sie verschlüsselt werden oder nachdem sie entschlüsselt wurden. Dies ist vorteilhaft, da es nicht nötig ist, dass das BHO selbst Daten codiert oder decodiert. Dies hat keinen Einfluss auf die Fähigkeit zu bestimmen, ob die Verbindung sicher ist oder nicht, da eine sichere Verbindung anhand der Protokollkennung „https" am Anfang der aktuellen URL-Adresse identifiziert werden kann. Es wird bevorzugt, dass eine Untersuchung des Inhalts der Übertragung vor der Verschlüsselung oder nach der Entschlüsselung stattfindet.
  • Erörterung des Betriebs eines Email-Clients Es werden nun der Betrieb eines typischen Email-Client und die Implementation der bevorzugten Ausgestaltung in einem Email-Client mit Bezug auf 5 der Zeichnungen beschrieben.
  • 5 zeigt den vereinfachten Betrieb eines Email-Clients. Empfang und Senden erfolgen typischerweise unabhängig und diese Operationen sind in 5 separat einander gegenüber liegend dargestellt, jeweils beginnend mit Schritt S120 und Schritt S130.
  • Die „Nachricht empfangen" Operation eines Email-Client wird in Schritt S120 eingeleitet. Dies erfolgt automatisch in vorbestimmten Intervallen, um den, Benutzer über eventuelle neu empfangene Nachrichten informiert zu halten, oder es kann als Reaktion darauf erfolgen, dass der Benutzer manuell ein ,Nachrichten empfangen' Icon anklickt. Der Start dieser Operation hat zur Folge, dass der Email-Client den Email-Server 95 abruft und eventuelle neue Nachrichten auf die Maschine des Benutzers herunterlädt. In Schritt S122 wird eine Email-Nachricht vom Email-Client empfangen. Typischerweise wird eine neue Nachricht nach dem Empfang in eine ,Inbox' gesetzt, wobei die empfangenen Nachrichtenköpfe (z. B. Name des Senders, Datum und Titel) zu einer Liste angeordnet sind. Der Benutzer klickt dann auf den entsprechenden Eintrag in der Liste, um die volle Nachricht zu lesen, so dass diese auf seinem Computerschirm erscheint. Die Email-Nachricht wird in Schritt S124 angezeigt.
  • Im Falle einer abgehenden Email wählt der Benutzer in Schritt S130 eine ,Email verfassen' Option. Als Reaktion darauf stellt der Email-Client eine Schnittstelle bereit, die einen Texteditor umfasst, in dem der Benutzer den Haupttext der Nachricht und andere Informationen wie z. B. Zieladresse, Betreff usw. eingeben kann. Der Benutzer verfasst die Nachricht in Schritt S132 und weist dann das Absenden an, indem er ein Icon oder eine Menüoption wählt, das/die im Email-Client zum Ausgeben eines ,Senden'-Befehls vorgesehen ist. Die Email wird in Schritt S134 zum Email-Server zur Übertragung zum Empfänger gesendet. Wenn der Email-Client eine Verschlüsselung durchführt, dann erfolgt dies in Schritt S134 vor der Übertragung.
  • In der bevorzugten Ausgestaltung wird zusätzliche Funktionalität für den Email-Client über ein Einsteckmodul bereitgestellt. Der Email-Client ist vorzugsweise einer der von Microsoft angebotenen, wie z. B. der Microsoft Exchange Client oder der Microsoft Gutlook Client, und das Einsteckmodul wird als eine Exchange Client Extension codiert. Diese sind in dem oben erwähnten Dokument „Microsoft Gutlook and Exchange Client Extensions" von Sharon Lloyd beschrieben.
  • Eine Exchange Client Extension ist ein Komponentenobjekt, das dem Component Object Model (COM) in Microsoft Windows entspricht und die Exchange IExchExt Schnittstelle verwendet. Diese Schnittstelle bietet eine Reihe von zusätzlichen Schnittstellen zum Modifizieren des Betriebs des Exchange Email Client, wie z. B. die IExchExtCommands-Schnittstelle, die es zulässt, dass das existierende Client-Verhalten ersetzt oder modifiziert wird und dass neue Befehle zu den Client-Menüs hinzugefügt werden; und die IExchExtEvent-Schnittstelle, die es zulässt, dass das kundenspezifische Verhalten zum Handhaben von Client-,Events' implementiert wird, wie z. B. die Ankunft neuer Nachrichten, Lesen, Schreiben, Senden von Nachrichten und Lesen und Schreiben von anhängenden Dateien. Auch die Schnittstellen IExchExtMessageEvents, IExchExtSessionEvents und IExchExtAttachmentEvents sind vorhanden und bieten zusätzliche Funktionalität für die in den einzelnen Schnittstellennamen angedeuteten spezielleren Aufgaben.
  • In der bevorzugten Ausgestaltung wird die Exchange Client Extension, die das Einsteckmodul bildet, zum Antworten auf Client-,Events' implementiert, die vom Client-Programm ausgelöst werden, wenn dieses Operationen ausführt und Aktionen vollzieht. Die fraglichen ,Events' werden von den oben erwähnten COM-Schnittstellen bereitgestellt. Die Überwachung des Email-Clients durch das Einsteckmodul kann daher als zu der Art und Weise analog angesehen werden, in der das BHO-Einsteckmodul den Betrieb des Webbrowsers überwacht.
  • Das Email-Client-Einsteckmodul wird beispielsweise zum Antworten auf das ,OnDelivery'-Event implementiert, das ausgelöst wird, wenn eine neue Nachricht von dem assoziierten Mailliefersystem empfangen wird und bevor es für den Benutzer sichtbar ist. Das ,OnDelivery'-Event enthält Informationen zum Zugreifen auf die verschiedenen Teile der Email-Nachricht, die heruntergeladen wurden und die sich im Speicher befinden. Der Nachrichtenkopf, der Nachrichtenhaupttext und eventuelle Nachrichtenanhänge werden im Speicher als Eigenschaften des Nachrichtenobjekts codiert, auf die separat durch MAPI-(Mail Application Program Interface)-Anrufe zugegriffen werden kann.
  • Anhand der als Teil des ,OnDelivery'-Events gegebenen Informationen kann das Einsteckmodul auf den Nachrichtenkopf zugreifen und beispielsweise die Identität des Senders ausziehen. Ferner kann das Einsteckmodul von MAPI-Anrufen erhaltene Informationen zum Absuchen des Texts einer empfangenen Nachricht nach Schlüsselwörtern oder relevanten Daten benutzen. Es kann nach Anzeichen auf eine eCommerce-Transaktion suchen, indem es signifikante Wörter wie ,Quittung' oder ,Kontonummer' identifiziert. Die Nachricht kann dann für Prüfzwecke gespeichert werden. Im Falle eines unzugelassenen Senders oder eines schädlichen Nachrichteninhalts kann die Nachricht ungesehen gelöscht werden.
  • Die Analyse einer empfangenen Email erfolgt daher an Punkt A in 5, bevor sie vom Benutzer betrachtet wird. Die Email wird vorzugsweise untersucht, bevor sie in die Inbox gesetzt wird. Wo eine Nachricht nicht automatisch vor dem Setzen in die Inbox entschlüsselt wird, z. B. dort, wo der Benutzer einen Entschlüsselungskey eingeben muss, da wird die Nachricht unmittelbar nach der Entschlüsselung, aber vor der Einsicht untersucht. Digitale Zertifikate können als Anhänge an die Email enthalten sein und können vor der Einsicht leicht untersucht werden, so dass geeignete Aktionen wie z. B. eine Validierung ausgeführt werden können.
  • Ein weiteres signifikantes Client-Event, für dessen Beantwortung das Einsteckmodul implementiert wird, ist das ,OnWriteComplete'-Event, das ausgelöst wird, wenn der Benutzer den ,Senden'-Befehl selektiert und den Email-Client aufgefordert hat, eine neue Email-Nachricht zum Mailliefersystem zu übertragen. Dieses Event wird an Punkt B in 5 vor der Übertragung und vor einer Verschlüsselung ausgeführt. Die neue Nachricht, die übertragen werden soll, wird ebenfalls im Speicher als Objekt gespeichert, auf das mit MAPI-Anrufen zugegriffen werden kann. Das Einsteckmodul kann die MAPI-Anrufe zum Durchsuchen des Inhalts der abgehenden Email nach sensitiven Daten wie Kreditkartennummern benutzen und nachfolgend bewirken, dass die Nachricht aufgezeichnet oder sogar gesperrt wird.
  • Betrieb der Einsteckmodule
  • Die bevorzugte Implementation der Einsteckmodule Webbrowser und Email-Client wurde oben mit Bezug auf die 3 und 5 beschrieben. Als Nächstes wird die durch die Einsteckmodule gegebene Funktionalität ausführlich mit Bezug auf die 6 bis 18 beschrieben.
  • Identifizieren und Aufzeichnen von Benutzernamen, Passwörtern und anderen Informationen
  • Das bevorzugte System bietet Mittel zum automatischen Identifizieren, Sammeln und Speichern von Daten, die in Übertragungen zu und von einer Benutzerworkstation enthalten sind, insbesondere die Benutzernamen und Passwörter, die von einem Benutzer zum Zugreifen auf Website-Seiten, FTP-(File Transfer Protocol)-Sites und andere solche Sites auf dem Internet eingegeben werden.
  • Systeme, die derzeit über Einrichtungen zum Aufzeichnen von Passwörtern verfügen, tun dies derzeit nur dann, wenn ein Benutzer auf die Option ,Remember Password' (Passwort merken) auf der GUI klickt. Das Passwort wird in einer geschützten lokalen Datei auf der Maschine des Benutzers gespeichert, die nur dann öffnet, wenn sich der Benutzer für diese Maschine authentifiziert, z. B. durch Eingeben seines Benutzernamens und des Passwortes beim Booten. Die Passwort-merken-Option bewirkt, dass sich das System das Passwort beim nächsten Besuch des Benutzers gemerkt hat, da das Passwortfeld mit diesem Passwort vorausgefüllt ist, so dass der Benutzer es nicht jedes Mal, wenn es verlangt wird, neu einzugeben braucht. Der Nachteil des lokalen Speicherns dieser Passwortdatei ist, dass der Benutzer, wenn er zu einer anderen Maschine geht, keinen Zugang zu der gespeicherten Passwortdatei hat und das Passwort selbst neu eingeben muss.
  • Das bevorzugte System identifiziert Passwörter automatisch ohne Notwendigkeit für einen Befehl vom Benutzer und speichert die identifizierten Passwörter und Benutzernamen in einem Daten-Repository. Dies ist vorzugsweise eine zentrale Datenbank 42. So können die Passwörter eines beliebigen Benutzers unabhängig von dem Terminal abgerufen werden, an dem sich der Benutzer einloggt, unter der Voraussetzung, dass das Terminal Zugang zu der zentralen Datenbank hat.
  • Identifizierte Passwörter und Benutzernamen werden in der Datenbank zusammen mit den Feldnamen, in denen sie auf der ursprünglichen Website gespeichert sind, und der Adresse der Internet-Site gespeichert, zu der sie übertragen und auf der sie benutzt werden. Site-Informationen können ganz einfach abgerufen werden, da sie in der HTTP-Anforderung enthalten sind, die die Passwort- und Benutzerinformationen dieser Site submittieren, sowie in der Darstellung der im Speicher befindlichen Webseite.
  • Die in der Datenbank gespeicherten Informationen sind sicherheitshalber vorzugsweise verschlüsselt, so dass nur eine ausgewählte Anzahl von Personen, wie z. B. Netzwerk-Supervisor, Systemadministratoren oder Unternehmensleiter, Zugang dazu haben. Sie können entweder durch eine Workstation im Netzwerk, durch Eingeben eines Benutzernamens oder eines Passwortes, um sich zu identifizieren, oder durch eine Supervisor-Workstation wie z. B. Operatorkonsolen 44 auf die Datenbank zugreifen.
  • Diese Speicherung von Benutzernamen und Passwörtern zusammen mit Adressdetails bietet einen erheblichen Vorteil für Unternehmen, die Online-Einrichtungen benutzen. Mit den derzeitigen Techniken kann, wenn ein Benutzer sein Authentifizierungspasswort vergisst, was einen Zugriff auf die geschützte Datei verhindert, oder das Unternehmen verlässt, ohne das Passwort mitgeteilt zu haben, nicht auf den Internet-Dienst zugegriffen werden. Eine ähnliche Situation entsteht, wenn die geschützte Datei beschädigt oder gelöscht wurde oder auf andere Weise verloren gegangen ist. Jeder Internet-Dienst muss dann nacheinander besucht werden, um das verlorene Passwort zu ersetzen oder zurückzugewinnen, was im Hinblick auf verlorene Zugriffs- und Administrationszeit sehr kostspielig sein kann. Mit dem bevorzugten System können die Passwortinformationen aus der zentralen Datenbank zurückgeholt werden, so dass der Zugang zu Websites nicht verloren geht.
  • 6 ist ein Fließschema, das den Betrieb eines Einsteckmoduls schematisch illustriert, das zum Extrahieren von Benutzernamen- und Passwortinformationen aus zu einem Webserver zu übertragenden Daten implementiert wird.
  • In Schritt S150 beginnt das Einsteckmodul mit dem Parsen der Daten, die als Nächstes vom Browser zum Webserver übertragen werden sollen. Dies erfolgt an Punkt ,C' in dem in 3 illustrierten Vorgang. Die Steuerung geht dann zu Schritt S152, wo das Einsteckmodul ermittelt, ob die zu übertragenden Daten Benutzernamen- oder Passwortinformationen enthalten oder nicht.
  • Die Passwörter oder Benutzernamen können in der oben mit Bezug auf die 3, 4 und 5 beschriebenen Weise z. B. durch Identifizieren von Feldnamen in einem submittierten Befehl oder mit Hilfe des DOM identifiziert werden, um nach Feldnamen, Feldtypen oder dem zum Identifizieren der Daten auf Webseiten verwendeten Anzeigeverfahren zu suchen. Sie können auch von der HTML von Webseiten, den Einblendfenstern oder GUIs (grafische Benutzeroberflächen) abgerufen werden, die von fernen Servern oder Providern auf dem World Wide Web präsentiert werden, oder sogar durch Scannen des Inhalts von Email-Nachrichten.
  • Das Identifizieren von Passwörtern und Benutzernamen in übertragenen Befehlen oder im DOM einer Webseite von ihren Feldnamen stützt sich auf die Feldnamen, die ihren Zweck mit offensichtlichen Etiketten wie ,Passwort' oder ,Benutzername' beschreiben. Falls der Feldname an sich keine Bedeutung hat, kann die Natur von übertragenen Daten vom Feldtyp der Daten, d. h. ,String' oder ,Integer' usw., oder von dem zum Eingeben der Daten benutzten Anzeigeverfahren abgeleitet werden. Felder, die ein Passwort aufnehmen sollen, können anhand der Repräsentation beim Suchen nach einem ,Passwort'-Feldtyp im DOM identifiziert werden. Textboxen auf einer Webseite, in die z. B. Passwortdaten eingegeben werden sollen, zeigen typischerweise jedes eingegebene Zeichen als ein Sternchen an; diese Eigenschaft kann anhand des DOM ermittelt und zum Inferieren benutzt werden, dass in die Textbox eingegebene Daten ein Passwort sind, selbst dann, wenn es keine anderen Anzeichen dafür gibt. Das Passwort wird zwar als eine Folge von Sternchen angezeigt, aber die Repräsentation im Speicher enthält weiter die Zeicheninformationen, die vom Benutzer eingegeben wurden. Das Passwort kann einfach durch Extrahieren der Eingabe aus dem Feld entnommen werden.
  • Alternativ können Passwörter und Benutzernamen durch Verweis auf die identifiziert werden, die von anderen Programmen wie dem ,Internet Explorer' von Microsoft gespeichert werden, wenn der Benutzer die Passwort-merken-Option gewählt hat. Solche Passwörter werden in einer lokalen geschützten Datei auf dem Computer des Benutzers gespeichert. Diese Datei wird dann ,entsperrt', wenn sich der Benutzer auf dem Computer authentifiziert hat, und so kann vom Browser-Einsteckmodul des bevorzugten Systems zum Erhalten von Passwort- und Benutzernamensinformationen darauf zugegriffen werden.
  • Wenn das Einsteckmodul in den zu übertragenden Daten kein(en) Benutzernamen oder Passwort erfasst, dann geht die Steuerung zu Schritt S158, und an diesem Punkt verlässt das Modul die Routine und die Steuerung geht zurück zu Punkt ,C' in 3. Der Browser kann dann die Daten zum Webserver senden. Wenn jedoch das Einsteckmodul in Schritt S152 ein(en) Benutzername oder Passwort erkennt, dann geht die Steuerung zu Schritt S154, wo die Werte des identifizierten Benutzernamens oder Passworts und die URL-Adresse oder eine andere Kennung der Webseite, zu der die Daten gesendet werden sollen, extrahiert werden. Die Steuerung geht dann zu Schritt S156, wo diese Werte und die URL-Adresse oder eine andere Kennung in einer vorbestimmten Systemdatenbank 42 gespeichert werden. Nach dem Speichern geht die Steuerung zu Schritt S158, wo das Modul die Routine verlässt und die Steuerung zurück zu Punkt ,C' in 3 geht. Der Browser kann dann die Daten zum Webserver übertragen.
  • Die bevorzugte Ausgestaltung braucht nicht nur auf die Speicherung von Passwörtern oder Benutzernamen begrenzt zu sein, die aufgrund des sofortigen Vorteils, den ihre Speicherung bietet, als Beispiel benutzt wurden. Andere Datentypen, besonders solche in Bezug auf eCommerce-Transaktionen, z. B. Kreditkarteninformationen und digitale Zertifikate, können ebenfalls zum Erstellen einer Datenbank oder eines Datensatzes nutzbringend extrahiert und gespeichert werden. Das System zum Extrahieren von Informationen von Übertragungen kann auch auf Email-Systeme angewendet werden.
  • Die Informationen können auf die oben beschriebene Weise über das DOM oder über MAPI-Anrufe zur COM-Darstellung von Email-Inhalt extrahiert werden, oder sie können aus der Sprache extrahiert werden, in der eine Webseite codiert ist. Webseiten werden typischerweise in HTML (Hyper Text Markup Language) codiert, einer für den Menschen lesbaren textgestützten Sprache, die mittels konventioneller Textvergleichstechniken nach bekannten Schlüsselwörtern oder Indikatoren durchsucht werden können. In der bevorzugten Ausgestaltung kann das Aufzeichnen der Daten das Aufzeichnen nur von Passwort- und Benutzernamensinformationen, das Aufzeichnen der URL- Adresse einer betrachteten Webseite oder eines Email-Kontos, das Aufzeichnen beliebiger Daten, die zu den Feldern einer Webseite gesendet werden, und das Aufzeichnen der HTML einer Webseite beinhalten, so dass die Webseite später abgerufen und betrachtet werden kann.
  • Die in dem bevorzugten System enthaltenen Einsteckmodule arbeiten in Verbindung mit Richtliniendaten, die z. B. in einer Datei, einer Datenbank oder in Softwarecode aufgezeichnet werden können. Die Richtliniendaten geben einem Benutzer des bevorzugten Systems die Möglichkeit zum Befehlen des Betriebs jedes der Einsteckmodule, um dadurch deren Funktionalität zu steuern.
  • Eine beispielhafte Darstellung von Richtliniendaten, in 7 illustriert, zeigt, wie ein Benutzer den Betrieb des Einsteckmoduls zum Aufzeichnen von Passwort- und Benutzernamensinformationen zusammen mit anderen Datentypen steuern kann.
  • Die baumähnliche Struktur der Richtliniendaten ist deutlich in 7 zu sehen, die nur einen Hauptzweig der Richtliniendaten mit dem Titel ,Recording' zeigt. Der Recording-Zweig ist in zwei Nebenzweige jeweils mit den Namen ,Browser' und ,Email' unterteilt, die Befehle für den Betrieb der Einsteckmodule Webbrowser bzw. Email-Client enthalten.
  • Der Browser-Zweig hat drei Nebenzweige mit den Bezeichnungen ,DataToRecord', ,WhenToStartRecording' und ,WhenToStopRecording'. Der DataToRecord-Zweig gibt den Datentyp vor, der aus Übertragungen zu und von der Benutzerworkstation und einem Webserver extrahiert werden sollen. Es werden in der Illustration vier Datentypen genannt, nämlich die URL-Adresse der betrachteten Webseite, die HTML der betrachteten Webseite, die von einem Benutzer in Felder auf der Webseite eingegebenen Daten, die einer Website submittiert werden, und eventuelle vom Benutzer eingegebene Passwörter und Benutzernamen. Diese werden in vier getrennten Nebenzweigen des DataToRecord-Zweigs mit den Bezeichnungen ,URL', ,HTML', SubmittedFields' und ,Passwords' genannt. Eine Ja/Nein-Option an jedem dieser Nebenzweige gibt an, ob die angezeigten Daten aufgezeichnet werden sollen oder nicht.
  • Der WhenToStartRecording-Zweig enthält eine Reihe von Bedingungen, die den Punkt angeben, an dem die im DataToRecord-Zweig vorgegebenen Daten aufgezeichnet werden sollen. In diesem Beispiel sind fünf Bedingungen illustriert, die jeweils auf einem anderen Zweig liegen, die jeweils mit ,WhenBrowserIsOpened', ,IfCreditCardNumberSubmitted', ,IfPasswordSubmitted', ,IfKeywordsReceived' und ,IfKeywordsSent' bezeichnet sind. Ob diese Bedingungen benutzt werden sollen, um zu ermitteln, wann die Aufzeichnung beginnt, wird durch einen Ja/Nein-Marker auf jedem Zweig angezeigt.
  • Ebenso führt der WhenToStopRecording-Zweig drei Bedingungen auf, die zum Ermitteln des Punkts verwendet werden können, an dem die Aufzeichnung der im DataToRecord-Zweig vorgegebenen Daten gestoppt werden soll. Diese Bedingungen sind ,WhenUserClosesBrowser', ,WhenUserChangesSite' und ,WhenUserChangesPage'. Der Ja/Nein-Status jeder der Bedingungen und für jeden aufzuzeichnenden Datentyp können leicht von einem Benutzer des bevorzugten Systems eingerichtet werden, um den Betrieb des Einsteckmoduls zu steuern.
  • Der Email-Zweig der Richtliniendaten ist in einen DataToRecord-Zweig und einen WhenToRecord-Zweig unterteilt. Jeder dieser Zweige ist in Zweige unterteilt, die sich mit gesendeter Mail und empfangener Mail befassen. Der Datentyp, der aufgezeichnet werden kann, ist im DataToRecord-Zweig angegeben und kann für gesendete Mail der Nachrichtentext, eventuelle Anhänge an die Nachricht und im Falle von mit einer digitalen Signatur signierten Nachrichten eine Kopie des die Signatur begleitenden digitalen Zertifikats sein. Bedingungen zum Aufzeichnen von gesendeten Mails und empfangenen Mails sind im WhenToRecord-Zweig dargelegt und können auf der Identifikation einer Kreditkartennummer, eines Schlüsselworts oder eines digitalen Zertifikats in der Mail basieren, die gesendet oder empfangen wird.
  • Die beschriebene baumähnliche Struktur ist die bevorzugte Form für die Richtliniendaten, da es mit ihr einfach ist, die Daten zu organisieren und darauf zu verweisen. Sie erlaubt es auch, verschiedene Benutzer unterschiedlichen Zweigen des Baums zuzuweisen, um verschiedene Richtlinien zu empfangen. Die baumähnliche Struktur wird zwar bevorzugt, aber es können auch andere Anordnungen möglich sein. Die in diesem Diagramm gezeigten Zweige sollen lediglich illustrativ sein.
  • Identifikation von Kreditkartennummern
  • Das bevorzugte System sucht auch nach Kreditkartennummern oder anderen Kontoinformationen in den zum Webserver oder Email-Client zu übertragenden Daten, indem es nach einer Folge von numerischen Ziffern sucht, typischerweise mit einer Länge zwischen 14 und 16. Es ermittelt dann, ob diese Ziffernfolge einen der Tests besteht, die universell von Kreditkartenunternehmen zum Validieren von Kreditkartennummern benutzt wird. Wenn eine Kreditkartennummer in der Übertragung gefunden wird, kann das bevorzugte System eine Reihe von Aktionen je nach den Einstellungen in der Richtliniendatei ausführen, wie z. B. überweisen der übertragung zu einer Drittpartei zur Billigung, Renegoziieren eines höheren Verschlüsselungsniveaus zum Sichern der Übertragung, wenn die Kreditkartennummer einem Unternehmen gehört, oder Verhindern, dass die Übertragung überhaupt stattfindet.
  • Der üblichste Test zum Identifizieren einer Kreditkartennummer ist im ANSI-Standard X4.13 definiert und ist üblicherweise als LUHN oder Mod 10 bekannt.
  • Die Luhn-Formel wird auf Kreditkartennummern angewendet, um eine Prüfziffer zu erzeugen, und kann somit zum Validieren von Kreditkarten benutzt werden, in diesem Fall wird die Prüfziffer als Teil der Formel einbezogen. Zum Validieren einer Kreditkartennummer mit der Luhn-Formel wird der Wert jeder zweiten Ziffer nach der ersten, beginnend von der rechten Seite der Nummer und nach links gehend, mit zwei multipliziert; alle Ziffern, sowohl die, die mit zwei multipliziert wurden, als auch die, die es nicht wurden, werden miteinander addiert; Ziffernwerte, die infolge der Verdopplung gleich oder größer als zehn werden, werden summiert, als wären sie zwei einstellige Werte, z. B.: ‚10' zählt als ‚1+0 = 1', ‚18' zählt als ,1+8 = 9'. Wenn die Gesamtsumme durch zehn dividierbar ist, dann ist die Kreditkarte eine gültige Kreditkartennummer.
  • 8 ist ein Fließschema, das den Betrieb eines Einsteckmoduls illustriert, das Kreditkartennummern mit der oben beschriebenen Luhn-Formel in vor der Übertragung stehenden Daten erkennt. Wenn eine Kreditkartennummer identifiziert wird, dann führt das Einsteckmodul weitere richtliniengestützte Checks aus, und auf der Basis von deren Ergebnis kann das Einsteckmodul entscheiden, ob die die Kreditkartennummer enthaltenen Daten übertragen werden sollen oder ob eine Übertragung verhindert werden soll.
  • Das Modul beginnt mit dem Betrieb in Schritt S160, der auf Punkt ,C' in dem in 3 illustrierten Vorgang im Falle einer Browser-Implementation folgt, oder auf Punkt B in dem in 5 illustrierten Vorgang im Falle einer Email-Client-Implementation. Die Steuerung geht von Schritt S160 zu Schritt S162, in dem das Modul die unmittelbar vor dem Senden zum Webserver oder Email-Server stehenden Daten absucht und daraus eine erste Folge von Stellen extrahiert, die wahrscheinlich eine Kreditkartennummer sind.
  • Dies wird durch Scannen der Daten erzielt, die die Übertragung von Ziffernfolgen über eine bestimmte Stellenlänge vergleicht. Kreditkartennummern bestehen gewöhnlich aus mehr als 12 Ziffern und nicht mehr als 16 Ziffern. So kann jede Ziffernfolge in diesem Bereich als mögliche Kreditkartennummern identifiziert werden.
  • Nach dem Extraktionsschritt S162 geht die Steuerung zum Entscheidungsschritt S164, wo ein routinemäßiger Dateiende-Check ausgeführt wird. Wenn die Daten keinen Kreditkartennummernkandidaten enthalten und der Dateiende-Check erreicht wird, bevor ein erster Nummernkandidat gefunden wird, dann geht die Steuerung in Schritt S164 weiter zu Schritt S178, wo die Übertragung der Daten zugelassen wird, ohne dass weitere Checks erfolgen. Das Modul endet dann in Schritt S180. Die Steuerung nimmt dann den in 3 gezeigten Webbrowser-Betrieb ab Punkt ,C' oder den in 5 gezeigten Email-Client-Betrieb ab Punkt B wieder auf.
  • Wenn eine erste potentielle Kreditkartennummer in den Daten in Schritt S162 gefunden wird, dann wird sie extrahiert und im Speicher gespeichert. Das Dateiende ist noch nicht erreicht, daher geht die Steuerung von Schritt S162 zu Schritt S164 und dann zu Schritt S166, wo eine Prüfsumme für die gespeicherte Kandidatennummer mit der Luhn-Formel berechnet wird. Die Steuerung geht dann zum Entscheidungsschritt S168, wo die Prüfsumme abgefragt wird.
  • Wenn die Prüfsumme anzeigt, dass die Kandidatennummer keine gültige Kreditkartennummer ist, dann geht die Steuerung zurück zu Schritt S162, wo die nächste potentielle Kreditkartennummer aus den Daten extrahiert wird. Wenn keine zweite Kreditkartennummer gefunden wird, dann wird das Ende der Datei erreicht und die Steuerung geht zu Schritt S178, wo die Übertragung stattfindet, und dann zu Schritt S180, wo das Modul die Routine verlässt.
  • Wenn die Prüfsumme jedoch anzeigt, dass die Kandidatennummer eine gültige Kreditkartennummer ist, dann geht die Steuerung zum Entscheidungsschritt S170, wo die Einstellungen der Richtliniendaten nach der richtigen durchzuführenden Aktion abgefragt werden. Die Aktion kann anhand von Faktoren wie die Nummer selbst, die Identität des die Nummer übertragenden Benutzers und die Adresse bestimmt werden, zu der sie gesendet werden soll. Die Richtliniendaten könnten beispielsweise vorgeben, dass Kreditkartennummern nicht zu übertragen sind oder dass eine höhere Verschlüsselungsstärke erforderlich ist, bevor die Übertragung erfolgen kann.
  • Mit diesem Richtlinienprüfschritt können Kreditkartentransaktionen auf einem höheren Level als dem des die Transaktion vornehmenden Benutzers gesteuert werden. So können finanzielle Entscheidungen schnell und leicht implementiert und automatisch ohne Notwendigkeit für Überwachung durchgesetzt werden. Eine Organisation möchte z. B. möglicherweise den Zugang zur Durchführung von Kredittransaktionen auf dem Konto der Organisation auf bestimmte autorisierte Personen oder Transaktionen für ein bestimmtes Konto insgesamt beschränken.
  • In Schritt S170 werden die Kreditkartennummer und andere Details der Transaktion mit den Einstellungen in der Richtliniendatei verglichen und es wird entschieden, ob eine Übertragung stattfinden kann oder nicht. Wenn bei den Richtlinienprüfungen aus irgendeinem Grund bestimmt wird, dass die Kreditkartennummer nicht übertragen werden soll, dann geht die Steuerung zu Schritt S172, wo die Übertragung der Daten unterbrochen wird, und dann zu Schritt S174, wo das Modul die Routine verlässt. Hier könnte das System dem Benutzer die Tatsache, dass die Anforderung abgelehnt wurde, durch eine Popup-Nachrichtenbox mitteilen. Die Steuerung kehrt dann bei einem Webbrowser zu Punkt A in 3 oder, bei einem Email-Client, zu Schritt S132 ,Mail verfassen' in 5 zurück.
  • Wenn in Schritt S172 ermittelt wird, dass die Kreditkartennummer übertragen werden kann, dann geht die Steuerung zu Schritt S176, wo die Daten übertragen werden, und dann zu Schritt S180, wo das Modul die Routine verlässt. In diesem Fall wird die Steuerung ab Punkt C in dem in 3 illustrierten Webbrowser-Betrieb oder ab Punkt B in dem in 5 illustrierten Email-Client-Betrieb wieder aufgenommen.
  • Kreditkartennummern brauchen in Schritt S162 nicht nur durch Scannen des Inhalts der Übertragung identifizert zu werden. In Webbrowser-Implementationen kann die Kreditkartennummer beispielsweise direkt mit Bezug auf die Feldnamen von Variablen identifiziert werden, die übertragen werden sollen, oder auch von der Darstellung der Webseite im Speicher. Die obige Diskussion über die Identifikation von Passwörtern erläutert dies näher.
  • Das bevorzugte System kann auch so konfiguriert werden, dass es nach abgehenden Übertragungen für andere relevante Finanzdetails wie z. B. Kontonummern sucht. Firmenkontonummern, von denen Fonds deponiert werden können, können in einer separaten Datei gespeichert werden. Eventuelle wahrscheinliche Zeichen- oder Ziffernfolgen können dann aus den abgehenden Daten in der beschriebenen Weise extrahiert und mit den Einträgen in der Kontendatei verglichen werden, um zu ermitteln, ob die Kontonummer gültig ist oder nicht. Die Transaktion kann dann wie oben beschrieben zugelassen oder verweigert werden. Es wurde zwar auf Kreditkartennummern Bezug genommen, aber man wird verstehen, dass auch jeder andere Kartennummerntyp wie z. B. Debitkartennummern für Zahlungen verwendet werden kann.
  • Es wurde zwar auch die Identifikation von Kreditkartennummern mit Bezug auf Daten erläutert, die übertragen werden sollen, aber man wird verstehen, dass ähnliche Techniken auch zum Identifizieren und Extrahieren von Kreditkartennummern von Übertragungen verwendet werden können, die empfangen werden.
  • Validierungs- und Authentifizierungsunterstützung
  • Online-Transaktionen erfordern typischerweise eine Form von Authentifizierung, ob der Benutzer der ist, für den er sich ausgibt, und ob er in der Lage ist, für die bestellten Waren zu bezahlen. Diese Anforderungen werden gewöhnlich vom Käufer dadurch erfüllt, dass er dem Händler seine Kreditkartennummer und die Karteninhaberadresse angibt, die dann vom Verkäufer beim Kartenausgeber verifiziert werden. Es werden jedoch in zunehmendem Maße digitale Zertifikate vom Benutzer an elektronische Übertragungen angehängt, die es dem Empfänger in Verbindung mit einer digitalen Signatur gestatten zu prüfen, ob die Übertragung von der als Sender genannten Person stammt. Digitale Zertifikate von bestimmten Ausgabestellen wie z. B. Identrus können auch als Gewährleistung dienen, dass der Halter seiner Verpflichtung zur Zahlung eines bestimmten Geldbetrags nachkommen wird. Diese Zertifikate sind bei Online-Handelsgeschäften nützlich.
  • Digitale Signaturen sind ein weithin benutztes Mittel, um die Identität einer Person online festzustellen, wenn Informationen übertragen oder Transaktionen durchgeführt werden. Sie sind auch eine Garantie für den Empfänger von übertragenen Informationen oder Transaktionsdetails, dass diese Details und diese Informationen nicht von einer unbefugten Drittpartei auf der Strecke missbraucht werden.
  • Digitale Zertifikate werden an Personen, Organisationen oder Unternehmen von unabhängigen Zertifikatbehörden wie z. B. Verisign Inc. ausgegeben. Eine Organisation kann auch als ihre eigene Zertifikatbehörde fungieren, die ihre eigenen digitalen Zertifikate ausgibt, die von einem von einer anderen Zertifikatbehörde ausgegebenen ,Root'-Zertifikat abgeleitet sein können oder auch nicht. Ein digitales Zertifikat enthält typischerweise den Namen des Inhabers, eine Seriennummer, ein Ablaufdatum, eine Kopie des Public-Key des Zertifikatinhabers und die digitale Signatur der Zertifikatausgabestelle. Auch ein Private-Key wird an den Zertifikatinhaber ausgegeben, der diesen an niemand anders weitergeben sollte.
  • Zertifikate sind für jeden Halter eindeutig und können von einem Ausgeber widerrufen werden, wenn der Halter nicht mehr gültig ist; ein Halter kann auch um einen Widerruf bitten, wenn sein Private-Key kompromittiert wurde.
  • Die Public- und Private-Keys können nicht zusammen zum Ver- oder Entschlüsseln einer Nachricht benutzt werden. Jedermann kann den Public-Key eines Zertifikatinhabers zum Verschlüsseln einer Nachricht benutzen, so dass sie nur vom Zertifikatinhaber nach dem Entschlüsseln der Nachricht mit seinem Private-Key gelesen werden kann.
  • Nachrichten können auch digital mit Software signiert werden, die den Inhalt der Nachricht in eine Hash genannte mathematische Zusammensetzung umwandelt. Der Hash wird dann mit dem Private-Key des Senders verschlüsselt. Der verschlüsselte Hash kann dann als digitale Signatur für die Nachricht verwendet werden, die übertragen wird. Die ursprüngliche Nachricht, die digitale Signatur und das digitale Zertifikat des Senders werden alle zu einem Empfänger gesendet, der zum Bestätigen, dass die von ihm empfangene Nachricht komplett und gegenüber ihrer ursprünglichen Form unverändert ist, dann einen Hash für die empfangene Nachricht erzeugen kann. Wenn der empfangene Hash nach dem Entschlüsseln mit dem Public-Key des Inhabers mit dem vom Empfänger produzierten Hash übereinstimmt, dann kann der Empfänger sicher sein, dass die Nachricht von der Person gesendet wurde, an die das Zertifikat ausgegeben wurde, und dass die Nachricht nicht auf der Strecke gegenüber ihrer ursprünglichen Form verändert wurde. Digitale Zertifikate sind daher von erheblicher und zunehmender Bedeutung für Firmen, die Geschäfte auf dem Internet tätigen.
  • In Fällen, bei denen ein Online-Händler digitale Zertifikate zum Gewährleisten der Identität seiner Kunden nutzt, muss beim Ausgeber geprüft werden, ob das Zertifikat weiterhin gültig ist, bevor eine Transaktion autorisiert wird. Solche Checks können online mit einem unabhängigen Verifikationsdienst wie z. B. dem von Valicert, Inc. angebotenen ausgeführt werden. Für solche Dienste wird gewöhnlich eine Gebühr erhoben.
  • Es kann vorkommen, dass individuelle Mitarbeiter einer Organisation jeweils Emails von einem einzigen Client, jeweils mit dessen digitalem Zertifikat signiert, zu separaten Zeitpunkten erhalten. Derzeit gibt es keine Möglichkeit, wie eine Information über Zertifikate, die von einem Mitarbeiter empfangen wurden, mit einem anderen Mitarbeiter gemeinsam genutzt werden kann, es sei denn, dass sie diese manuell untereinander austauschen, und infolgedessen könnten einzelne Mitarbeiter anfordern, dass dasselbe Zertifikat jedes Mal validiert wird, wenn sie es erhalten. Dies ist jedoch verschwenderisch, da ein Zertifikat, das von seinem Ausgeber widerrufen wird, nie wieder reaktiviert wird, so dass Validierungsgebühren, die bereits für einen Widerruf des Zertifikats ausgegeben wurden, unnötig sind. Zusätzlich möchte der Empfänger möglicherweise ein geschäftliches Urteil darüber fällen, ob ein zuvor validiertes Zertifikat erneut geprüft werden soll oder nicht. Wenn beispielsweise an einem Tag ein digital signierter Auftrag im Wert von einer Million Dollar für Waren empfangen wird und das Zertifikat erfolgreich validiert wurde, und am nächsten Tag ein anderer Auftrag für $50 eingeht, mit demselben Zertifikat signiert, dann kann die Organisation einen zweiten Validierungscheck als unnötig ansehen und spart dadurch die Validierungsgebühr.
  • Das bevorzugte System stellt Mittel zum Aufzeichnen von Informationen über die empfangenen digitalen Zertifikate, den Status des Zertifikats beim letzten Check sowie, wo zutreffend, Transaktionsinformationen wie Client, Betrag, Datum, Waren usw. bereit. Diese Informationen werden in einer zentralen Datenbank gespeichert, zu der alle Benutzer des Systems Zugang haben. Das bevorzugte System stellt auch Mittel zum Benutzen der gespeicherten Informationen bereit, um zu entscheiden, ob ein Validierungscheck wünschenswert ist oder nicht, und um Übertragungen je nach dem Status des digitalen Zertifikats zu akzeptieren oder abzulehnen. So können Benutzer des Systems Übertragungen empfangen und überprüfen, ohne ihre Authentizität selbst feststellen zu müssen.
  • 9 illustriert den Betrieb eines Einsteckmoduls des bevorzugten Systems, das implementiert wird, um digitale Zertifikate von Übertragungen zu extrahieren, die von Unternehmensmitarbeitern empfangen wurden, und um sie in einer Datenbank zusammen mit ihrem Validitätsstatus und mit Einzelheiten über eventuelle assoziierte Transaktionen aufzuzeichnen, wie z. B. Datum, Betrag, Waren usw. Das Modul prüft zunächst, ob das Zertifikat offensichtlich ungültig ist und ob die Nachricht damit korrekt signiert wurde. Das Zertifikat ist z. B. dann offensichtlich ungültig, wenn sein Ablaufdatum überschritten wurde oder wenn es einen ungültigen ,Fingerabdruck' enthält. Ein solcher Fingerabdruck kann beispielsweise eine Prüfsumme für das Zertifikat selbst sein. Die Nachricht wurde nicht korrekt signiert, wenn die Signatur nicht anhand der im Zertifikat enthaltenen Informationen überprüft werden kann. Einzelheiten über die Zertifikatvalidierung und die Nachrichtensignierung sind in den oben erwähnten ITU- und RFC-Dokumenten ausführlicher beschrieben. Das Modul prüft dann, ob das Zertifikat bereits in der Datenbank gespeichert ist oder nicht, und zeichnet nur diejenigen auf, die es nicht sind. Wo bereits eine Kopie des Zertifikats gespeichert ist, da prüft das Modul den Datenbankeintrag, um zu ermitteln, ob er bereits zuvor als widerrufen identifiziert ist, und in diesem Fall wird die Übertragung sofort abgelehnt. Ansonsten ermittelt das Modul gemäß Geschäftsregeln definierenden Richtlinien, ob das Zertifikat validiert werden soll oder nicht. Je nach den Ergebnissen einer solchen Validierung prüft es dann, ob das Zertifikat verlässlich ist und daher, ob die von dem digitalen Zertifikat signierte Übertragung abgelehnt oder akzeptiert werden soll. Das Modul wird in Schritt S190 gestartet, im Anschluss an den Empfang von Daten, die ein digitales Zertifikat enthalten. Digitale Zertifikate werden typischerweise als Anhänge an Nachrichten übertragen und können durch Untersuchen der ersten paar Bytes im Kopf des Anhangs identifiziert werden. Diese Bytes identifizieren den Typ der angehängten Datei und geben auch an, ob ein Anhang ein digitales Zertifikat ist oder nicht.
  • Der Startschritt S190 erfolgt nach Punkt A in 3, wenn das Modul in einem Webbrowser implementiert wird, und nach Punkt A in 5, wenn das Modul in einem Email-Client implementiert wird. Nach dem Start geht das Modul weiter zu Schritt S191, wo das Ablaufdatum des Zertifikats geprüft und die Signierung der Nachricht durch die digitale Signatur bestätigt wird. Wenn das Zertifikat abgelaufen ist oder wenn die Nachricht inkorrekt signiert wurde, dann geht das Modul weiter zu Schritt 198 und lehnt die Übertragung ab. Ansonsten geht das Modul zu Schritt S192, wo die Datenbank nach einer zuvor empfangenen Kopie des digitalen Zertifikats abgesucht wird. Die Steuerung geht dann zum Entscheidungsschritt S194. Wenn eine Kopie des Zertifikats in der Datenbank gefunden wird, dann geht die Steuerung weiter zum Entscheidungsschritt S196, wo das Modul ermittelt, ob das Zertifikat zuvor als widerrufen markiert wurde. Dies ist dann aufgetreten, wenn ein früherer Validitätscheck zu Tage gebracht hat, dass ein digitales Zertifikat widerrufen wurde. Wenn das Zertifikat nicht bereits in der Datenbank ist, dann geht die Steuerung von Schritt S194 zu Schritt S202, wo das neue Zertifikat und das Datum, an dem es empfangen wurde, zusammen mit zusätzlichen Details wie die Adresse, von der es gesendet wurde, und Details von eventuellen Transaktionen in Verbindung mit der Übertragung in der Datenbank gespeichert werden, wie z. B. ein Geldwert, die Kontonummer usw. Wenn das Zertifikat in Schritt S196 bereits als widerrufen markiert wurde, geht die Steuerung direkt zu Schritt S198, wo die das digitale Zertifikat umfassende Übertragung automatisch abgelehnt wird. Dies kann beispielsweise das Senden einer automatisch erzeugten Meldung zum Initiator der Übertragung beinhalten, dessen Zertifikat als ungültig gefunden wurde, um die Ablehnung zu erläutern und um zu verhindern, dass der Empfänger des digitalen Zertifikats weitere Schritte in Verbindung mit der abgelehnten Übertragung unternimmt. Das Modul verlässt dann die Routine in Schritt S200.
  • Wenn das Zertifikat jedoch nicht zuvor in Schritt S196 als widerrufen markiert wurde, dann geht die Steuerung zu Schritt S204, wo die Historie von Übertragungen, die durch das Zertifikat oder durch andere Zertifikate von demselben Unternehmen signiert oder zum Ausführen von Transaktionen auf demselben Konto verwendet wurden, mit Richtliniendaten verglichen werden, um zu ermitteln, ob ein Online-Validitätscheck des Zertifikats erforderlich ist. Die Steuerung geht auch zu Schritt S204, nachdem ein neues digitales Zertifikat zur Datenbank in Schritt S202 hinzugefügt wurde.
  • Die Richtliniendaten enthalten Befehle, die in Verbindung mit der Historie von zuvor empfangenen signierten Übertragungen und zuvor durchgeführten Widerrufchecks betrachtet anzeigen, ob das zum Signieren einer Übertragung benutzte Zertifikat bei dieser Gelegenheit geprüft werden soll oder nicht. Beispielhafte Richtliniendaten sind in 10 illustriert, auf die nun Bezug genommen werden sollte.
  • Die Richtliniendaten sind auf dem Zweig AcceptanceConfidenceRating auf dem DigitalCertificates-Zweig der Richtliniendatendarstellung gespeichert. Der AcceptanceConfidenceRating-Zweig ist in zwei separate Zweige unterteilt, die sich individuell mit ,monetären' digitalen Zertifikaten befassen, wo ein Zertifikat zum Signieren einer Übertragung benutzt wird, die eine Transaktion mit dem Empfänger für einen Geldbetrag beinhaltet, und digitalen ,Identitäts'-Zertifikaten, die keine monetäre Transaktion mit dem Empfänger der Übertragung beinhalten. Bestimmte Zertifikate werden nur für die Verwendung in Verbindung mit monetären Transaktionen ausgegeben, zum Beispiel das von einigen Online-Bankorganisationen wie Identrus ausgegebene ,Warranty Certificate', das als eine Gewährleistung für den Empfänger der signierten Übertragung ausgegeben wird. Solche Gewährleistungszertifikate bezeugen, dass der Sender der Übertragung Kunde einer Identrus-Mitgliedsbank ist und dass die Bank die Haftung für eventuell von ihm nicht geleistete Zahlungen übernimmt.
  • Organisationen, die unterschiedliche Arten oder Klassen von digitalen Zertifikaten ausgeben, markieren jedes Zertifikat je nach seiner Klasse. Das Identifizieren eines Zertifikats als zu einer bestimmten Klasse gehörig ist dann eine Sache des Wissens, wie verschiedene Organisationen ihre Zertifikate klassifizieren, und des Suchens nach dem entsprechenden Indikator in dem empfangenen Zertifikat.
  • Aussteller von digitalen Zertifikaten können viele verschiedene, für verschiedene Zwecke geeignete Zertifikatklassen bereitstellen. Mit diesen können sich Richtliniendaten separat nach entsprechenden Unterzweigen des Richtliniendatenbaums befassen.
  • In dem Beispiel befasst sich die Richtlinie des ersten Zweigs namens ,IdentityCertificates' mit Übertragungen, die keine monetäre Transaktion involvieren. Der Zweig umfasst vier separate Unterzweige. Der erste davon, ,AlwaysAcceptFrom', enthält einen Verweis auf eine Tabelle, ,Tabelle a', die die Namen von Personen und Organisationen aufführt, die als zuverlässig angesehen werden. Die in dieser Tabelle aufgeführten Namen sind diejenigen, die dem Unternehmen bekannt sind und denen das Unternehmen ausdrücklich vertraut, für die es nicht als notwendig erachtet wird zu ermitteln, ob ein digitales Zertifikat von seinem Aussteller widerrufen wurde oder nicht.
  • Der zweite Zweig, ,AlwaysCheckFrom', enthält einen Verweis auf eine separate Tabelle, Tabelle b, in der die Namen von Organisationen und Personen gespeichert sind, für die digitale Zertifikate immer geprüft werden sollen. Der Inhalt von Tabelle a und Tabelle b hängt natürlich immer von der Erfahrung des Benutzers des bevorzugten Systems ab und es liegt am Benutzer, sie auszufüllen.
  • Der dritte Zweig, ,CheckIfDaysSince CertificateReceivedFromCompany', gibt eine Zeitperiode nach dem Empfang eines gültigen digitalen Zertifikats von einem Unternehmen vor, innerhalb derer Checks weiterer von diesem Unternehmen empfangener digitaler Zertifikate nicht als notwendig erachtet werden. In diesem Fall ist die Zeitperiode auf 10 Tage eingestellt.
  • Der vierte Zweig, ,CheckIfDaysSince LastReceivedThisCertificate', gibt eine ähnliche Zeitperiode im Falle eines individuellen digitalen Zertifikats vor. In dem gezeigten Beispiel geben die Richtliniendaten vor, dass Validierungschecks an einem gegebenen digitalen Zertifikat nur alle 30 Tage vorgenommen zu werden brauchen. Auch hier liegt es wieder am Benutzer des bevorzugten Systems, die Anzahl der Tage zu entscheiden, die auf beiden diesen Zweigen vorgegeben werden. Die Zeitmenge, die seit dem Empfang eines gültigen digitalen Zertifikats verstrichen ist, kann durch Bezugnahme auf digitale Zertifikate und assoziierte Daten bestimmt werden, die in der Datenbank gespeichert sind.
  • Indem digitale Zertifikate periodisch und nicht bei jedem Empfang geprüft werden, kann für die Durchführung von Checks ausgegebenes Geld eingespart werden.
  • Der MonetaryCertificate-Zweig enthält auch einen AlwaysAcceptFrom- und einen AlwaysCheckFrom-Zweig, die jeweils auf Tabelle x und y verweisen. Tabelle x führt alle Organisationen und Personen auf, für die kein Statuscheck eines digitalen Zertifikats erforderlich ist; Tabelle y führt alle die auf, für die ein Check immer erforderlich ist. Der MonetaryCertificate-Zweig enthält auch einen CheckIfAmountExceeds-Zweig, der einen Transaktionsschwellenbetrag vorgibt, jenseits dessen alle digitalen Zertifikate geprüft werden müssen, und schließlich einen IfRecentlyChecked-Zweig, der zwei Bedingungen zum Ausführen von Checks an einem digitalen Zertifikat darlegt, das kürzlich empfangen und validiert wurde. Der IfRecentlyChecked-Zweig gestattet es dem Benutzer vorzugeben, dass für Transaktionen für einen geringen Betrag, in diesem Fall $5000, empfangene digitale Zertifikate, die innerhalb eines vorgegebenen Zeitraums, in diesem Fall 30 Tage, nach einem vorherigen Widerrufcheck, nicht validiert zu werden brauchen.
  • 11 illustriert den Einsteckmodulprozess, der mit den in 9 gezeigten Richtliniendaten interagiert. Dieser Prozess ist ein Subprozess des in 8 gezeigten, der in Schritt S204 abläuft und zum Entscheidungsschritt S206 führt, in dem das Einsteckmodul ermittelt, ob ein Online-Check des Status des empfangenen digitalen Zertifikats ausgeführt werden soll oder nicht. Der Subprozess beginnt in Schritt S220, von dem die Steuerung weiter zum Entscheidungsschritt S222 geht, in dem anhand der Klasse des zum Signieren der Nachricht verwendeten digitalen Zertifikats ermittelt wird, ob die Übertragung monetär ist. Wenn es sich um eine monetäre Übertragung handelt, dann geht die Steuerung zum Entscheidungsschritt S232, der der erste in einer Kette von Entscheidungsschritten ist, die den Zweigen im MonetaryCertificates-Zweig des AcceptanceConfidenceRating-Zweigs der Richtliniendaten entsprechen.
  • Wenn in Schritt S222 ermittelt wird, dass die Übertragung nicht monetär ist, dann geht die Steuerung zum Entscheidungsschritt 224, d. h. dem ersten Entscheidungsschritt in einer Kette von Entscheidungsschritten, die den IdentityCertificates-Zweigen des AcceptanceConfidenceRating-Zweigs der Richtliniendaten entsprechen. In jedem der Entscheidungsschritte in der Kette wird ein einfacher Check durchgeführt, um zu prüfen, ob die auf jedem Unterzweig des IdentityCertificates-Zweigs der Richtliniendaten vorgegebenen Bedingungen erfüllt sind. Je nach den Ergebnissen dieses Checks geht die Steuerung entweder zu Schritt 242, wo das Vertrauen in das digitale Zertifikat festgestellt und kein Online-Check des Status des digitalen Zertifikats als notwendig erachtet wird, oder zu Schritt S244, wo das Vertrauen nicht festgestellt wird und ein Online-Check als notwendig erachtet wird, oder zum nächsten Entscheidungscheck in der Kette.
  • So geht die Steuerung vom Entscheidungsschritt S224, wo ermittelt wird, ob der Sender des digitalen Zertifikats in Tabelle a aufgeführt ist, d. h. der ,AlwaysAcceptFrom'-Tabelle, wenn der Sender des digitalen Zertifikats in Tabelle a aufgeführt ist, zu Schritt S242, wo das Vertrauen in das Zertifikat festgestellt wird, und der Subprozess endet mit der Rückkehr zu Schritt S208 in 8. Wenn der Sender in Tabelle a nicht aufgeführt ist, dann geht die Steuerung von Schritt S224 zum nächsten Entscheidungsschritt in der Kette, Schritt S226, in dem ermittelt wird, ob der Sender des digitalen Zertifikats in Tabelle b aufgeführt ist, d. h. in der ,AlwaysCheckFrom'-Tabelle. Ebenso geht die Steuerung, wenn der Sender in dieser Tabelle aufgeführt ist, zu Schritt S244, wo ein Online-Check des Status des digitalen Zertifikats als notwendig erachtet wird. Die Steuerung kehrt von Schritt S244 im Subprozess zu Schritt S210 in 8 zurück.
  • Wenn der Sender des digitalen Zertifikats nicht in Tabelle b aufgeführt ist, dann geht die Steuerung vom Entscheidungsschritt S226 zum nächsten Entscheidungsschritt in der Kette weiter, der die nächste in den Richtliniendaten als Unterzweig aufgeführte Bedingung repräsentiert. So wird im Entscheidungsschritt S228 geprüft, ob dieses digitale Zertifikat in den letzten 30 Tagen validiert wurde. Dies beinhaltet das Nachschlagen des digitalen Zertifikats in der Datenbank von gespeicherten digitalen Zertifikaten und das Extrahieren des Datums aus den gespeicherten Informationen, an dem das digitale Zertifikat zuletzt geprüft wurde. Wenn der Status des digitalen Zertifikats in den letzten 30 Tagen geprüft wurde, dann geht die Steuerung zu Schritt S242, wo das Vertrauen festgestellt wird. Wenn die Informationen in der Datenbank von gespeicherten digitalen Zertifikaten anzeigen, dass das digitale Zertifikat in den letzten 30 Tagen nicht geprüft wurde, dann geht die Steuerung von Schritt S228 zum Entscheidungsschritt S230, wo geprüft wird, ob ein anderes digitales Zertifikat von demselben Unternehmen empfangen wurde und ob dieses digitale Zertifikat innerhalb der letzten 10 Tage geprüft wurde. Diese Ermittlung beinhaltet wiederum das Prüfen der Datenbank von gespeicherten digitalen Zertifikaten und von Informationen über diese digitalen Zertifikate. Wenn das andere digitale Zertifikat in den letzten 10 Tagen geprüft wurde, dann geht die Steuerung zu Schritt S242, wo das Vertrauen in das empfangene digitale Zertifikat festgestellt wird. Wenn nicht, dann geht die Steuerung zu Schritt S244.
  • Im Falle einer monetären Übertragung werden die in den Richtliniendaten dargelegten Bedingungen schrittweise in den Entscheidungsschritten S232 bis S240 durchlaufen. Wenn der Sender des digitalen Zertifikats im Entscheidungsschritt S232 nicht in Tabelle x gefunden wird, die die Namen von Unternehmen und Organisationen aufführt, für die keine Prüfung des Status des digitalen Zertifikats als notwendig erachtet wird, dann wird das Vertrauen festgestellt und die Steuerung geht zu Schritt S242. Ansonsten geht die Steuerung zum nächsten Entscheidungsschritt in der Kette, nämlich Entscheidungsschritt S234. Im Entscheidungsschritt S234 wird, wenn der Sender des digitalen Zertifikats nicht in Tabelle b, d. h. der ,AlwaysCheckFrom'-Tabelle, gefunden wird, das Vertrauen nicht festgestellt und die Steuerung geht zu Schritt S244. Ansonsten geht die Steuerung zum Entscheidungsschritt S236, wo ermittelt wird, ob der Betrag, für den die Transaktion durchgeführt wird, $10.000 übersteigt. Diese Ermittlung erfolgt mit Bezug auf die signierten Transaktionsdaten, die den Geldbetrag enthalten, entweder auf eine vom Aussteller des Zertifikats vorbestimmte Weise oder in der Email oder in assoziierten, die Transaktion bildenden Emails oder Übertragungen enthalten. Wenn gefunden wird, dass die Transaktion für einen Betrag von mehr als $10.000 ist, oder wenn der Betrag der Transaktion nicht anhand der übertragenen Daten festgestellt werden kann, dann wird das Vertrauen nicht festgestellt und die Steuerung geht zu Schritt S244.
  • Ansonsten geht die Steuerung zum Entscheidungsschritt S238, wo ermittelt wird, ob das digitale Zertifikate innerhalb der letzten 30 Tage geprüft wurde. Auch diese Ermittlung erfolgt wieder mit Bezug auf die Datenbank von gespeicherten digitalen Zertifikaten und Daten über digitale Zertifikate. Wenn das Zertifikat nicht innerhalb der letzten 30 Tage geprüft wurde, dann wird das Vertrauen nicht festgestellt und die Steuerung geht zu Schritt S244. Wenn es geprüft wurde, geht die Steuerung zum Entscheidungsschritt S240, wo, wenn der zuvor ermittelte Betrag der Transaktion als über $5000 liegend ermittelt wurde, das Vertrauen nicht festgestellt wird und die Steuerung zu Schritt S244 geht. Wenn der Betrag der Transaktion unter $5000 liegt, dann wird dies als ein akzeptables Risiko eingestuft, sich auf das digitale Zertifikat zu verlassen, das Vertrauen wird festgestellt und die Steuerung geht zu Schritt S242.
  • Diese beiden letzten Bedingungen erlauben es dem System, auf der Basis der kürzlichen Handelshistorie zu ermitteln, ob der Status des Zertifikats geprüft werden soll oder nicht. Wenn beispielsweise eine Transaktion von einer Partei für eine mäßige Summe durchgeführt werden soll, d. h. unter $5000, und die Suche nach der aufgezeichneten Transaktion und den Zertifikat-Details zu Tage bringt, dass vor relativ kurzer Zeit dieselbe Partei eine Transaktion durchgeführt hat und dabei ihr digitales Zertifikat als gültig festgestellt wurde, dann könnte man argumentieren, dass eine nochmalige Prüfung der Validität des Zertifikats der Partei so bald nach der ersten unnötig ist, und man wird bevorzugen, der Partei zu vertrauen, anstatt die Validierungsgebühr ein zweites Mal zu bezahlen.
  • Man wird verstehen, dass die Befehle in der Richtliniendatei so gestaltet werden können, dass sie das Vertrauensniveau reflektieren, das das Unternehmen in seine Kunden oder Lieferanten hat, auf der Basis der Erfahrungen von Personen innerhalb des Unternehmens, der Transaktionsbeträge, die ohne signifikantes Risiko als zulässig angesehen werden usw. Die Richtliniendatei kann auch zum Implementieren allgemeinerer Richtlinien eingerichtet werden, die in Verbindung mit einer Aufzeichnung von Transaktionsdetails für den Inhaber dieses digitalen Zertifikats verwendet werden sollen. So kann beispielsweise jede Transaktion, die vom Inhaber angeboten wird, mit dem Datensatz von den zuvor von ihm getätigten verglichen werden, um zu sehen, ob der Betrag und die bestellten Waren und Dienste mit seiner Handelshistorie im Einklang stehen. Wenn nicht, dann kann es wünschenswert sein, die Validität des Zertifikats zu prüfen, um zu bestätigen, dass es noch gültig ist und die Identität des Senders garantiert. Wenn es widerrufen wurde, dann hat sich möglicherweise eine Drittpartei den Private-Key des ursprünglichen Inhabers beschafft und versucht, betrügerische Transaktionen durchzuführen.
  • Nach dem Prüfen der Richtliniendaten in Schritt S204 wurde entweder das Vertrauen in das digitale Zertifikat festgestellt oder auch nicht. Im Entscheidungsschritt S206 geht die Steuerung, wenn das Vertrauen festgestellt wurde, zu Schritt S208, wo die die Transaktion enthaltende Übertragung akzeptiert wird. Die Steuerung geht dann zu Schritt S200, wo das Modul die Routine verlässt und die Steuerung zu Punkt A in 3 im Falle eines Webbrowsers oder zu Punkt A in 5 im Falle eines Email-Client geht.
  • Wenn in Schritt S206 das Vertrauen in das digitale Zertifikat nicht festgestellt wird, dann geht die Steuerung zu Schritt S210, wo ein Online-Validierungscheck an dem digitalen Zertifikat durchgeführt wird: Dies kann die Prüfung beinhalten, ob das digitale Zertifikat widerrufen wurde oder ob, im Falle einer eCommerce-Transaktion, der Ausgeber des digitalen Zertifikats eine Gewährleistung für den in der Transaktion versprochenen Betrag bestätigt. Die Steuerung geht als Nächstes weiter zu Schritt S212, wo der in der Datenbank für dieses Zertifikat gespeicherte Validitätsstatus auf den neuesten Standgebracht wird. Die Steuerung geht dann zum Entscheidungsschritt S214, wo die Steuerung, wenn das Zertifikat als ungültig gefunden wird, zu Schritt S198 geht, wo die Übertragung abgelehnt wird, oder zu Schritt S208, wo die Übertragung akzeptiert wird. Eine Ablehnung der Übertragung kann bedeuten, dass sie aus der Mailbox des Empfängers gelöscht wird, bevor sie geöffnet wird, oder dass die Übertragung mit dem Wort ,abgelehnt' oder einem anderen Indikator markiert wird. Nach Schritt S198 oder S208 geht die Steuerung zu Schritt S200, wo das Modul die Routine verlässt. Wann immer eine Transaktion zugelassen wird, wird die Datenbank so aktualisiert, dass sie Informationen über die Transaktion wie z. B. Datum und Betrag enthält, damit die Informationen beim Ermitteln der Notwendigkeit für weitere Validierungschecks benutzt werden können.
  • Aufzeichnung von Informationen
  • Das bevorzugte System bietet auch einen Weg, um Transaktionsinformationen für online durchgeführte Transaktionen automatisch aufzuzeichnen. In diesem Zusammenhang sollen die Begriffe ,Transaktion' und ,eCommerce-Transaktion' eine Vereinbarung zwischen zwei Parteien über das Internet oder sogar über dasselbe Netzwerk eines Unternehmens bedeuten, in der Geld oder ein Geldwert versprochen wird. Normalerweise ist der Benutzer selbst zum Führen von Transaktionsinformationen verantwortlich, indem er Papierkopien der relevanten elektronischen Datensätze anfertigt oder indem er aktiv Kopien eventueller elektronischer Datensätze in Dateien auf seinem Computer speichert. Die Abhängigkeit von manuellen Methoden, um das Führen solcher Aufzeichnungen zu gewährleisten, ist eindeutig sowohl unzuverlässig als auch arbeitsaufwändig.
  • Das bevorzugte System andererseits sucht den Informationsgehalt aller vom System verarbeiteten Kommunikationen nach Anzeichen dafür ab, dass eine Transaktion begonnen hat oder stattfindet. Es gibt viele solcher Anzeichen. Das einfachste ist das, ob die Verbindung sicher ist oder nicht, da die meisten Webseiten vor dem Durchführen einer Transaktion eine sichere Verbindung negoziieren und diese Verbindung danach wieder schließen. Die Ermittlung, ob eine Verbindung sicher ist, erfolgt durch Untersuchen der URL-Adresse der Zielwebseite. Eine sichere Verbindung wird durch ein ,s' nach dem Präfix ,http' angezeigt. So besteht eine Betriebsart des bevorzugten Systems darin, alle zu einer Webseite gesendeten Seiten aufzuzeichnen, während eine Verbindung sicher ist. Das bevorzugte System führt auch Aufzeichnungen über Webseiten, die sichere Verbindungen negoziieren, aber keine eCommerce-Sites sind, d. h. solche, die zu anderen Zwecken als für Käufe angeschlossen sind und die keine zu diesen Seiten übertragenen Daten aufzeichnen. Eine solche Webseite könnte die Notmail-Webseite von Microsoft sein, die einen Email-Dienst bereitstellt.
  • Ein anderes Anzeichen könnte einfach die URL-Adresse der Site sein. In diesem Fall kann das bevorzugte System so konfiguriert werden, dass es alle zu einer Webseite übertragenen Daten aufzeichnet, die als die eines Online-Handelsunternehmens identifiziert wurden. Andere Anzeichen könnten eine identifizierte Kreditkartennummer, eine elektronische Quittung, eine Email-Bestätigung des Verkaufs, die Verwendung eines digitalen Zertifikats, insbesondere eines digitalen Garantiezertifikats, oder ein Kaufcode sein.
  • Wenn der Ablauf einer Transaktion identifiziert wurde, dann kann das bevorzugte System die Details der Transaktion sowohl durch Speichern der Gesamtheit jeder Kommunikation zwischen einem Benutzer und dem identifizierten Händler oder durch Scannen der Übertragungen und Extrahieren bestimmter Details wie z. B. Datum, Betrag, Warentyp, Menge usw. aufzeichnen.
  • Das Aufzeichnen von Transaktionsdaten kann gestoppt werden, wenn das Ende der Transaktion identifiziert wird oder wenn eine vordefinierte Anzahl von Übertragungen zwischen dem Käufer und dem Händler stattgefunden hat. Ebenso kann das bevorzugte System, wenn eine Transaktion identifiziert wurde, in der Datenbank eine vordefinierte Anzahl von gecachten Übertragungen aufzeichnen, die unmittelbar vor der ersten erkannten Übertragung der Transaktion stattgefunden haben.
  • Dies ist dann nützlich, wenn beispielsweise das erste Anzeichen dafür, dass eine Übertragung stattfindet, die Erkennung einer Kreditkartennummer oder einer elektronischen Quittung ist, da diese wahrscheinlich ganz am Ende einer Transaktion empfangen werden. Die vorherigen Übertragungen können beispielsweise aus Webseiten bestehen, die Informationen über die gekauften Waren oder Dienste enthalten, oder ein Austausch von Emails, wo Spezifikationen oder Lieferbedingungen vereinbart wurden. Man beachte, dass es vollkommen möglich ist, dass frühere Übertragungen vom selben Typ sind wie die, in denen die Transaktion erkannt wurde, oder von einem anderen Typ oder eine Mischung von Typen. So könnte beispielsweise ein Benutzer eine Website www.abc.com besuchen, Details von Waren einholen und diese dann in einer zu Orders@abc.com gesendeten Email bestellen.
  • Das bevorzugte System zeichnet die Transaktionsdetails in einer zentralisierten gemeinsamen Datenbank 42 auf. Zusätzlich kann die Datenbank eine lokale Datei oder ein Dienst auf einem Netzwerk sein. Die in der Datenbank gespeicherten Informationen können mit bekannten Verschlüsselungstechniken verschlüsselt werden, so dass nur eine Person mit ausreichender Autorisierung darauf zugreifen kann.
  • 12 ist eine Darstellung des Ablaufs eines Ausführungsbeispiels für ein Modul zum Identifizieren, wann eine elektronische Transaktion online durchgeführt wird. 14 illustriert den Vorgang, mit dem das bevorzugte System eine identifizierte Transaktion in der Datenbank aufzeichnet, und 15 illustriert, wie das bevorzugte System es zulässt, dass eine identifizierte Transaktion auf der Basis einer vorbestimmten Zulassungsrichtlinie zugelassen oder abgelehnt wird.
  • Als Nächstes wird mit Bezug auf 12 der Betrieb eines Moduls zum Identifizieren beschrieben, wann eine Online-Transaktion stattfindet.
  • Das Modul beginnt den Betrieb in Schritt S250 als Reaktion auf den Empfang von Daten oder als Reaktion darauf, dass ein Benutzer die Übertragung von Daten zu einem fernen Ort einleitet. Im Falle einer Webbrowser-Implementation ist dies nach Punkt A bzw. nach Punkt C, wie in 3 gezeigt; bei einer Implementation in einem Email-Client ist dies nach Punkt A bzw. B, wie in 5 gezeigt.
  • Die Steuerung geht dann zum Entscheidungsschritt S252, wo ermittelt wird, ob, im Falle eines Webbrowsers, eine sichere Verbindung zwischen der Daten übertragenden Site und der Daten empfangenden Site negoziiert wurde. Dies kann durch Abfragen der URL-Adresse erzielt werden, mit der die Verbindung aufgenommen wurde, wie oben erwähnt, oder durch Abfragen des Webbrowsers, um zu sehen, ob verschlüsselt wird. Bei einer Email-Nachricht fällt dieser Schritt weg und die Steuerung geht direkt zu Schritt S260. Da Online-Webbrowser-Transaktionen gewöhnlich die Übertragung von persönlichen Informationen wie Name und Adresse, Kreditkartennummer oder andere Kontokenninformationen beinhalten, werden sichere Verbindungen gewöhnlich ganz selbstverständlich negoziiert. So ist die Anwesenheit einer sicheren Verbindung allein ein guter Hinweis darauf, dass eine Transaktion stattfindet. Sichere Verbindungen können jedoch auch aus anderen Gründen als die Übertragung von Transaktionsdetails negoziiert werden. Wenn also in Schritt S252 festgestellt wird, dass die Verbindung sicher ist, dann geht die Steuerung zu Schritt S254, wo die Adresse der fernen Site, mit der die Verbindung hergestellt wurde, anhand einer Liste bekannter Sites geprüft wird, die keine Einrichtungen zum Durchführen von Online-Transaktionen bieten, aber die sichere Verbindungen herstellen. Browsergestützte Email-Sites wie z. B. die Hutmail-Site von Microsoft sind ein solches Beispiel. Die Steuerung geht dann zum Entscheidungsschritt S256, wo eine Ermittlung auf der Basis des vorherigen Checks erfolgt. Wenn die Site-Adresse als Non-eCommerce-Site identifiziert wird, d. h. eine, die die Ausführung einer Transaktion nicht ermöglicht, dann wird festgestellt, dass eine Transaktion möglicherweise stattfindet oder nicht, und die Steuerung geht zum Entscheidungsschritt S260, um weitere Checks über den Inhalt der Übertragung durchzuführen. Wenn in Schritt S256 die Site-Adresse nicht als eine bekannte Non-eCommerce-Site identifiziert wird, dann wird davon ausgegangen, dass eine Online-Transaktion stattfindet, und das Modul verlässt die Routine bei Schritt S258.
  • Wenn in Schritt S252 gefunden wird, dass keine sichere Verbindung hergestellt wurde, oder wenn eine sichere Verbindung hergestellt wurde, aber mit einer bekannten Non-eCommerce-Site gemäß Ermittlung in Schritt S256, oder wenn die Übertragung eine Email ist, dann geht die Steuerung zum Entscheidungsschritt S260. Im Entscheidungsschritt S260 erfolgt der erste einer Reihe von Checks über den Inhalt der Übertragung, um zu ermitteln, ob sie Teil einer Transaktion ist oder nicht. In Schritt 260 wird die Übertragung gescannt, um zu sehen, ob sie eine Kreditkartennummer enthält. Das Verfahren hierfür wurde mit Bezug auf 8 beschrieben. Wenn in der Übertragung eine Kreditkartennummer gefunden wird, dann wird davon ausgegangen, dass eine Transaktion stattfinden muss, und die Steuerung geht zu Schritt S258, wo das Modul die Routine verlässt. Wenn keine Kreditkartennummer gefunden wird, dann geht die Steuerung stattdessen zum Entscheidungsschritt S262, wo die Übertragung gescannt wird, um zu sehen, ob sie einen Kontocode enthält. Kontocodes können (zum Beispiel) in einer separaten Datei gespeichert werden, auf die das Modul bei der Ausführung dieses Schrittes zugreift, oder alternativ kann ein Kontocode anhand von beschreibenden Daten in der Übertragung identifiziert werden, wie z. B. ein Feldname wie ,Kontonummer' oder ähnliche Zeichen, die im Text einer Nachricht erscheinen.
  • Wenn im Entscheidungsschritt S262 ein Kontocode gefunden wird, dann wird davon ausgegangen, dass die Übertragung Teil einer Transaktion ist, und die Steuerung geht zu Schritt S258, wo das Modul die Routine verlässt. Wenn kein Kontocode gefunden wird, dann geht die Steuerung zu Schritt S264, wo im Falle eines Webbrowsers die URL-Adresse mit einer Liste von bekannten, in einer Datei oder in einer Datenbank gespeicherten eCommerce-URL-Adressen verglichen wird. Im Entscheidungsschritt S266 erfolgt eine Ermittlung an diesem Vergleich. Wenn gefunden wird, dass die URL-Adresse auf einer bekannten eCommerce-Seite oder Teil eines bekannten Satzes von eCommerce-Seiten ist, dann wird festgestellt, dass eine eCommerce-Transaktion stattfindet, und die Steuerung geht zu Schritt S258, wo das Modul die Routine verlässt. Ebenso kann, bei einer Email, die Zieladresse mit einer Liste bekannter eCommerce-Email-Adressen verglichen werden, z. B. ,orders@abc.com', und im Falle einer Übereinstimmung wird festgestellt, dass eine eCommerce-Transaktion stattfindet, und die Steuerung geht zu Schritt S258, wo das Modul die Routine verlässt.
  • Die soeben beschriebenen Checks sind lediglich für die möglichen Checks repräsentativ, die vorgenommen werden könnten, um zu ermitteln, ob eine Übertragung wahrscheinlich Teil einer eCommerce-Transaktion ist oder nicht, und sollen nicht erschöpfend sein. Ferner hat die Reihenfolge, in der die Checks illustriert wurden, keine besondere Bedeutung. Die Reihenfolge ist lediglich von der Struktur der Richtliniendaten abhängig, wie mit Bezug auf 13 ersichtlich ist.
  • In Schritt S268 ist ein allgemeiner Check illustriert, der zusätzlich zu den oben beschriebenen eventuelle weitere Checks nach einem Hinweis auf eine Transaktion repräsentiert, die ein Unternehmen als wünschenswert ansieht, wie z. B. die Suche nach Kaufcodes oder eingebetteten Codes in den Daten. Es wird bevorzugt, dass es der Webbrowser oder der Email-Client, der im bevorzugten System verwendet wird, dem Benutzer erlaubt, Übertragungen mit einem eingebetteten Code zu markieren, um anzuzeigen, dass die Übertragung Teil einer Transaktion und aufzuzeichnen ist. Auch könnte der eingebettete Code dadurch in die Daten gesetzt werden, dass die Website oder der Email-Client einige der Transaktionsdaten zur Workstation des Benutzers sendet.
  • Die Steuerung geht nach Schritt S266 zu diesem Schritt, wenn die Site nicht als bekannte eCommerce-Site erkannt wird, und wenn ein solcher Transaktionsindikator in Schritt S268 gefunden wird, dann wird festgestellt, dass eine Transaktion stattfindet und die Steuerung geht zu Schritt S258, wo das Modul die Routine verlässt. Wenn in Schritt S268 kein solcher Indikator gefunden wird, dann wird davon ausgegangen, dass keine Transaktion stattfindet, und das Modul verlässt die Routine in Schritt S258. Nach dem Verlassen können die Daten nach Punkt C und B in 3 bzw. 5 übertragen oder nach ihrem Empfang an Punkt A in den 3 und 5 verarbeitet werden.
  • Ziel in dem beschriebenen Beispiel ist es, das Aufzeichnen von Übertragungen und möglichen Transaktionsdetails zu beginnen, wenn auch nur der Verdacht besteht, dass eine Transaktion stattfindet. Es wird davon ausgegangen, dass es vorzuziehen ist, Daten aufzuzeichnen, auch wenn sie nicht Teil einer Transaktion sind, anstatt eine Transaktion überhaupt nicht aufzuzeichnen. 13 ist eine Illustration der Richtliniendaten, die zum Identifizieren verwendet werden, dass eine eCommerce-Transaktion stattfindet, und um die Art und Weise zu steuern, in der die Transaktionsdaten aufgezeichnet werden. Die Richtliniendaten werden durch einen Transaktionszweig des Richtliniendatenbaums repräsentiert, der in zwei separate Unterzweige mit der Bezeichnung ,Identification' und ,Termination' unterteilt wird. Der Identification-Zweig wiederum ist in fünf Unterzweige unterteilt, die den Feststellungen entsprechen, die in dem in 12 illustrierten Prozess vorgenommen wurden. Der erste dieser Unterzweige mit der Bezeichnung ,IfConnectionGoesSecure' erlaubt es einem Benutzer vorzugeben, ob die Aufzeichnung beginnen soll, wenn das Einsteckmodul erfasst, dass die Verbindung zum Webserver sicher geworden ist. Die auf diesem Unterzweig vorgegebene Bedingung entspricht dem in 12 gezeigten Entscheidungsschritt S252. Man wird mit Bezug auf die 12 und 13 verstehen, dass der in 12 gezeigte Steuerfluss dem Layout der Bedingungen entspricht, die auf den in 13 gezeigten Zweigen des Richtliniendatenbaums vorgegeben sind. Der ExcludedSites-Zweig des IfConnectionGoesSecure-Zweigs enthält einen Verweis auf eine Tabelle q, in der die Websites aufgeführt sind, die bekanntlich sichere Sites negoziieren, von denen aber bekannt ist, dass sie keine eCommerce-Websites sind. Auf Tabelle q wird in Schritt S256 des in 12 gezeigten Prozesses verwiesen.
  • Der nächste Unterzweig des Identification-Zweigs heißt ,IfCreditCardNumberPresent' und erlaubt es dem Benutzer vorzugeben, ob die Erfassung einer Kreditkartennummer zum Einleiten des Aufzeichnens von übertragenen oder empfangenen Daten verwendet werden soll oder nicht. Dieser Unterzweig entspricht dem Entscheidungsschritt S260. Der PreviousPages-Unterzweig des IfCreditCardNumberPresent-Zweigs führt die Zahl von Webseiten vor der Webseite auf, in der die Kreditkartennummer erfasst wurde, die ebenfalls aufzuzeichnen sind. Da Kreditkartennummern normalerweise am Ende der Transaktion submittiert werden, können mit diesem Unterzweig vorherige Webseiten, die wahrscheinlich die Details und die Anforderung der Transaktion enthalten, abgerufen und gespeichert werden. Diese Webseiten werden kontinuierlich durch das bevorzugte System gecacht, so dass im Falle der Identifikation einer Transaktion diese aus dem Cache abgerufen und in der Datenbank gespeichert werden kann. Dies wird mit Bezug auf 14 näher erläutert.
  • Der nächste Unterzweig des Identification-Zweigs heißt ,IfAccountsCodePresent' und ermöglicht es einem Benutzer vorzugeben, ob die Erkennung eines Kontocodes in den übertragenen oder empfangenen Daten als ein Indikator zum Einleiten des Aufzeichnens der Daten anzusehen ist. Die Kontocodes werden in dem in 12 gezeigten Schritt S262 durch Verweis auf Tabelle r identifiziert. Der Verweis auf diese Tabelle befindet sich im AccountCodes-Unterzweig des IfAccountCodePresent-Zweigs. Man beachte, dass diese Tabelle auch die Zahl vorheriger aufzuzeichnender Seiten ähnlich wie die oben für die Kreditkartenidentifikation beschriebene zeigt, aber in diesem Fall wird die Zahl der aufzuzeichnenden vorherigen Seiten in Tabelle r gespeichert, so dass eine andere Anzahl von Seiten für jeden erfassten Kontencode vorgegeben werden kann.
  • Mit dem IfKnownECommerceSite-Zweig kann der Benutzer eine Liste von Sites, Teilen von Sites oder sogar einzelnen Seiten entsprechenden URL-Adressen erstellen, wo bekanntlich eCommerce-Transaktionen stattfinden. Die URL-Adresse der aktuellen Seite wird mit Einträgen in dieser Liste verglichen, um zu ermitteln, ob eine Transaktion stattfindet. Der KnownSites-Unterzweig enthält einen Verweis auf Tabelle s, in der die URL-Adressen bekannter eCommerce-Sites gespeichert sind. Die Ermittlung, ob die URL-Adresse der Website eine bekannte eCommerce-Site ist, erfolgt im Entscheidungsschritt S266 nach Schritt S264 von 12. Schließlich bietet der IfOtherIndicatorPresent-Zweig dem Benutzer eine Möglichkeit, um vorzugeben, ob die Ermittlung anderer Indikatoren als Anfangspunkt für das Aufzeichnen von Daten benutzt werden soll oder nicht. Zwei Unterzweige dieses Zweigs namens Keywords und PreviousPages geben mögliche erkennbare Indikatoren an, in diesem Fall die in Tabelle t aufgeführten Schlüsselwörter, und auch die Zahl der vorherigen Seiten, die gespeichert werden müssen, wenn Schlüsselwörter erkannt werden.
  • Der Termination-Zweig des Transactions-Zweigs teilt sich in vier Unterzweige auf, die Bedingungen zum Beenden des Aufzeichnens von gesendeten oder empfangenen Daten angeben. Jeder Unterzweig gibt eine Bedingung an, anhand derer das Ende der Transaktion definiert werden kann. Mit dem ersten Zweig, ,IfConnectionGoesInsecure', kann der Benutzer vorzugeben, dass das Aufgeben einer sicheren Verbindung durch den Webbrowser das Ende einer Transaktion anzeigt, so dass die Aufzeichnung gestoppt werden sollte. Die anderen Unterzweige geben vor, dass die Aufzeichnung jeweils zu stoppen ist, wenn sich die Website ändert, wenn eine digitale Quittung empfangen wird, sowie nach dem Empfang von 20 Webseiten nach der Identifikation, dass eine Transaktion stattfindet.
  • Es muss hervorgehoben werden, dass Richtliniendaten, die insbesondere in diesem Diagramm, aber auch in den anderen Diagrammen dargestellt sind, für jeden Benutzer individuell sind. Ein Benutzer kann nicht nur vorgeben, ob auf bestimmte Bedingungen zu reagieren ist oder nicht, indem er die Ja- oder Nein-Variable entsprechend einstellt oder z. B. die Anzahl der Seiten ändert, die aufgezeichnet werden sollen, sondern auch die Struktur und Anordnung von Zweigen und die auf diesen Zweigen vorgegebenen Bedingungen können sich von Benutzer zu Benutzer unterscheiden. Man wird verstehen, dass das Richtlinienbeispiel zwar das Aufzeichnen von Transaktionen in einer Webbrowser-Umgebung beschreibt, aber eine ähnliche Richtlinie würde auch die Email-Umgebung steuern, die Sichere-Verbindung-Option weglassen, aber die Definition einer Richtlinie zum Aufzeichnen von Emails nach dem Erkennen von Kreditkartennummern, Kontocodes oder anderen identifizierbaren Informationen darin zulassen, oder wo Emails zu bekannten eCommerce-Adressen gesendet werden.
  • Von dem Verfahren zum Identifizieren einer Transaktion kann dann voll profitiert werden, wenn das Verfahren zusammen mit Mitteln zum Aufzeichnen von Übertragungen zwischen einem Benutzer des bevorzugten Systems und einer fernen Site angewendet wird. So können Aufzeichnungen aller von einem Benutzer ausgeführten Transaktionen automatisch geführt werden. Die Datensätze können auf dem neuesten Stand gehalten werden, ohne Papierkopien jeder empfangenen oder gesendeten Übertragung anfertigen zu müssen. Dies macht die Buchführung eines Unternehmens wesentlich einfacher und genauer.
  • 14 illustriert den Betrieb eines Moduls zum Aufzeichnen von Übertragungen, die eine Transaktion umfassen. Das Modul beginnt in Schritt S270.
  • Wenn das Modul als Teil eines Webbrowsers implementiert wird, dann beginnt Schritt S270 in Punkt A in 3 nach dem Empfang von Daten oder nach Punkt C in 3 unmittelbar vor dem Senden von Daten zu einer fernen Site. Bei einer Implementation des Moduls als Teil eines Email-Client erfolgt Schritt S270 nach Punkt A in 5, nachdem eine Email empfangen wurde, oder nach Punkt B in 5, unmittelbar bevor eine vom Benutzer verfasste Email zu einem Empfänger gesendet wird.
  • Nach Schritt S270 geht die Steuerung zu Schritt S272, wo der Test zum Identifizieren einer Transaktion, oben mit Bezug auf 9 beschrieben, durchgeführt und ermittelt wird, ob eine eCommerce-Transaktion stattfindet oder nicht. Die Steuerung geht dann zum Entscheidungsschritt S274, wo nach der Feststellung, dass keine Transaktion stattfindet, die Steuerung direkt zu Schritt S276 geht, wo das Modul die Routine verlässt.
  • Wenn jedoch festgestellt wird, dass eine Transaktion stattfindet, dann geht die Steuerung zu Schritt S278, wo die Richtlinie anhand eines oder mehrerer Erkennungsmittel, die Identität des Senders, der Betrag der Transaktion geprüft wird, oder andere Parameter zum Bestimmen, welche vorherigen Übertragungen ggf. mit der identifizierten Übertragung gespeichert werden sollten und wie detailliert die Übertragung aufgezeichnet werden soll. Die Richtlinie könnte beispielsweise verlangen, dass eine Transaktion für eine große Geldsumme ausführlicher aufgezeichnet wird als eine Transaktion für eine kleine Summe. Ein Betriebsbeispiel hierfür könnte die Aufzeichnung jeder Webseite sein, auf die beim Durchführen einer Transaktion auf der Website eines Online-Händlers bei Transaktionen für große Geldsummen zugegriffen wird, wobei aber nur die Übertragung aufgezeichnet wird, die eine elektronische Quittung für Transaktionen für kleinere Beträge beinhaltet.
  • Die Richtliniendatei könnte außer der zu speichernden Datenmenge auch den Charakter der aufzuzeichnenden Daten bestimmen. Die gesamte Übertragung oder Webseite kann als eine Serie von Schnappschüssen der Transaktion ebenso aufgezeichnet werden, wie beispielsweise Webseiten in Cache-Speichern gespeichert werden, oder alternativ können individuelle Datenelemente, wie z. B. Datum, Identität des Händlers, Betrag usw., aus der Übertragung oder Webseite extrahiert und entweder alleine oder zusammen mit den Schnappschussdaten gespeichert werden.
  • Auf diese Weise kann Speicherplatz am effektivsten genutzt werden, um sicherzustellen, dass genügend Platz zum Aufzeichnen der wichtigsten Transaktionen vorhanden ist.
  • Die Menge der aufzuzeichnenden Transaktionsdaten kann auch von der Identität des Händlers, vom geografischen Ort, der Handelshistorie mit dem Unternehmen des Benutzers sowie den angebotenen Waren und Diensten abhängig sein.
  • In 13 zeigen die Richtliniendatenbeispiele ein einfaches Szenario, in dem die aufzuzeichnende Datenmenge im Hinblick auf die Zahl der Webseiten vorgegeben wird, die von den im Memory gecachten Seiten abzurufen sind. Die Anzahl unterscheidet sich je nachdem, ob eine Kreditkartennummer, ein Kontocode oder ein Schlüsselwort identifiziert wird. Ferner zeigt Tabelle r, dass sich die Zahl der zu speichernden vorherigen Webseiten mit der Erkennung unterschiedlicher Kontocodes unterscheiden kann, je nach der relativen Bedeutung des Kontos.
  • Die Erweiterung dieses einfachen Falls auf einen weiter entwickelten kann dadurch erzielt werden, dass in den Richtliniendaten ein höheres Detail-Level gegeben wird. Weitere Zweige am Richtliniendatenbaum könnten Firmen- oder Personennamen oder Schlüsselwörter in Bezug auf Waren und/oder Dienste vorgeben; ebenso die gemäß diesen Schlüsselwörtern aufzuzeichnende Datenmenge und Namen.
  • Auch die Tabellen könnten so erweitert werden, dass sie auf die Menge an unterschiedlichen Datentypen verweisen, die gespeichert werden sollen. Daten wie z. B. der Firmenname, was verkauft wird, die Menge usw. könnten aus dem Email-Text, dem die Webseite definierenden HTML-Text oder aus der DOM-Repräsentation der Webseite extrahiert und in der Datenbank gespeichert werden.
  • Es können alle im Cache gespeicherten Webseiten oder Informationen abgerufen werden, oder das System kann nur Seiten abrufen, die mit der anfangs als Teil einer Transaktion identifizierten Seite gemeinsame Details haben.
  • Alternativ kann dem Benutzer eine Liste aller gespeicherten Nachrichten vorgelegt werden, aus der der Benutzer solche Übertragungen manuell auswählen kann, die sich auf die identifizierte Transaktion beziehen.
  • Nach dem Ermitteln, wie viele Daten aufgezeichnet werden sollen, geht die Steuerung zum Entscheidungsschritt S280. Wenn in Schritt S280 frühere Übertragungen zu speichern sind, geht die Steuerung zu Schritt S282, wo die im lokalen Cache gespeicherten Übertragungen abgerufen werden. Bei einem Webbrowser kann dies eine vorbestimmte Anzahl früherer Seiten sein, wie oben beschrieben. Wo die Transaktion in einem Webbrowser erkannt wurde, da kann eine Richtlinie auch diktieren, dass der Cache nach früheren Email-Nachrichten in Bezug auf die Transaktion durchsucht wird, die z. B. von derselben Organisation gesendet oder empfangen wurde. Dies kann durch Vergleichen der Teile der URL-Adresse des Browsers mit Teilen der Email-Adressen ermittelt werden. Ebenso können in Email-Nachrichten erkannte Transaktionen bewirken, dass sowohl frühere Emails als auch frühere Webseiten aus dem Cache abgerufen werden. Die Steuerung geht dann zu Schritt S284, wo die identifizierte Transaktion und evtl. abgerufene frühere Übertragungen in der Systemdatenbank 42 gespeichert werden.
  • In Schritt S280 geht die Steuerung, wenn keine früheren Übertragungen benötigt werden, direkt zu Schritt S284, wo die als Transaktion identifizierte Übertragung in der Systemdatenbank aufgezeichnet wird. Zur selben Zeit, in der die Übertragungen in Schritt S284 gespeichert werden, können auch verwandte Daten wie die Benutzeridentität, der Betrag und die andere Transaktionspartei in der Systemdatenbank registriert werden, so dass ein kompletter Datensatz entsteht, obwohl dies von den Anweisungen in den Richtliniendaten abhängig ist. Die Steuerung geht dann zu S286 und das Modul verlässt die Routine.
  • Nach Schritt S276, wenn das Modul die Routine verlassen hat, können die Daten nach Punkt A in den 3 und 5 übertragen oder nach dem Empfang an den Punkten C und B jeweils in den 3 und 5 verarbeitet werden.
  • Nach der Identifikation einer Übertragung können alle Übertragungen zwischen dem Benutzer und der anderen Partei aufgezeichnet werden, bis das System erkennt, dass die Transaktion komplett ist. Die Erkennung des Endpunkts einer Transaktion und das Stoppen des Aufzeichnens können auf eine Weise ähnlich wie die erfolgen, die oben zum Identifizieren beschrieben wurde, ob eine Transaktion stattfindet. Die einfachste Implementation besteht darin, Übertragungsinformationen aufzuzeichnen, bis eine elektronische Quittung oder ein Versandauftrag eingegangen ist. Alternativ kann bewirkt werden, dass das Aufzeichnen von Übertragungen nach einer vorbestimmten Anzahl von Übertragungen zwischen dem Benutzer und der anderen Partei oder nach dem Verstreichen einer bestimmten Zeit seit der Identifikation der Transaktion gestoppt wird.
  • Übertragungen können vereinfacht werden, wenn der Cache nach jeder Änderung einer Website durch den Benutzer geleert wird. Dies hält den Speicherbedarf für den Cache-Memory klein und reduziert die Zahl der zu durchsuchenden vorherigen Übertragungen, wenn Suchtechniken angewendet werden sollen.
  • Man wird verstehen, dass die oben beschriebenen Methoden auch zum Aufzeichnen von assoziierten Übertragungen angewendet werden können, die nach dem Erkennen und Aufzeichnen einer Transaktion stattfinden. So folgt auf eine mit einem Webbrowser durchgeführte Transaktion typischerweise eine vom Verkäufer zum Käufer gesendete Bestätigungsemail. Diese Email kann als Teil der Transaktion erkannt werden, da sie gemeinsame Charakteristiken wie Auftragsnummer, Kontonummer, Warenbeschreibung, Preis usw. enthält. Sie kann auch von einer Adresse gesendet werden, die der Website-Adresse ähnlich ist, z. B. ,customerservices@abc.com', wenn die für den Kauf benutzte ursprüngliche Website ,abc.com' war. Vorzugsweise wird ein Zeitelement benutzt, so dass nur Folgeübertragungen als mit der ursprünglichen Transaktion assoziiert angesehen werden, die innerhalb einer gegebenen Zeitperiode auftreten.
  • Es kann vorteilhaft sein, über Transaktionsinformationen hinaus auch andere Informationen aufzuzeichnen, damit das Management das Verhalten seiner Kunden analysieren kann, z. B. um zu gewährleisten, dass die Organisation durch die Nutzung des elektronischen Handels in der Tat echte Produktivitätsvorteile erzielt. Solche Informationen sind nicht auf die Produktivität des Benutzers selbst begrenzt, sondern auf den gesamten Prozess, so dass beispielsweise ein Vergleich von Einkaufs-Websites angestellt werden kann, um zu ermitteln, welche im Hinblick auf den Verkaufsprozess am effizientesten sind, und somit welche den größten Nutzen im Hinblick auf eine Senkung der Einkaufskosten bringen. Das bevorzugte System ermöglicht dies durch Aufzeichnen von zusätzlichen Informationen, wie z. B. die für den Kauf benötigte Menge an Zeit, die Anzahl der Tastenanschläge und Mausklicke, die zum Abwickeln eines Kaufs erforderlich sind, die Menge an ,Untätigkeits'-Zeit, während der Benutzer auf das Herunterladen von Seiten oder den Empfang von Antworten wartet. Diese Informationen können mit dem Transaktionsdatensatz in der Datenbank aufgezeichnet werden, so dass eine statistische Analyse über einen Bereich von Transaktionen ausgeführt werden kann.
  • Die für eine Transaktion benötigte Zeit kann durch Assoziieren eines Zeitstempels mit jeder der empfangenen Übertragungen ermittelt werden. Wenn festgestellt wird, dass die Transaktion komplett ist, dann wird der mit der ersten Übertragung (die evtl. aus dem Cache in Schritt S282 zurückgewonnen wurde) assoziierte Zeitstempel von dem mit der letzten Übertragung assoziierten Zeitstempel subtrahiert und das Ergebnis, das die Gesamtdauer der Transaktion sein wird, wird in der Datenbank in Schritt S284 gespeichert. Alternativ könnten der erste und der letzte Zeitstempel in der Datenbank aufgezeichnet und die Transaktionsdauer später berechnet werden. Die Zahl der Tastenanschläge und Mausklicke kann in einem System auf der Basis von Microsoft Windows mit Hilfe von standardmäßigen Windows-,Hooks' in das Betriebssystem ermittelt werden. Solche Techniken sind ausführlicher in dem Dokument „Win 32 Hooks" von Kyle Marsh von der Microsoft Developer Network Technology Group vom 29. Juli 1993 beschrieben, erhältlich von der Microsoft Corporation Website
    (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmgmt/html/msdn hooks32.asp).
  • Das bevorzugte System führt einen Zähler für die Anzahl der Tastenanschläge (mit dem WH KEYBOARD Hook) und Mausklicke (mit dem WH MOUSE Hook), die jeweils zwischen empfangenen Übertragungen auftreten, und assoziiert diese Summen mit der empfangenen Übertragung. Die Tastenanschläge und Mausklicke, die auftreten, während eine andere Anwendung im Fokus ist (z. B. wenn der Benutzer vorübergehend auf eine andere Anwendung umschaltet), werden ignoriert. Wenn festgestellt wird, dass die Transaktion komplett ist, dann werden die Summen der Tastenanschläge und Mausklicke, die zwischen der ersten Übertragung (die möglicherweise aus dem Cache in Schritt S282 zurückgewonnen wurde) und der letzten Übertragung aufgetreten sind, miteinander addiert, und das Ergebnis, das die Gesamtzahl der Tastenanschläge und Mausklicke während der gesamten Transaktion ist, wird in der Datenbank in Schritt S284 gespeichert. Ebenso kann die Reaktionszeit der Website-Transaktion durch Notieren des Zeitpunkts, an dem jede abgehende Übertragungsanforderung gesendet wurde, und Subtrahieren des Ergebnisses von dem Zeitpunkt, an dem die Antwortübertragung empfangen wurde, gemessen werden. Das Anhäufen der Reaktionszeiten zwischen dem Anfang und dem Ende der Transaktion ergibt die Gesamtzeit, die der Benutzer mit dem Warten auf die Website verbracht hat. Ebenso misst das bevorzugte System auch die Reaktionszeit des Benutzers, d. h. die Zeit zwischen dem Empfang einer Übertragung und dem Moment des Sendens einer Antwort.
  • Das bevorzugte System berechnet auch, wie groß der Anteil der Reaktionszeit des Benutzers ist, der mit dem Eingeben von Daten verbraucht wird, so dass die Zeit, die der Benutzer braucht, um die eingehende Übertragung zu ,verdauen' (die Differenz), ermittelt werden kann. Die mit dem Eingeben von Daten verbrachte Zeit wird mittels einer ,Stoppuhr' ermittelt. Die Stoppuhr wird nach jedem Empfang einer neuen Übertragung zurückgestellt und wird sofort neu gestartet, wenn der Benutzer eine Taste anschlägt oder die Maus anklickt. Falls der Benutzer eine vorbestimmte Zeit lang keine Taste anschlägt oder die Maus anklickt, z. B. 5 Sekunden, dann nimmt das System an, dass der Benutzer jetzt Details der vorherigen Übertragung verdaut, und stoppt die Uhr. Die Uhr wird auch dann gestoppt, wenn der Tastenanschlag oder Mausklick das Senden einer abgehenden Übertragung bewirkt. Die Summe der mit dem Eingeben von Daten verbrachten Zeit zwischen dem Anfang und dem Ende der Transaktion ergibt die Gesamtzeit, die der Benutzer mit dem Eingeben von Daten auf der Website verbracht hat. Die Zeitsummen können in der Datenbank in Schritt S284 zur weiteren Analyse gespeichert werden.
  • Das bevorzugte System stellt auch ein Mittel zum Überwachen von durchgeführten Transaktionen und zum automatischen Verweisen der Transaktion zur Billigung bereit, wenn diese als notwendig erachtet wird. Dieser Vorgang lässt es zu, dass ein großes Unternehmen die von seinen Mitarbeitern vorgenommenen Transaktionen mit einem einzigen Satz von in den Richtliniendaten dargelegten Kriterien überwacht und steuert. Auf die Richtliniendaten kann jedes Mal Bezug genommen werden, wenn eine Transaktion identifiziert wird, um zu ermitteln, ob der Benutzer befugt ist, diese Transaktion selbst durchzuführen, oder ob er eine Autorisierung von einer höheren Stelle in dem Unternehmen benötigt. Der Vorgang ist in 15 illustriert, auf die nunmehr Bezug genommen werden sollte.
  • Das diesen Vorgang ausgestaltende Modul wird in Schritt S290 gestartet. Dieser Start erfolgt vorzugsweise, sobald alle zu beachtenden relevanten Details der Transaktion ermittelt sind und bevor die Transaktion kommittiert wird. Bei einer Email-Transaktion befinden sich Details wie Waren und Preise typischerweise in einer einzigen Email und können vor der Übertragung dieser Email betrachtet werden. Bei einer Webbrowser-Transaktion kann die Existenz einer Transaktion erkannt werden, bevor alle Details bekannt sind, und in diesem Fall erfolgt der Start erst dann, wenn sie es sind. Dies bedeutet normalerweise kein Problem, da eine endgültige Verpflichtung erst ganz am Ende des Transaktionsprozesses stattfindet, lange nachdem alle relevanten Details bekannt sind. Die Erkennung der Transaktion und der relevanten Details kann in der oben mit Bezug auf 12 beschriebenen Weise ermittelt werden. Kurz mit Bezug auf die 3 und 5, dort ist zu sehen, dass Schritt S290 nach Punkt C in 3 bei einer Webbrowser-Implementation oder nach Punkt A in 5 bei einer Email-Client-Implementation stattfindet, wenn die benötigten Details bekannt sind.
  • Die Steuerung geht von Schritt S290 zum Entscheidungsschritt S292, wo die Details der Transaktion mit den Richtlinieneinstellungen verglichen werden, um zu ermitteln, ob eine Zulassung erforderlich ist oder nicht. Die Ermittlung kann auf der Identität oder Stellung des die Transaktion vornehmenden Mitarbeiters, dem Betrag der Transaktion oder der anderen Transaktionspartei basieren. In einigen Fällen könnte eine Zulassung immer erforderlich sein, wie z. B. dann, wenn der Finanzdirektor eines Unternehmens jede Transaktion überprüfen möchte, bevor sie getätigt wird.
  • 16 zeigt ein Beispiel für Richtliniendaten, die zum Ermitteln, ob eine Transaktion von einer Drittpartei genehmigt werden muss oder nicht, und auch zum Ermitteln der Identität eines geeigneten zu beanspruchenden Billigers (Zulassungsstelle) verwendet werden können. In diesem Fall geben Bedingungen in den Richtliniendaten je nach dem Transaktionsbetrag und der URL-Adresse der anderen Partei der Transaktion vor, ob eine Zulassung erforderlich ist.
  • Die relevanten Richtliniendaten sind im Transactions-Approval-Zweig des Richtliniendatenbaums dargelegt. Dieser Zweig teilt sich in vier Unterzweige auf. Der erste Zweig, ,MaximumUnapprovedTransactionAmount', definiert einen Schwellenbetrag für Transaktionen. Transaktionen für Beträge über diesem Schwellenwert müssen vor der Durchführung von einem Billiger genehmigt werden.
  • Der zweite Unterzweig, ,MaximumUnapproved MonthlyAmount', definiert einen maximalen Betrag für Transaktionen, die ein Benutzer innerhalb eines Monats tätigen darf. In diesem Fall erfordert jede Transaktion, die von dem Benutzer getätigt wird, die zur Folge hätte, dass der monatliche Gesamtbetrag $2500 übersteigt, eine Zulassung von einer Drittpartei, wie auch weitere Transaktionen, die nach dem Erreichen dieses Schwellenbetrags getätigt werden sollen.
  • Der dritte Zweig, ,ExcludedSites', bezieht sich auf eine Tabelle, die Website- und Email-Adressen aller Sites aufführt, die immer von einer Drittpartei genehmigt werden müssen, bevor eine Transaktion getätigt werden kann. Schließlich bezieht sich der letzte Zweig, ,Approvers', auf eine Tabelle, in der die Namen möglicher Drittpartei-Billiger aufgeführt sind. Neben jedem Namen steht der Höchstbetrag für Transaktionen, für die der Billiger zulassungsbefugt ist, sowie eine Liste von ausgeschlossenen Sites, für die dieser Billiger eine Transaktion nicht genehmigen darf. Im einfachsten Fall sind Billiger andere Computer-Benutzer, die am selben Netzwerk angeloggt sind wie der Benutzer, der die Transaktion durchführt, z. B. Abteilungsleiter oder Supervisors. Die Zulassungsstellen werden, gemäß der Natur ihrer Rolle, Mitglieder des Handelsunternehmens sein, die die Autorität haben, die Verantwortung für die finanziellen Transaktionen zu übernehmen, die das Unternehmen tätigt. Es ist auch möglich, dass Billiger aus einer Gruppe von Personen genommen werden, die primär für diese Rolle angestellt sind, wie z. B. nur Personen in der Finanzabteilung.
  • Wenn die Bedingungen auf den ersten drei Unterzweigen des Transaktionszweigs anzeigen, dass eine Zulassung erforderlich ist, dann kann ein entsprechender Billiger durch Scannen der Tabelle von Zulassungsstellen gefunden werden, bis ein Billiger gefunden wird, dessen Transaktionslimit gleich oder höher ist als die vorgeschlagene Transaktion, und dem es nicht untersagt ist, Transaktionen auf dieser relevanten Site zu genehmigen.
  • Man wird verstehen, dass die beispielhaften Richtliniendaten in 16 Richtliniendaten sind, die für einen einzelnen Computerbenutzer oder eine Benutzergruppe in dem Netzwerk spezifisch sind. Andere Benutzer oder Gruppen können andere Einstellungen und eine andere Liste von Zulassungsstellen haben.
  • Man wird verstehen, dass die Bedingungen zum Ermitteln eines geeigneten Billigers durch Erzeugen neuer Unterzweige auf dem Richtliniendatenbaum geschaffen werden können.
  • Der Ablauf des Zulassungsprozesses kann beispielsweise außer auf solche, die eine eCommerce-Transaktion umfassen, auch auf jede Übertragungsart erweitert werden. Ein solcher Vorgang kann dadurch implementiert werden, dass die Bedingungen definiert werden oder die Unterzweige der Richtliniendaten z. B. Benutzernamen, Adressen oder Schlüsselwörter vorgeben, die in der Übertragung identifiziert und auf die reagiert werden muss. So kann bewirkt werden, dass alle Email-Übertragungen zu einer bestimmten Firma oder Person billigungspflichtig sind oder alle Emails, die vorbestimmte Informationen enthalten, per Schlüsselwortidentifikation erkannt werden.
  • Wenn in Schritt S292 ermittelt wird, dass keine Billigung erforderlich ist, dann geht die Steuerung direkt zu Schritt S294, wo das Modul die Routine verlässt. Nach Schritt S294 wird die Übertragung der Transaktion zugelassen und die Transaktion kann ablaufen. Die Steuerung kehrt von Schritt S294 zu Punkt C in 3 oder zu Punkt B in 5 zurück.
  • Wenn jedoch in Schritt S292, nach dem Konsultieren der Richtlinieneinstellungen, ermittelt wird, dass die Transaktion billigungspflichtig ist, dann geht die Steuerung zu Schritt S296, wo die Einzelheiten der Transaktion zum Ermitteln eines geeigneten Billigers für die Transaktion benutzt wird. Der Billiger kann ein Firmenmitarbeiter sein, der an seiner Workstation oder an einer Workstation mit einer dedizierten Zulassungsfunktion wie z. B. Operatorkonsolen 44 wie in 2 gezeigt angeloggt ist, oder er kann sogar ein automatisierter Prozess sein. Bei einem großen Unternehmen mit einer Reihe von Abteilungen kann es vorteilhaft sein, für jede Abteilung eine Gruppe von Billigern zu haben, wobei jede Gruppe die Konten der Abteilung überwacht. So können Transaktionen abgelehnt werden, bevor sie getätigt werden, wenn beispielsweise der Leiter der Abteilung beschließt, alle Käufe oder eine bestimmte Art von Käufen vorübergehend zu suspendieren.
  • Die Steuerung geht von Schritt S296 nach der Ermittlung eines geeigneten Billigers zu Schritt S298, wo ein Zulassungsantrag über eine Systemzulassungswarteschlange 100 zum designierten Billiger übertragen wird. Nach Schritt S298 geht die Steuerung zum Entscheidungsschritt S300, wo ermittelt wird, ob eine Antwort von dem Billiger empfangen wurde. In dem Moment, in dem ein Zulassungsantrag vorgelegt wird, wird eine Zeituhr gestartet. Wenn in Schritt S300 keine Antwort empfangen wurde, dann geht die Steuerung zu Schritt S302, wo anhand der Zeituhr ermittelt wird, ob eine Auszeitperiode verstrichen ist oder nicht. Vorausgesetzt, die Periode ist nicht verstrichen, geht die Steuerung von Schritt S302 zurück zu S300, wo das System weiter auf eine Antwort von dem Billiger wartet. So bilden die Entscheidungsschritte S300 und S302 eine Schleife, in der das System wartet, bis eine Antwort empfangen wird oder bis die Auszeit abläuft. Im Entscheidungsschritt S300 geht die Steuerung, wenn eine Antwort empfangen wurde, zu Schritt S304, wo eine Aktion je nachdem stattfindet, ob die Transaktion zugelassen oder abgelehnt wurde.
  • Wenn die Transaktion zugelassen wurde, geht die Steuerung von Schritt S304 zu Schritt S294, wo das Modul die Routine verlässt und die Übertragung stattfinden kann. Wenn jedoch die Übertragung nicht zugelassen wird, dann geht die Steuerung von Schritt S300 zu Schritt S306, wo das Modul die Routine verlässt. Das Verlassen in Schritt S306 verhindert jedoch die Übertragung der Transaktion und bringt den Benutzer zu Punkt A in 3 bei einer Webbrowser-Implementation oder zu Schritt S132 „Email verfassen" in 5 bei einer Email-Client-Implementation zurück.
  • Ebenso geht die Steuerung, wenn in Schritt S302 festgestellt wird, dass die ,Auszeitperiode' ohne Eingang einer Antwort von dem Billiger abgelaufen ist, direkt zu Schritt S306, wo das Modul die Routine verlässt.
  • Die rechte Seite von 15 zeigt die für den Billiger beteiligten Schritte. Der Zulassungsprozess beginnt in Schritt S310, von wo die Steuerung zu Schritt S312 geht, in dem die Maschine des Billigers die Systemzulassungswarteschlange nach eventuellen neuen Zulassungsanträgen abfragt. Die Steuerung geht dann zum Entscheidungsschritt S314. In Schritt S314 geht die Steuerung, wenn kein Antrag ansteht, zu Schritt S312 zurück, wo die Systemwarteschlange erneut abgefragt wird. Diese Schritte werden so lange wiederholt, bis ein Zulassungsantrag eingeht oder bis der Billiger den Zulassungsprozess deaktiviert.
  • In Schritt S314 geht die Steuerung, wenn ein Zulassungsantrag eingeht, zu Schritt S316, wo der Zulassungsantrag von der Systemwarteschlange heruntergeladen wird und der Billiger selbst entscheidet, ob dem Antrag stattgegeben oder ob er abgelehnt wird. Die Steuerung geht dann zu Schritt S318, wo die Antwort des Billigers zurück in die Systemzulassungswarteschlange und von dort zurück zur Benutzerworkstation übertragen wird.
  • Die Steuerung geht von Schritt S318 zurück zu Schritt S312, wo die Systemzulassungswarteschlange nach neuen Zulassungsanträgen abgefragt wird. Man wird verstehen, dass der Zulassungsprozess unter Umständen auch vollkommen automatisiert werden könnte. So könnten beispielsweise Transaktionen automatisch abgelehnt werden, wenn das Unternehmen nicht genügend Mittel besitzt, wenn sie verursachen würden, dass die Budgetbeträge überschritten würden oder wenn sie einfach über einem Höchstbetrag liegen. Eine solche Automatisierung könnte alternativ als Teil des Benutzerprozesses vorgesehen werden, so dass noch nicht mal ein Zulassungsantrag gestellt würde.
  • Bei der Ermittlung, ob eine gegebene Transaktion genehmigt werden soll, sollte die Genehmigungsstelle diese idealerweise vollständig betrachten können, z. B. so, dass sie genau sehen kann, was gekauft wird, anstatt einfach Zusammenfassungsinformationen wie Gesamtpreis und Lieferant zu sehen. Das bevorzugte System stellt dies dadurch bereit, dass die oben beschriebenen Merkmale der Aufzeichnung von Übertragungen mit dem Zulassungsmerkmal kombiniert werden. Der in Schritt S298 vorgelegte Zulassungsantrag wird mit einem Verweis auf den Ort in der Datenbank ergänzt, in der die Transaktionsinformationen in Schritt S284 gespeichert wurden. Der Billiger empfängt die Ortsdetails in Schritt S316 und das System ruft die die Transaktion konstituierenden Übertragungen aus der Datenbank ab und zeigt sie auf geeignete Weise an, so dass der Billiger sie beim Fällen seiner Zulassungsentscheidung berücksichtigen kann. Die Operation geht dann normalerweise mit Schritt S318 weiter. Es ist natürlich wichtig, dass der Aufzeichnungsschritt S284 stattfindet, bevor der Zulassungsantrag in Schritt S298 erfolgt, da die aufgezeichneten Informationen sonst noch nicht zur Verfügung stehen. Da die Transaktion in Schritt S284 bereits identifiziert wurde, aber noch nicht abgeschlossen ist (da sie noch nicht gebilligt wurde), muss die in Schritt S284 vorgenommene Datenbankaufzeichnung einen Flag enthalten, der die Transaktion als „anhängig" identifiziert. Dieser Flag kann in Schritt S316 aktualisiert werden, so dass er zeigt, dass die Transaktion zugelassen oder abgelehnt wurde, alternativ kann der Datenbankdatensatz, falls die Zulassung verweigert wurde, gelöscht werden, da die Transaktion nicht stattgefunden hat.
  • Sicherheit
  • Das bevorzugte System bietet Mittel zum Zuweisen einer angemessenen Sicherheitsbewertung zu der Übertragung in Abhängigkeit vom identifizierten Charakter der übertragenen Daten. Die zugewiesene Sicherheitsbewertung kann vom Benutzer des Systems im Einklang mit seinen Erfordernissen anhand der Richtliniendaten eingestellt werden.
  • Die einfachste Implementation der Richtliniendaten ist in diesem Falle eine Liste, die in einer ersten Spalte mögliche Datentypen wie z. B. Mitarbeiterpasswörter, Arbeitgeberpasswörter, Kreditkartennummern, Bankdetails usw. und in einer zweiten Spalte die gewünschte Verschlüsselungsstärke (z. B. in Key-Bits) enthält, die als für den jeweiligen Datentyp angemessen angesehen wird. Man wird verstehen, dass auch andere Möglichkeiten zum Zuweisen von Sicherheitsniveaus in Abhängigkeit vom bestimmten Charakter der Daten im Rahmen der Erfindung angewandt werden können.
  • 17 zeigt eine beispielhafte Illustration von Richtliniendaten, die geeignete Verschlüsselungsstärken für verschiedene Datentypen definieren. Die Richtliniendaten haben die Form einer Reihe von Key-Wertepaaren, die auf separaten Zweigen des Richtliniendatenbaums angeordnet sind. Der Key gibt den Datentyp an, der übertragen wird, wie z. B. Passwörter, Kreditkartennummern, submittierte Schlüsselwörter und einen allgemeinen Key für sonstige submittierte Daten. Die Werte, die diesen Keys entsprechen, sind die Verschlüsselungsstärke in Bits, die als für die Übertragung der im Key angegebenen Daten geeignet angesehen wird. Die Key-Wertepaare sind auf mehreren Zweigen des RequiredEncryptionLevel-Zweigs des TransmittedDataSecurity-Zweigs des Richtliniendatenbaums angeordnet. So ist in dem Beispiel ersichtlich, dass Passwörter eine gewünschte Verschlüsselungsstärke von 40 Bits haben, sowohl Firmenkreditkartennummern als auch persönliche Kreditkartennummern eine gewünschte Verschlüsselungsstärke von 128 Bits haben, submittierte Schlüsselwörter eine gewünschte Verschlüsselungsstärke von 40 Bits haben und sonstige submittierte Daten keine Verschlüsselung brauchen.
  • Der SubmittedKeyword-Zweig bezieht sich auf bestimmte Wörter oder Ketten oder Text, die als sensitiv designiert wurden und eine Form von Verschlüsselung benötigen. Dies können Benutzernamen, Adressinformationen, finanzielle Informationen oder vorgewählte Wörter wie z. B. ,vertraulich' oder ,geheim' sein. Die submittierten Schlüsselwörter können durch Bezugnahme auf eine Tabelle oder Datei erkannt werden, in der sie gespeichert sind.
  • Ferner kann sich jeder Zweig der Richtliniendaten, anstatt eine allgemeine Verschlüsselungsstärke anzugeben, auf eine Tabelle beziehen, in der beispielsweise verschiedene Passwörter oder Kreditkartennummern zusammen mit Verschlüsselungsstärken aufgeführt sind, die für jedes Passwort oder jede Nummer spezifisch sind.
  • Nach dem Zuweisen einer Sicherheitsbewertung fragt das Einsteckmodul entweder den Webbrowser ab, um die Sicherheit der Verbindung zu ermitteln, die vom Webbrowser mit dem Webserver zur Übertragung dieser Informationen eingerichtet wurde, oder, bei einer Email-Übertragung, die Verschlüsselungseinstellungen, die der Benutzer oder die Anwendung bestimmt hat, werden auf die Nachricht angewendet. Dies ist typischerweise die kryptografische Stärke des zum Codieren der Daten zur Übertragung verwendeten Verschlüsselungsalgorithmus. Solche Übertragungsdetails werden vom Webbrowser als Teil des ,elektronischen Quittungsaustauschs' vom Webdiensteanbieter empfangen.
  • Eine sichere Verbindung wird gewöhnlich in einem Browser-Fenster durch ein geschlossenes Vorhängeschloss-Icon in der rechten unteren Ecke angezeigt. Ein Benutzer kann das Icon anklicken, um das Sicherheitsniveau abzufragen, das durch den Quittungsaustausch bereitgestellt wurde. Dabei kann er eine Benachrichtigung der Form ASSL-gesichert empfangen (128 Bits). Der erste Teil der Benachrichtigung beschreibt den Typ der verwendeten Verschlüsselung, während der zweite Teil die Verschlüsselungsstärke beschreibt. Das Einsteckmodul wird implementiert, um diese Daten automatisch vom Browser zu erhalten, so dass sie zum Ermitteln verwendet werden können, ob das Sicherheitsniveau für eine vorgeschlagene Übertragung ausreicht oder nicht. Ebenso bestimmt bei einer Email-Nachricht das Einsteckmodul die Verschlüsselungseinstellungen, die der Benutzer oder die Anwendung vor der Übertragung der Nachricht zur Verwendung vorgegeben hat.
  • Das Modul vergleicht die vorgegebene Verschlüsselungsstärke mit der der Verbindung oder der Nachricht und führt je nach dem Ergebnis des Vergleichs eine der folgenden Aktionen aus:
    • a) wenn die Sicherheit der Verbindung für die Natur der übertragenen Informationen geeignet ist, dann lässt das Modul die Übertragung der Informationen zu;
    • b) wenn die Sicherheit der Verbindung höher ist als für die Übertragung der Informationen erforderlich, dann kann das Modul entweder die Übertragung der Informationen auf diesem Sicherheitsniveau zulassen, mit dem Webserver und dem Webbrowser automatisch ein neues geeignetes Sicherheitsniveau negoziieren und die Informationen auf diesem Niveau übertragen oder den Benutzer darauf hinweisen, dass das vorliegende Sicherheitsniveau unnötig ist, und ihn zur Durchführung einer Aktion auffordern;
    • c) wenn die Sicherheit der Verbindung für die Natur der übertragenen Informationen nicht ausreicht, dann kann das Modul entweder die Übertragung verhindern und den Benutzer warnen und auffordern, automatisch mit dem Webserver und dem Webbrowser ein neues geeignetes Sicherheitsniveau zu negoziieren und die Informationen dann auf diesem Niveau zu übertragen, oder im Falle einer Email automatisch die Einstellung der Verschlüsselungsstärke erhöhen oder den Benutzer anweisen, dass das vorliegende Sicherheitsniveau nicht ausreicht, und ihn auffordern zu bestätigen, dass er die Übertragung weiterhin wünscht.
  • Man wird verstehen, dass das Einsteckmodul auch so konfiguriert werden könnte, dass es auf eine Differenz zwischen dem ermittelten gewünschten Sicherheitsniveau und dem gegebenen auf verschiedene Weisen reagiert, und dass die oben erwähnten Aktionen lediglich illustrativ sind.
  • Weitere Maßnahmen, die das System ergreifen kann, könnten z. B. die Anforderung des Herunterladens einer anderen Webseite auf die Maschine des Benutzers oder das Modifizieren der submittierten Felddaten beinhalten, so dass empfindliche Informationen nicht übertragen werden.
  • Der Betrieb eines Browsers oder Email-Einsteckmoduls zum Überwachen der durch einen Benutzer des bevorzugten Systems übertragenen Daten ist in 18 illustriert, auf die nunmehr Bezug genommen werden sollte. Der Betrieb des Moduls beginnt mit Schritt S320 an Punkt C in 3 unmittelbar vor der Übertragung der Daten zu einem Webserver, oder an Punkt B in 5 unmittelbar vor der Übertragung einer Email. Die Steuerung geht dann zu Schritt S322, wo das Modul die vor der Übertragung stehenden Daten parst und nach Kreditkartennummern sucht. Ein mögliches Verfahren hierfür wurde zuvor mit Bezug auf 8 beschrieben. Wenn keine Kreditkartennummer in den Daten erkannt wird, geht die Steuerung zu Schritt S314, wo das Modul nach Passwörtern in den vor der Übertragung stehenden Daten sucht. Ein Verfahren hierfür wurde oben mit Bezug auf 6 beschrieben. Wenn in den Daten kein Passwort gefunden wird, dann geht die Steuerung zu Schritt S316, wo das Modul nach Firmenkonten- oder Kaufcodes in den Daten sucht. Konten- oder Kaufcodes können erkannt werden, indem die Codes des Unternehmens in einer Datei gespeichert und versucht wird, diese Codes mit in den abgehenden Daten gefundenen Ziffernfolgen zu vergleichen. Wenn kein Kontencode gefunden wird, dann geht die Steuerung zu Schritt S318, wo das Modul nach Anzeichen für andere sensitive Daten in den vor der Übertragung stehenden Daten sucht. Solche Anzeichen müssen im Voraus definiert werden, vorzugsweise in einer zur Erfassung verwendeten separaten Datei, und ist von den Anforderungen der Benutzer des bevorzugten Systems abhängig. Beispiele könnten vorgegebene Schlüsselwörter über Projekte sein, die das Unternehmen durchführt, die Projekttitel selbst, persönliche Details wie die Adresse des Empfängers der Daten, oder des Senders, oder sogar das in den Daten selbst enthaltene Wort ,vertraulich' oder ,privat'.
  • Wenn keine solchen Anzeichen gefunden werden, dass die Daten sensitiv sind und einen stärkeren Schutz benötigen, bevor sie übertragen werden, dann wird die Übertragung auf dem aktuellen Verschlüsselungsniveau zugelassen. Dies kann bedeuten, dass die Übertragung stattfindet, ohne dass irgendeine Verschlüsselung angewendet wird.
  • Wenn jedoch einer der Checks in den Schritten S322 bis S328 Daten zu Tage bringt, die als sensitiv angesehen werden, dann geht die Steuerung zu Schritt S332, wo den erfassten Daten eine Sicherheitsbewertung zugewiesen wird. Dies wird durch Vergleichen der erkannten Daten mit vorbestimmten Einträgen in den Richtliniendaten erzielt.
  • Jeder Eintrag auf dem Zweig der Richtliniendaten hat ein zuvor zugewiesenes Verschlüsselungsniveau, das das Mindestniveau ist, das für die Übertragung dieser Daten benutzt werden darf. Die Einträge in der Tabelle und das zugewiesene Verschlüsselungsniveau werden, wie alle Richtlinieneinstellungen, von dem Unternehmen mit dem bevorzugten System in Abhängigkeit von deren Anforderungen entschieden. Die Zuweisung einer Sicherheitsbewertung ist dann einfach eine Sache des Nachschlagens von Passwort, Kreditkartennummer oder sonstigen Daten in den Richtliniendaten und das Ablesen der entsprechenden Bewertung. Verweise auf Tabellen auf einem Unterzweig der Richtliniendaten können zum Zuordnen verschiedener Verschlüsselungsstärken zu unterschiedlichen Passwörtern, Kreditkartennummern usw. verwendet werden.
  • Nach dem Ermitteln des geeigneten Sicherheitsniveaus in Schritt S332 geht die Steuerung zu Schritt S334, wo das Modul das Verschlüsselungsniveau erfasst, das mit dem Webserver negoziiert wurde, zu dem die Daten übertragen werden, oder das von der Email-Anwendung vor dem Übertragen der Nachricht anzuwenden ist. Dies kann durch Abfragen des Webbrowsers oder der Email-Anwendung oder durch Einstellen von Verschlüsselungsstärke-Variablen zu der Zeit erzielt werden, zu der die Verbindung hergestellt wird oder die Email-Verschlüsselungsanforderungen bestimmt werden, was beides vor der Übertragung stattfindet.
  • Die Steuerung geht dann zum Entscheidungsschritt S336, in dem das gewünschte Sicherheitsniveau, d. h. die Verschlüsselungsstärke, mit dem im vorangegangenen Schritt ermittelten verglichen wird. Wenn das gewünschte Verschlüsselungsniveau gleich oder niedriger ist als das in Schritt S334 ermittelte, dann wird dies als ein ausreichender Schutz für die zu übertragenden Daten angesehen und die Steuerung geht zum Endschritt S330, wo das Modul die Routine verlässt. Nach Schritt S330 kehrt die Steuerung entweder zu Punkt C in 3 oder zu Punkt B in 5 zurück, je nachdem, ob das Modul in einem Webbrowser oder einem Email-Client implementiert wird. Die Übertragung der Daten erfolgt dann in der gewöhnlichen Weise.
  • Wenn jedoch in Schritt S336 das gewünschte Verschlüsselungsniveau höher ist als das gerade eingestellte, dann lässt das Modul eine Übertragung erst dann zu, wenn das richtige Verschlüsselungsniveau negoziiert wurde. Die Steuerung geht dann zum Entscheidungsschritt S338, wo das Modul ermittelt, ob es die Verschlüsselungsstärke erhöhen kann, und wenn ja, dann geht die Steuerung zu Schritt S340, wo eine neue, stärker verschlüsselte Verbindung negoziiert oder, bei einer Email, eine höhere Verschlüsselungsstärke eingestellt wird.
  • Das höchste verfügbare Verschlüsselungsniveau hängt von der sowohl vom Webserver als auch vom Webbrowser verwendeten Software oder, im Falle einer Email, von der Email-Sende- und -Empfangsanwendung ab. Es kann dann Fälle geben, in denen das richtige Verschlüsselungsniveau für eine andere Partei nicht verfügbar ist und die Daten niemals übertragen werden können. Ferner können bestimmten Datentypen Sicherheitsbewertungen gegeben werden, die anzeigen, dass kein Verschlüsselungsniveau jemals für ihren Schutz ausreicht, d. h. es wird verhindert, dass Daten jemals übertragen werden.
  • Nachdem versucht wurde, die Verbindung erneut herzustellen oder die Email-Verschlüsselungseinstellungen auf eine höhere Verschlüsselungsstärke zu ändern, geht die Steuerung zurück zu Schritt S334, um zu gewährleisten, dass die Verbindungen oder Einstellungen jetzt auf einer geeigneten Stärke sind. Wenn das geeignete Verschlüsselungsniveau in Schritt S338 nicht neu negoziiert werden kann oder ein Versuch, die Verschlüsselungsstärke in Schritt S340 zu erhöhen, nicht erfolgreich war, dann wird eine Übertragung der Daten als unsicher angesehen und die Steuerung geht zum Endschritt S342, wo das Modul die Routine verlässt. Nach dem Verlassen der Routine in Schritt S342 kehrt die Steuerung zu Punkt A in 3 oder zu Schritt S132 in 5, ,Email verfassen', zurück, so dass der Benutzer die Übertragung neu betrachten und bearbeiten oder abbrechen kann. Dem Benutzer kann auch eine geeignete Nachricht angezeigt werden, die die Gründe für die Nichtübertragung erläutert.
  • Das bevorzugte System stellt somit einen Weg bereit, um zu gewährleisten, dass die Übertragung von Daten so sicher wie möglich ist. Es schließt die Möglichkeit aus, dass ein Benutzer vergisst, eine Übertragung zu sichern, und negoziiert ein geeigneteres Sicherheitsniveau, wenn das benutzte nicht ausreicht.
  • Webbrowser können ähnliche Einrichtungen bereitstellen, um den Benutzer zu warnen, dass bevorsteht, dass vom Benutzer eingegebene Daten über eine unsichere Verbindung gesendet werden, oder um Einrichtungen zum vorgabemäßigen Verschlüsseln aller Nachrichten bereitzustellen. Das bevorzugte System bietet jedoch die Möglichkeit, den Inhalt von zu übertragenden Daten zu untersuchen, um deren Sicherheitserfordernis zu ermitteln, die Übertragung auf der Basis solcher Sicherheitserfordernisse und des bestimmten Sicherheitsniveaus der Verbindung (Verschlüsselungsstärke) zuzulassen oder zu verhindern. Man wird verstehen, dass das bevorzugte System ein erheblich verbessertes System für sichere Übertragungen bereitstellt, das die Möglichkeit menschlicher Fehler reduziert.
  • Überwachung abgehender Emails auf sensitive Informationen
  • Zusätzlich zu dem Problem des Abfangens sensitiver Daten durch eine Drittpartei zwischen Sender und Empfänger besteht für Organisationen ein erhebliches Risiko einer absichtlichen Weitergabe sensitiver Informationen durch ihre Benutzer. So ist z. B. die Praxis des ,elektronischen' Stehlens von Kopien vertraulicher Dokumente wie Kundenlisten durch einen Mitarbeiter einer Organisation, bevor er sie verlässt, eine einfache Sache, die praktisch nicht erkennbar und demzufolge weit verbreitet ist. Der Benutzer braucht dazu lediglich das Dokument zu seiner eigenen privaten Email-Adresse zum späteren Abrufen zu senden. Das Dokument braucht noch nicht einmal über das eigene Email-System der Organisation gesendet zu werden, da ein Internet-Mail-Service wie z. B. „Hotmail" verwendet werden kann, so dass das unautorisierte ,Leck' mit derzeitigen Mitteln praktisch nicht ermittelt werden kann.
  • Zusätzlich zur Bereitstellung von Mitteln zum Gewährleisten, dass ein geeignetes Verschlüsselungsniveau auf Nachrichten angewendet wird, erlaubt das bevorzugte System die Identifikation von Nachrichten als potentiell sensitiv, um automatisch umgeleitet oder ohne Wissen des Benutzers auf einen anderen Zielort kopiert zu werden. Beim Ermitteln, ob solche Nachrichten umgeleitet werden sollen, berücksichtigt das bevorzugte System eine Reihe von Faktoren einschließlich der Identität des Senders, der Identität des beabsichtigten Empfängers, der Natur der Adressen der beabsichtigten Empfänger, der Natur des Nachrichteninhalts, der Natur und Existenz eventueller Nachrichtenanhänge, des Mittels, mit dem die Nachricht übertragen werden soll, und ob die Nachricht und/oder eventuelle Anhänge verschlüsselt sind oder nicht.
  • Die Natur der Nachricht kann durch Scannen der Nachricht nach einem oder mehreren Schlüsselwörtern oder Schlüsselwortkombinationen oder mit Hilfe von standardmäßigen ,natürlichsprachliche Abfrage'-Techniken ermittelt werden. Die Natur der Adresse der beabsichtigten Empfänger kann durch Bezugnahme auf eine Liste von bekannten Internet-Mailservice-Bereichen ermittelt werden. So werden beispielsweise „hotmail.com", „yahoo.com" und „aol.com" alle vornehmlich von Personen und nicht von Unternehmen benutzt. Ebenso kann die Adresse nach Ähnlichkeiten mit dem Namen des Senders untersucht werden. So könnte z. B. eine Email, die bekanntlich von Fred Smith zur Adresse „smith900@aol.com" gesendet wird, durch den Einschluss sowohl von „smith" als auch „aol.com" in der Empfängeradresse als verdächtig angesehen werden. Eine weitere Untersuchung der Nachricht kann die Wahrscheinlichkeit unterstützen, dass dies eine unautorisierte Weitergabe von vertraulichen Daten ist, z. B. dann, wenn die Nachricht nur aus Dateianhängen besteht und der Nachrichtentext und die Betreffzeile leer gelassen wurden, ein wichtiger Hinweis, weil es wenig wahrscheinlich ist, dass der Sender Text eingeben wird, den nur er lesen wird. Die Mittel, mit denen die Nachricht übertragen wird, sind ein wichtiger Faktor, so kann beispielsweise eine mit einem Internet-Mailservice wie Hotmail gesendete Übertragung weitaus verdächtiger sein als eine Nachricht, die über das gewöhnliche Firmenemailsystem gesendet wird.
  • In der Tat ist das ,Heraufladen' von Dateien auf einen Internet-Mailservice potentiell so verdächtig, dass die bevorzugte Ausgestaltung Mittel enthält, um das Heraufladen von Dateien auf solche Dienste ganz zu verbieten.
  • Beim Umleiten von Mail fügt das bevorzugte System zusätzlichen Text zum Anfang der Mail hinzu, z. B. „----Redirected Mali----", zusammen mit den Adressen der ursprünglich beabsichtigten Empfänger, so dass der neue Empfänger feststellen kann, dass die Nachricht zu ihm umgeleitet wurde, sowie den Empfänger, zu dem sie ursprünglich gesendet wurde.
  • Wenn die weitergeleitete Nachricht verschlüsselt werden soll, dann kann das bevorzugte System die Nachricht verschlüsselt oder unverschlüsselt zu der Drittpartei weiterleiten. Der Verschlüsselungskey des Senders wird vorzugsweise mit der Nachricht gesendet und es sind Mittel vorgesehen, damit die Drittpartei die Nachricht entschlüsseln kann, wenn sie bereits verschlüsselt war, und die Nachricht mit dem Verschlüsselungskey des ursprünglichen Senders zur Übertragung verschlüsseln kann.
  • Das bevorzugte System identifiziert auch eingehende Mails, die umgeleitet wurden (d. h. zu einem Benutzer gesendet wurden, der nicht der ursprünglich beabsichtigte Empfänger ist), indem der Text nach „----Redirected Mail----" durchsucht wird. Auf eine solche Mail kann der neue Empfänger beispielsweise mit speziellen Icons aufmerksam gemacht werden, oder es kann eine Nachrichtenbox eingeblendet werden, um ihn zu benachrichtigen. Es können auch Mittel vorgesehen werden, um es zuzulassen, dass der neue Empfänger die Nachricht leicht ,genehmigt' und sie zu dem/den ursprünglich beabsichtigten Empfänger(n) senden lässt. Dies kann beispielsweise dadurch erzielt werden, dass eine „Zulassen"-Schaltfläche vorgesehen wird. Wenn auf diese Schaltfläche geklickt wird, dann erzeugt das bevorzugte System eine neue Nachricht auf dieselbe Weise, als wenn der Benutzer auf die normale „Weiterleiten"-Schaltfläche geklickt hätte. Anstatt des Hinzufügens von Text zu der Nachricht, um darauf hinzuweisen, dass sie weitergeleitet wurde, extrahiert das System jedoch im Falle der „Zulassen"-Schaltfläche die Liste der ursprünglich beabsichtigten Empfänger aus der Nachricht und zieht dann die Umleitungsdetails heraus, um die Nachricht in ihrem ursprünglichen Zustand zu lassen. Die Zielfelder „An", „Cc" und „Bcc" werden dann automatisch mit den extrahierten Adressen der ursprünglichen Empfänger ausgefüllt, und das „Von"-Feld (das für jede Nachricht existiert, selbst dann, wenn sie nicht normal angezeigt wurde) wird mit dem Namen/der Adresse des ursprünglichen Senders ausgefüllt. Das Datum/Zeit-Feld kann auch das/die Datum/Uhrzeit der ursprünglichen Nachricht eingestellt werden. Dann wird die Nachricht gesendet, entweder automatisch oder wenn der Benutzer die „Senden"-Schaltfläche drückt. Auf diese Weise kann durch Anklicken von nur einer oder zwei Schaltflächen die umgeleitete Mail zugelassen und gesendet werden, und erscheint nach der Ankunft wie vom ursprünglichen Empfänger gekommen, so als wenn keine Umleitung stattgefunden hätte.
  • Beispielhafte Richtliniendaten zum Steuern des Betriebs eines zum Umleiten von Mail implementierten Einsteckmoduls sind in 19 dargestellt, eine beispielhafte Illustration des Betriebs eines solchen Einsteckmoduls ist in 20 dargestellt. 19 ist ein Richtliniendatenbaum mit einer Reihe von Zweigen, die Entscheidungsschritten in 20 entsprechen.
  • Das Einsteckmodul wird in Schritt S350 gestartet, der Punkt B in der Illustration des Betriebs des Email-Client in 5 entspricht. Nach dem Starten durchläuft das Einsteckmodul sechs Schritte, die verschiedene Details der abgehenden Email-Nachricht ermitteln. Erstens, in Schritt S351 wird die Identität der die Email sendenden Person mit Einträgen in einer vorbestimmten Liste von Namen und Adressen geprüft. Emails von Benutzern auf dieser Liste werden so angesehen, dass sie die Autorität haben, Emails direkt zum beabsichtigten Empfänger unabhängig vom Inhalt der Nachricht und unabhängig vom Empfänger zu übertragen. Die Emails von jedem, der nicht auf der Liste aufgeführt ist, können je nach ihrem Inhalt umgeleitet werden oder auch nicht. So geht die Steuerung im Entscheidungsschritt S351, wenn der Name oder die Adresse des Benutzers auf der Liste steht, zu Schritt S364, wo zugelassen wird, dass die Email ohne weitere Interaktion übertragen wird. Wenn der Benutzer jedoch nicht auf der Liste steht, dann geht die Steuerung zu Schritt S253 für weitere Checks. In Schritt S352 wird der Empfänger der abgehenden Email-Nachricht anhand der Lookup-Tabelle s gemäß den auf dem Recipients- Zweig der in 19 gezeigten Richtliniendaten geprüft. Im nachfolgenden Entscheidungsschritt S354 werden der die Email-Nachricht umfassende Text und eventuelle Anhänge an der Email-Nachricht mit Einträgen in einer Lookup-Tabelle t verglichen. Auf Tabelle t wird im Keywords-Zweig der Richtliniendaten verwiesen und sie enthält Wörter, die anzeigen, dass die Natur der Email-Nachricht möglicherweise für das Unternehmen sensitiv ist. Im nächsten Schritt S356 wird die Email-Nachricht geprüft, um zu sehen, ob sie verschlüsselt werden muss oder nicht. Man wird sich erinnern, dass eine Verschlüsselung erst dann erfolgt, wenn die Email übertragen wird, daher wird in dieser Phase die Email nur zur Verschlüsselung markiert. Im nächsten Entscheidungsschritt S358 wird ermittelt, ob die Email-Nachricht Anhänge enthält oder nicht, und im folgenden Entscheidungsschritt S360, ob die Email-Nachricht Text zum Begleiten der Anhänge enthält, d. h. ob das Haupttextfeld der Email-Nachricht leer ist.
  • In jedem der Entscheidungsschritte S352, S354 oder S362, wo eine Lookup-Tabelle konsultiert wird, bedeutet eine Übereinstimmung zwischen einem Eintrag in der Lookup-Tabelle und einem Eintrag in der Email, dass die Email zu einer Drittpartei zwecks Prüfung umgeleitet werden soll, bevor sie aus dem Unternehmen hinaus gesendet wird. Wenn beispielsweise in Schritt S354 gefunden wird, dass die Email die Wörter ,vertraulich' oder ,geheim' enthält, dann reicht dies als Rechtfertigung dafür aus, dass die Email von einer Drittpartei geprüft wird, bevor sie zum beabsichtigten Empfänger geliefert wird. Dies stellt sicher, dass keine sensitiven Informationen ohne Kenntnis des Unternehmens aus diesem hinausgesendet werden. Die Steuerung geht daher von diesen Schritten zu Schritt S364, wo Text, der anzeigt, dass die Email umgeleitet wurde, 'zur Nachricht hinzugefügt wird, und die Empfängeradresse wird auf die der verifizierenden Partei geändert, zu der die umgeleitete Nachricht gesendet werden soll. Die Steuerung geht dann zu Schritt S366, wo die Email übertragen wird. Wenn die Email-Nachricht in Schritt S336 zum Umleiten markiert wurde, dann wird sie natürlich zur verifizierenden Partei zur Überprüfung anstatt zum ursprünglichen Empfänger der Nachricht gesendet.
  • Im Entscheidungsschritt S356 wird, wenn eine Verschlüsselung der Nachricht erfasst wird, dies als ausreichend angesehen, um das Umleiten der Nachricht zu einer Drittpartei zur Überprüfung zu rechtfertigen. Demgemäß geht die Steuerung, wenn die Nachricht verschlüsselt werden soll, von Schritt S356 zu Schritt S364, wo die Nachricht zum Umleiten modifiziert wird. Im Falle einer zur Verschlüsselung markierten Nachricht wird der Verschlüsselungsflag vorzugsweise weggenommen, so dass die Nachricht umgeleitet wird, ohne verschlüsselt zu werden, damit sie der neue Empfänger lesen kann. Der der Nachricht hinzugefügte Umleitungstext enthält vorzugsweise auch den Verschlüsselungskey (der im Allgemeinen der Public-Key des beabsichtigten Empfängers und daher nicht sensitiv ist), so dass die Nachricht vor dem Übertragen neu verschlüsselt werden kann.
  • Alternativ könnte das gesamte digitale Zertifikat des beabsichtigten Empfängers in der umgeleiteten Nachricht enthalten sein. Der Public-Key oder das Zertifikat, je nachdem, würde dann durch den oben beschriebenen automatisierten Zulassungsprozess entfernt.
  • Wenn die Email in Schritt S358 keine Anhänge enthält, dann wird die Email so angesehen, dass sie wahrscheinlich keine Dokumente oder Dateien mit potentiell sensitiven Informationen enthält, und es wird zugelassen, dass die Email ohne weitere Eingriffe in Schritt S364 übertragen wird. Wenn die Email Anhänge enthält und in Schritt S360 ermittelt wird, dass die Email im Hauptteil oder im Betreff der Nachricht keinen Text enthält, dann wird die Nachricht als eine erkannt, die wahrscheinlich zu einem anderen Konto des Senders gesendet wird. Die Email wird dann in Schritt S362 und S364 zum Prüfen zu einer Drittpartei weitergeleitet.
  • 21 zeigt den Betrieb des Einsteckmoduls zum Sperren des Heraufladens von Informationen vom Computersystem des Unternehmens zu einer externen Site. Es erfolgt ein einfacher zweistufiger Check, der einen Check der externen Site-Adresse in S372 nach dem Start in Schritt S370 und einen Check von sensitiven Schlüsselwörtern in den in Schritt S374 heraufgeladenen Informationen enthält. Vorausgesetzt, die externe Site-Adresse wird in Schritt S373 nicht als eine verbotene Site ermittelt und es werden in Schritt S374 keine sensitiven Schlüsselwörter erfasst, wird das Heraufladen in Schritt S376 zugelassen, sonst wird das Heraufladen in Schritt S378 gesperrt.
  • Die Richtliniendaten zum Steuern des Betriebs des Einsteckmoduls zum selektiven Sperren des Heraufladens von Informationen sind einfach und sind unten in 19 aufgeführt.
  • Auf diese Weise können abgehende Übertragungen, die sensitive Informationen enthalten, die aus nicht im Interesse des Unternehmens liegenden Gründen übertragen werden sollen, vor der Übertragung verifiziert und eine Übertragung falls nötig verhindert werden.
  • Verwalten des Weiterleitens von Emails
  • Email-Anwendungen bieten ein Mittel zum ,Weiterleiten' eingehender Mails zu einem oder mehreren Benutzern. Der Benutzer klickt typischerweise eine „Weiterleiten"- Schaltfläche an, die bewirkt, dass eine Kopie der eingehenden Mail automatisch in das Mail-Verfassungsfenster eingegeben wird, so als wenn sie der Benutzer selbst eingetastet hätte. Dann braucht der Benutzer lediglich die Namen der beabsichtigten Empfänger der weitergeleiteten Mail einzugeben und die „Senden"-Schaltfläche anzuklicken. Dies ist ein nützliches Merkmal, mit dem ein Benutzer den Inhalt einer empfangenen Email leicht mit anderen gemeinsam nutzen kann.
  • Ein Problem kann jedoch im Falle einer Mail entstehen, die sensitive Informationen enthält, besonders dann, wenn die sensitive Natur der Mail nicht sofort offensichtlich ist, z. B. dann, wenn die sensitiven Informationen weiter unten in der Email erscheinen, so dass der Benutzer durch das Betrachtungsfenster rollen muss, um sie zu lesen. Benutzer leiten Emails häufig weiter, sobald sie die ersten paar Zeilen, oder in einigen Fällen auch nur die Betreffzeile, gelesen haben, besonders dann, wenn sie große Mengen an Emails verarbeiten müssen. Demzufolge werden sensitive Informationen häufig unabsichtlich weitergegeben, sowohl innerhalb als auch, was noch gefährlicher ist, außerhalb der Organisation. Es hat mehrere High-Profile-Fälle gegeben, bei denen infolgedessen erhebliche Summen verloren gegangen sind.
  • Das bevorzugte System stellt daher Mittel zum Steuern des Weiterleitens von Emails bereit. Zu solchen Steuerfunktionen gehören Warnhinweise für den Benutzer, bevor eine weitergeleitete Email übertragen wird, und das Verhindern, dass die Email überhaupt weitergeleitet wird. Es können auch Mittel vorgesehen werden, um die Email vor der Übertragung zuzulassen oder um zu einem anderen Benutzer umzuleiten, wie oben beschrieben.
  • Eine Weiterleitung erfolgt vorzugsweise gemäß dem Inhalt der Email und der Adressen der Empfänger, zu denen sie bereits gesendet wurde. So kann beispielsweise die sensitive Natur der Email mit einer Reihe von Methoden ermittelt werden, wie z. B. Scannen nach Schlüsselwörtern wie „vertraulich" oder Prüfen, ob das Sensitivitätsattribut auf „persönlich", „privat" oder „vertraulich" gesetzt ist. Mittel für den ursprünglichen Verfasser der Nachricht, diese als für eine spätere Weiterleitung ungeeignet zu markieren, werden ebenfalls durch Einfügen vorbestimmter Zeichenketten bereitgestellt, wie z. B. „<NOFORWARD>" (was jede Weiterleitung verhindert) oder „<NOFORWARDEXTERNAL>" (was eine Weiterleitung außerhalb der Organisation verhindert). Solche Mittel könnten auch in Form eines zusätzlichen Attributs zu der Nachricht vorgesehen werden.
  • Zusätzlich zu inhaltsgestützten Faktoren fragt das bevorzugte System die Liste von vorherigen Empfängern der Nachricht ab. Wenn die Email bereits vom ursprünglichen Verfasser aus der Organisation hinaus gesendet wurde, dann kann sie beispielsweise als sicher angesehen werden, so dass sie auch weiter extern weitergeleitet werden kann. Ebenso kann festgestellt werden, wenn die ursprüngliche Email nur zu einem einzigen Empfänger gesendet wurde, dass der ursprüngliche Verfasser keine große Verbreitung beabsichtigt, und es kann eine entsprechende Warnung ausgegeben werden. Der Aktionsverlauf als Reaktion auf die beschriebenen Faktoren kann im Einklang mit den Richtlinien bestimmt werden.
  • Die Tatsache, dass eine Email, die vor der Übertragung steht, eine weitergeleitete Email ist, kann leicht durch Absuchen der Email nach Zeichenketten wie „----Original Message----„ festgetellt werden, die automatisch zu Beginn der ursprünglichen Mail vom Email-Programm hinzugefügt wird. Ebenso kann die Liste früherer Empfänger durch Scannen nach den Zeichenketten „An:" und „Cc:" ermittelt werden, die auf die ursprüngliche Nachrichtenfolge folgen. Die Liste von Empfängern befindet sich unmittelbar hinter diesen Zeichenketten. Interne und externe Empfänger können leicht anhand der Bereichsnamen (ggf.) unterschieden werden. So ist beispielsweise ein Empfängername „Fred Smith" gewöhnlich intern, während „fsmith@xyz.com typischerweise extern ist.
  • Richtliniendaten zum Anweisen des Betriebs eines implementierten Einsteckmoduls zum Steuern des Weiterleitens von Email-Nachrichten sind in 22 dargestellt, der Betrieb eines solchen Moduls in 23.
  • Der Richtliniendatenbaum enthält eine Reihe von Unterzweigen, die Parameter vorgeben, anhand derer Befehlswerte eingestellt werden können. So weist beispielsweise der erste Unterzweig „PreventAll", wenn er auf ,JA' gesetzt ist, das Modul an, die Weiterleitung aller Emails zu verhindern. Der nächste Unterzweig WarnAll verlangt, wenn er auf JA gesetzt ist, dass das Modul dem Email-Client-Benutzer immer einen Warnhinweis gibt, wenn eine Email vor der Weiterleitung steht. Die nächsten beiden Unterzweige PreventExternal und WarnExternal enthalten entsprechende Parameter nur für externe Emails und lassen es zu, dass der Benutzer des Email-Client zwischen Regeln, die das Weiterleiten von Emails innerhalb des Unternehmens beeinflussen, und solchen unterscheidet, die das Weiterleiten von Emails zu Personen außerhalb des Unternehmens betreffen. Der „PreventKeywords"-Zweig gibt eine Lookup-Tabelle vor, in der Schlüsselwörter gespeichert sind, die sensitive Informationen anzeigen. Solche Schlüsselwörter können vordefinierte Zeichenketten wie <NOFORWARD> oder <NOFORWARDEXTERNAL> oder ein oder mehrere vorbestimmte Wörter sein.
  • Die Email wird vor der Übertragung gescannt und wenn ein Schlüsselwort im Text der Email oder in einem der Anhänge der Email gefunden wird, dann wird eine Weiterleitung der Email nicht zugelassen. Die letzten beiden Unterzweige PreventIfNotSentExternally verhindern, wenn sie auf JA gesetzt sind, eine Übertragung der weitergeleiteten Email außerhalb des Unternehmens, wenn sie bis dahin noch nie außerhalb des Unternehmens übertragen wurde. In der Praxis kann die weitergeleitete Email zu allen Empfängern innerhalb des Unternehmens gesendet werden und die externen Empfänger werden einfach aus der Empfängerliste gelöscht, alternativ kann vom Benutzer verlangt werden, die Adressliste vor der Übertragung so zu ändern, dass sie keine externen Empfänger enthält.
  • Schließlich verhindert der Parametersatz auf dem PreventIfSingleRecipient-Zweig, wenn er auf JA gesetzt ist, eine Weiterleitung von Email-Nachrichten, wenn der ursprüngliche Empfänger der Nachricht eine Einzelperson war.
  • Der Betrieb des Einsteckmoduls ist in 23 illustriert. Das Einsteckmodul wird in Schritt S380 gestartet, wieder an Punkt B in 5. Im Entscheidungsschritt S382 wird die Email vorgescannt, um zu sehen, ob sie die Zeichenkette „----Original Message----„ enthält, da diese Zeichenkette automatisch zu Beginn der ursprünglichen Mail vom Email-Programm beim Erzeugen einer Nachricht zum Weiterleiten hinzugefügt wird. Wenn die Email-Nachricht diese Zeichenkette nicht enthält, dann kann davon abgeleitet werden, dass die Email-Nachricht eine ursprüngliche Nachricht ist und nicht weitergeleitet wird, und die Nachricht kann in Schritt S384 übertragen werden.
  • Wenn jedoch in Schritt S382 gefunden wird, dass die Nachricht die Zeichenkette „----Original Message----„ enthält, dann ist klar, dass die Email-Nachricht eine weitergeleitete Nachricht ist und das Modul unternimmt weitere Schritte, um zu ermitteln, ob es die Übertragung der weitergeleiteten Nachricht zulassen soll oder nicht. Die Steuerung geht dann zu Schritt S386, wo die Empfänger der weitergeleiteten Nachricht geprüft werden, um zu sehen, ob einige davon extern zu dem Online-Unternehmen sind. Wenn es einen externen Empfänger gibt, dann scannt das Einsteckmodul in Schritt S388 die Email-Nachricht, um zu sehen, ob die Email schon einmal zu einem Empfänger außerhalb des Unternehmens weitergeleitet wurde. Wenn nicht, dann wird in Schritt S390 verhindert, dass die Nachricht weitergeleitet wird, und der Benutzer des Email-Client wird benachrichtigt. Wenn die Email-Nachricht jedoch bereits einmal aus dem Unternehmen hinaus gesendet wurde, dann wird dem Benutzer in Schritt S392 ein Warnhinweis gegeben, wonach die Email-Nachricht entweder vom Benutzer übertragen oder zwecks Revision der beabsichtigten Empfänger zum Benutzer zurückgesendet werden kann.
  • Wenn die weitergeleitete Nachricht in Schritt S386 nicht zu einer Adresse außerhalb des Unternehmens gesendet werden soll, dann geht die Steuerung zu Schritt S394, wo ermittelt wird, ob der Benutzer der einzige Empfänger der ursprünglichen Nachricht war. Wenn ja, dann kann es der Fall sein, dass der ursprüngliche Verfasser der Nachricht nicht beabsichtigt hat, dass diese weit verbreitet werden soll. Demgemäß geht die Steuerung zu Schritt S390, wo die Übertragung der weitergeleiteten Email-Nachricht gesperrt wird. Dies entspricht den in 22 gezeigten Richtliniendaten, die eine solche Aktion vorgeben.
  • Alternativ kann ein Warnhinweis an den Benutzer ausgegeben werden, der versucht, die Nachricht weiterzuleiten.
  • Der letzte Check erfolgt im Entscheidungsschritt S396, wo der Inhalt der Nachricht und eventueller Anhänge daran mit Einträgen in einer Schlüsselworttabelle verglichen werden. Wenn es Übereinstimmungen zwischen Einträgen in der Email und denen in der Tabelle gibt, dann wird die Nachricht so angesehen, dass sie sensitive Informationen enthält, und wird nicht weitergeleitet. Das Modul endet dann in Schritt S390. Wenn keine sensitiven Schlüsselwörter gefunden werden, dann wird zugelassen, dass die Email in Schritt S384 weitergeleitet wird.
  • Verwalten des Signierens von abgehenden Übertragungen
  • Die Möglichkeit, ein digitales Zertifikat zum Signieren einer Nachricht zu benutzen, ist für den Empfänger der Nachricht beim Feststellen der Identität des Senders und für beide Parteien beim Sicherstellen, dass nicht betrügerisch in die Nachricht eingegriffen wurde, deutlich wertvoll. Der Sender der Nachricht sollte sich jedoch der Tatsache bewusst sein, dass eine digital signierte Nachricht potentiell einen bindenden Vertrag darstellt, der nach dem Senden nicht verweigert oder widerrufen werden kann. Es ist daher zwingend notwendig, beim digitalen Signieren eines Dokuments vorsichtig zu sein, genau wie wenn eine schriftliche Unterschrift auf ein Papierdokument gesetzt wird. Email-Anwendungen wie z. B. „Gutlook" von Microsoft bieten Mittel, um Nachrichten automatisch digital zu signieren, und während dies aus den oben beschriebenen Gründen für den Empfänger zum Bestätigen der Identität des Senders wertvoll ist, ist es auch potentiell gefährlich und verlangt vom Benutzer äußerste Vorsicht beim Umgang mit dem Nachrichteninhalt.
  • Das bevorzugte System stellt Mittel zum Steuern des Signierens von abgehenden Nachrichten gemäß Richtliniendaten bereit. 24 zeigt ein Beispiel für Richtliniendaten. Zu solchen Steuerungen gehören:
    das Erzwingen des Signierens einer Nachricht;
    das Nahelegen dem Benutzer, dass eine Nachricht signiert werden sollte;
    das Nahelegen dem Benutzer, dass eine Nachricht NICHT signiert werden sollte; und
    das Verhindern des Signierens einer Nachricht.
  • Beim Feststellen des durchzuführenden Aktionsverlaufs berücksichtigt das bevorzugte System eine Reihe von Faktoren, einschließlich der Natur des Nachrichteninhalts (einschließlich eventueller Anhänge), der Identität des beabsichtigten Empfängers und/oder seiner Organisation, der Identität des Senders, der Natur des verwendeten digitalen Zertifikats (ob die Nachricht bereits für eine Signatur markiert wurde) und der Natur des/der digitalen Zertifikats/e, das/die zum Signieren der Nachricht zur Verfügung steht/stehen.
  • Die Natur der Nachricht kann durch Scannen der Nachricht nach einem oder mehreren Schlüsselwörtern oder Schlüsselwortkombinationen oder durch Anwenden von standardmäßigen ,natürlichsprachliche Abfrage'-Techniken ermittelt werden. Ebenso kann die Natur der beabsichtigten oder verfügbaren digitalen Zertifikate durch Bezugnahme auf den Ausgeber und den Typ des Zertifikats ermittelt werden.
  • 25 illustriert den Betrieb eines Einsteckmoduls zum Sicherstellen, dass eine Email ordnungsgemäß digital signiert wird. Das Modul wird in Schritt S400 an Punkt B in dem in 5 illustrierten Betrieb des Email-Client gestartet. Die Steuerung geht dann zum Entscheidungsschritt S402, wo die abgehende Email gescannt wird, um zu sehen, ob sie bereits zur Signatur markiert wurde. Das eigentliche ,Signieren' der Nachricht erfolgt erst unmittelbar vor der Übertragung. Wenn sie nicht für eine Signatur markiert wurde, dann geht die Steuerung zu Schritt S404, wo das Modul in einer Empfänger-Lookup-Tabelle (Tabelle f) nachschlägt, um zu ermitteln, ob der Empfänger der abgehenden Email als einer identifiziert ist, zu dem Emails immer digital signiert werden müssen. Wenn der Empfänger in Tabelle f aufgeführt ist, dann geht die Steuerung zu Schritt S406, wo der Benutzer des Email-Client benachrichtigt wird, dass die Email nur dann gesendet wird, wenn sie digital signiert wird. Alternativ kann das Einsteckmodul die Email mit dem digitalen Zertifikat des Email-Autors automatisch digital signieren.
  • Wenn der Empfänger der abgehenden Email in Schritt S404 nicht in der Lookup-Tabelle steht, dann geht die Steuerung zum Entscheidungsschritt S408, wo die Keywords-Tabelle auf dem EnforceSigning-Zweig des Richtlinienbaums befragt wird. Falls die Schlüsselwörter aus Tabelle g im Text der Email oder in einem der Anhänge der Email stehen, dann ist eine digitale Signatur der Email erforderlich und die Steuerung geht wie zuvor zu Schritt S406. Man wird verstehen, dass die Entscheidungsschritte S404 und S406 Lookup-Befehlen zum Nachschlagen in den Recipients- und Keywords-Lookup-Tabellen auf dem EnforceSigning-Zweig der Richtliniendaten entspricht.
  • Solche Schlüsselwörter können vorbestimmte Wörter wie „vertraulich", „geheim", „Vertrag", „Angebot", „Auftrag" usw. wie in 24 illustriert sein.
  • Wenn die Empfänger der Email nicht in Tabelle f stehen und die Email keine in Tabelle g aufgeführten Schlüsselwörter enthält, dann geht die Steuerung zum Entscheidungsschritt S410, der einem Lookup-Befehl auf dem SuggestSigning-Zweig des Richtliniendatenbeispiels entspricht. Im Entscheidungsschritt S410 wird die Adresse des Empfängers mit der in der Lookup-Tabelle h verglichen, um zu ermitteln, ob eine Signierung der Email angeraten ist. Wenn der Name des Empfängers in Tabelle h steht, dann geht die Steuerung zu Schritt S412, wo der Benutzer des Email-Client benachrichtigt wird, dass eine digitale Signierung der abgehenden Email-Nachricht wünschenswert ist. Es ist aber nicht unbedingt erforderlich, dass der Benutzer des Email-Client die Email-Nachricht digital signiert, und die Email kann daher ohne Signatur übertragen werden, wenn der Benutzer dies wünscht. Nach dem Entscheidungsschritt S410 geht die Steuerung, wenn der Name des Empfängers nicht in Tabelle h steht, zum Entscheidungsschritt S414, wo der Email-Text wie zuvor nach einer Reihe von Schlüsselwörtern durchsucht wird, die anzeigen könnten, dass er sensitive Daten enthält und eine digitale Signatur benötigt. Je nachdem, ob die Email solche sensitiven Schlüsselwörter enthält, wird der Benutzer des Email-Client entweder in Schritt S412 benachrichtigt, dass es wünschenswert ist, die Nachricht digital zu signieren, oder alternativ wird die Email-Nachricht in Schritt S416 ohne Signatur übertragen.
  • Wenn in Schritt S402 nach dem Starten des Einsteckmoduls gefunden wird, dass die Email für eine Signatur markiert wurde, dann geht die Steuerung zum Entscheidungsschritt S418. Im Entscheidungsschritt S418 konsultiert das Einsteckmodul die Lookup-Tabelle m im DenySigning-Zweig, vorgegeben unter dem DenySigning-Zweig der Richtliniendaten. Tabelle m ist auf dem CertificatesUsed-Zweig unter dem DenySigning-Zweig vorgegeben und gibt den Aussteller, den Typ, die Zertifikatnummer oder den Signierungskey der digitalen Zertifikate an, die als von Interesse angesehen werden. Falls sich das digitale Zertifikat oder der Signierungskey, das/der zum Signieren der abgehenden Email benutzt werden soll, in Tabelle m befindet, erfolgen weitere Checks in Bezug auf den Empfänger und die Natur der abgehenden Email, um zu ermitteln, ob eine Signierung der Nachricht angemessen ist oder nicht. Die Steuerung geht zu Schritt S420, wo der Empfänger der abgehenden Email anhand der Recipient-Tabelle n geprüft wird, und dann zum Entscheidungsschritt S422, wo der Text der Email und eventuelle Anhänge nach verschiedenen Schlüsselwörtern abgesucht werden. Wenn in einem der Entscheidungsschritte S420 oder S422 der Empfänger oder ein eventueller Text in der Nachricht mit dem in den Lookup-Tabellen definierten übereinstimmt, dann geht die Steuerung zu Schritt S424, wo die Übertragung der Email gesperrt wird. Der Benutzer des Email-Client kann dann zur Email-Texteingabestufe zurückgeführt werden und es kann von ihm verlangt werden, die Nachricht ohne digitale Signierung neu zu übertragen.
  • Wenn in einem der Schritte S418 oder S422 gefunden wird, dass das Zertifikat oder der Signierungskey nicht von Interesse ist, und wenn im Text der Email keine sensitiven Wörter gefunden werden, dann geht die Steuerung zu Schritt S426, der dem ersten Unterzweig auf dem SuggestNotSigning-Zweig des Richtliniendatenbaums entspricht. Was den DenySigning-Zweig des Richtliniendatenbaums angeht, so entsprechen die drei Entscheidungsschritte S426, S428 und S430 den Lookup-Befehlen zum Prüfen des mit der Email verwendeten digitalen Zertifikats oder Signierungskeys, des Empfängers der abgehenden Email und des Texts der abgehenden Email mit vorbestimmten sensitiven Einträgen jeweils in den Lookup-Tabellen j, k und l. Wenn gefunden wird, dass das zum Signieren der abgehenden Email benutzte Zertifikat in Schritt S426 von Interesse ist, und wenn in Schritt S426 oder in Schritt S430 gefunden wird, dass der Empfänger oder der Text der abgehenden Email mit Einträgen in den vorgegebenen Lookup-Tabellen übereinstimmt, dann geht die Steuerung zu Schritt S432, wo der Benutzer des Email-Client benachrichtigt wird, dass es wünschenswert ist, die abgehende Email-Nachricht nicht digital zu signieren. Der Benutzer kann die signierte Email-Nachricht jedoch weiterhin senden, wenn er dies wünscht.
  • Wenn in einem der Entscheidungsschritte S426, S428 und S430 keine Übereinstimmung gefunden wird, dann wird die Email in Schritt S416 normal gesendet.
  • Instant-Messaging- und Telefonieanwendungen
  • Zusätzlich zu Browser- und Email-Aktivitäten werden auch zusätzliche Anwendungen wie Instant Messaging (auch als ,Chatten' bekannt) und digitale Telefonieanwendungen (wie „Voice Over OP") in Geschäftssituationen immer populärer. Instant-Messaging-Standards sind in RFC 2778 und 2779 und von der IETF SIMPLE Arbeitsgruppe definiert. Voice Over-IP-Standards sind in der ITU-T Empfehlung H.323 (1998) definiert. Viele Aspekte der vorliegenden Erfindung können auf von solchen Anwendungen gesendete und empfangene Daten angewendet werden. Instant Messaging ist von der Idee her einer Reihe von gesendeten und empfangenen Emails ähnlich, mit der Ausnahme, dass die ,Konversation' ,live' erfolgt, wobei beide Parteien ständig anwesend sind. Für die Zwecke der vorliegenden Erfindung sind die Prozeduren jedoch identisch. 5 der Zeichnungen kann Instant Messaging durch Ersetzen des Wortes „Email" in den Schritten S122, S124, S132 und S134 durch das Wort „Nachricht" repräsentieren. Die „Email-Server"-Beschreibung 95 wird durch „Nachrichtenrelais" ersetzt. Die bevorzugte Ausgestaltung ist zum Abfangen an den Punkten A und B wie zuvor gestaltet, indem ein Einsteckmodul zur Internet Messaging Anwendung bereitgestellt oder indem eine Instant Messaging Anwendung entwickelt wird, die die Einsteckfunktionalität enthält. Alternativ wird man verstehen, dass das Abfangen auf Protokollebene erfolgen könnte, wobei Netzwerkpakete abgefangen werden, bevor sie die Benutzermaschine verlassen oder wenn sie an der Benutzermaschine ankommen.
  • VOIP (Voice Over Internet Protocol) ist vom Konzept her dem Instant Messaging ähnlich, mit der Ausnahme, dass der Nachrichteninhalt aus digitalisierter Sprache besteht, die codiert und sofort übertragen wird. Eine Analyse des Nachrichteninhalts ist unpraktisch, aber Mittel zum Aufzeichnen der Nachricht und zum Setzen von Controls auf ,Anruf'-Ebene sind durchführbar und werden auf ähnliche Weise implementiert, entweder als Einsteckmodul zur Voice-Messaging-Anwendung oder auf Netzwerkprotokollebene, beide innerhalb der Benutzermaschine.
  • Es wurde zwar die Implementation des bevorzugten Systems mit Bezug auf Einsteckmodule für existierende Anwendungen beschrieben, aber die Erfindung kann auch durch Bereitstellen von Webbrowsern, Email-Clients, Instant-Messaging-Anwendungen oder Voice Over IP Anwendungen implementiert werden, bei denen die Funktionalität der hier beschriebenen Einsteckmodule bereits von Anfang an codiert wird.

Claims (64)

  1. Informationsmanagementsystem, das Folgendes umfasst: eine oder mehrere Workstations für den Anschluss an ein Computernetz (10), wobei jede Workstation einen Speicher aufweist; eine Anwendung, die in dem genannten Speicher jeder Workstation gespeichert ist, um abgehende Daten' zu dem genannten Netz zu senden und eingehende Daten von dem genannten Netz zu empfangen; einen Analysator, der in die Anwendung integriert ist und die Aufgabe hat, in Verbindung mit Richtliniendaten Folgendes auszuführen: a) Überwachen der genannten abgehenden Daten und Ermitteln, beim Einleiten des Sendens der abgehenden Daten und gemäß Richtliniendatenregeln, einer geeigneten Verschlüsselungsstärke für die abgehenden Daten; und b) Steuern des Sendens der genannten abgehenden Daten von der genannten Anwendung in Abhängigkeit von der genannten Ermittlung einer geeigneten Verschlüsselungsstärke; wobei die Richtliniendaten zentral definiert werden und Regeln enthalten, die eine geeignete Verschlüsselungsstärke für abgehende Daten vorgeben, wobei die Verschlüsselungsstärke vom Inhalt der Daten abhängig ist.
  2. System nach Anspruch 1, wobei die genannten Regeln in den genannten Richtliniendaten vertrauliche Daten definieren, die nicht gesendet werden dürfen, wobei der genannte Analysator die Aufgabe hat, in Verbindung mit den genannten Richtliniendaten zu verhindern, dass die genannten vertraulichen Daten von der genannten Anwendung gesendet werden.
  3. System nach Anspruch 1 oder 2, wobei der genannte Analysator ferner die Aufgabe hat, die aktuelle Verschlüsselungsstärke beim Gebrauch zum Senden der genannten abgehenden Daten zu ermitteln; und wobei der genannte Analysator das Senden der genannten abgehenden Daten von der genannten Anwendung sowohl in Abhängigkeit von der genannten Ermittlung einer geeigneten Verschlüsselungsstärke als auch in Abhängigkeit von der genannten Ermittlung der aktuellen Verschlüsselungsstärke beim Gebrauch steuert.
  4. System nach Anspruch 3, wobei dann, wenn der Analysator ermittelt, dass die aktuelle Verschlüsselungsstärke beim Gebrauch zum Senden von abgehenden Daten geringer ist als die genannte geeignete Verschlüsselungsstärke, der genannte Analysator das Senden der genannten abgehenden Daten von der genannten Anwendung verhindert.
  5. System nach Anspruch 3, wobei dann, wenn der Analysator ermittelt, dass die aktuelle Verschlüsselungsstärke beim Gebrauch zum Senden von abgehenden Daten geringer ist als die genannte geeignete Verschlüsselungsstärke, der genannte Analysator das Senden der genannten abgehenden Daten für die genannte Anwendung verhindert und die genannte Anwendung so steuert, dass sie eine Verschlüsselungsstärke zum Senden neu negoziiert, die geeignet ist.
  6. System nach Anspruch 3, wobei dann, wenn der Analysator ermittelt, dass die aktuelle Verschlüsselungsstärke beim Gebrauch zum Senden von abgehenden Daten geringer ist als die genannte geeignete Verschlüsselungsstärke, der genannte Analysator die abgehenden Daten so modifiziert, dass die aktuelle Verschlüsselungsstärke eine geeignete Verschlüsselungsstärke zum Senden der modifizierten abgehenden Daten ist.
  7. System nach Anspruch 3, wobei dann, wenn der Analysator ermittelt, dass die aktuelle Verschlüsselungsstärke beim Gebrauch zum Senden von abgehenden Daten geringer ist als die genannte geeignete Verschlüsselungsstärke, der genannte Analysator die genannte Anwendung so steuert, dass sie einen Benutzer der genannten Anwendung avisiert, dass die Verschlüsselungsstärke beim Gebrauch nicht ausreicht.
  8. System nach einem der vorherigen Ansprüche, wobei der Analysator ferner die Aufgabe hat, Kreditkartennummern in den genannten abgehenden Daten zu identifizieren.
  9. System nach Anspruch 8, wobei der Analysator ferner die Aufgabe hat, einen vorbestimmten Satz von Kreditkartennummern von anderen Kreditkartennummern zu unterscheiden, wobei die genannten Regeln der genannten Richtliniendaten andere geeignete Verschlüsselungsstärken für abgehende Daten, die Kreditkartennummern in dem vorbestimmten Satz enthalten, definieren als für andere Kreditkartennummern.
  10. System nach Anspruch 9, wobei die genannten Regeln der genannten Richtliniendaten vorgeben, dass es keine geeignete Verschlüsselungsstärke für einen vorbestimmten Satz von einer oder mehreren Kreditkartennummern gibt.
  11. System nach einem der vorherigen Ansprüche, wobei der genannte Analysator ferner die Aufgabe hat, ein oder mehrere Kreditkartennummern, Kontocodes, Benutzernamen, Passwörtern, Namen und Adressen und/oder andere vorbestimmte Schlüsselwörter im Inhalt der genannten abgehenden Daten zu identifizieren.
  12. System nach einem der vorherigen Ansprüche, wobei die genannten Regeln in den genannten Richtliniendaten eine geeignete Verschlüsselungsstärke für die genannten abgehenden Daten vorgeben, d. h. in Abhängigkeit von der Adresse, zu der die genannten abgehenden Daten gesendet werden sollen.
  13. System nach einem der vorherigen Ansprüche, wobei die genannte Anwendung ein Web-Browser ist.
  14. System nach Anspruch 13, wobei der genannte Analysator ein Einsteck-Modul (70, 72) des genannten Web-Browsers ist.
  15. System nach Anspruch 14, wobei der genannte Web-Browser der Microsoft Internet Explorer ist und der genannte Analysator ein Browser Helper Object ist.
  16. System nach einem der Ansprüche 1 bis 12, wobei die genannte Anwendung ein Email-Client ist.
  17. System nach Anspruch 16, wobei der genannte Analysator ein Einsteck-Modul (74) des genannten Email-Client ist.
  18. System nach Anspruch 17, wobei der genannte Email-Client der Microsoft Gutlook Email-Client ist und der genannte Analysator eine Microsoft-Client-Erweiterung ist.
  19. System nach einem der Ansprüche 1 bis 12, wobei die genannte Anwendung eine Instant-Messaging-Anwendung ist.
  20. System nach Anspruch 19, wobei der genannte Analysator ein Einsteck-Modul der genannten Instant-Messaging-Anwendung ist.
  21. System nach einem der vorherigen Ansprüche, wobei das genannte Computernetz, an das eine oder mehrere Workstation(s) angeschlossen werden kann/können, ein öffentliches Computernetz ist, und wobei die genannten ein oder mehreren Workstations zusammen ein privates Computernetz bilden.
  22. System nach einem der vorherigen Ansprüche, das ferner eine Supervisor-Workstation umfasst, wobei die genannte Supervisor-Workstation auf die genannten Richtliniendaten zugreifen kann, so dass ein Benutzer der genannten Supervisor-Workstation die genannten Richtliniendaten bearbeiten kann.
  23. Verfahren zum Verwalten von Informationen, das die folgenden Schritte beinhaltet: Bereitstellen von einer oder mehreren Workstation(s) für den Anschluss an ein Computernetz (10), wobei jede Workstation einen Speicher hat; Bereitstellen einer in dem genannten Speicher jeder Workstation gespeicherten Anwendung zum Senden von abgehenden Daten zu dem genannten Netzwerk und zum Empfangen von eingehenden Daten von dem genannten Netzwerk; Analysieren, mittels eines Analysators, der in die Anwendung integriert ist, der genannten abgehenden Daten, um beim Einleiten des Sendens der abgehenden Daten und gemäß Richtliniendatenregeln eine geeignete Verschlüsselungsstärke für die abgehenden Daten zu ermitteln; und Steuern des Sendens der genannten abgehenden Daten von der genannten Anwendung gemäß der Ermittlung einer geeigneten Verschlüsselungsstärke in dem genannten Analyseschritt; wobei die Richtliniendaten zentral definiert werden und Regeln enthalten, die eine geeignete Verschlüsselungsstärke für abgehende Daten vorgeben, wobei die Verschlüsselungsstärke vom Inhalt der Daten abhängig ist.
  24. Verfahren nach Anspruch 23, wobei die genannten Regeln in den genannten Richtliniendaten vertrauliche Daten definieren, die nicht gesendet werden dürfen, und wobei in dem genannten Steuerschritt das Senden der genannten vertraulichen Daten verhindert wird.
  25. Verfahren nach Anspruch 23 oder 24, wobei der genannte Analyseschritt ferner den Schritt des Ermittelns der aktuellen Verschlüsselungsstärke beim Gebrauch zum Senden der genannten abgehenden Daten umfasst; und wobei in dem genannten Steuerschritt das Senden der genannten abgehenden Daten von der genannten Anwendung sowohl von der Ermittlung einer geeigneten Verschlüsselungsstärke als auch von der Ermittlung der aktuellen Verschlüsselungsstärke beim Gebrauch abhängig ist.
  26. Verfahren nach Anspruch 25, wobei dann, wenn ermittelt wird, dass die aktuelle Verschlüsselungsstärke beim Gebrauch zum Senden der abgehenden Daten geringer ist als die genannte geeignete Verschlüsselungsstärke, in dem genannten Steuerschritt das Senden der genannten abgehenden Daten von der genannten Anwendung verhindert wird.
  27. Verfahren nach Anspruch 25, wobei dann, wenn in dem genannten Analyseschritt ermittelt wird, dass die aktuelle Verschlüsselungsstärke beim Gebrauch zum Senden von abgehenden Daten geringer ist als die genannte geeignete Verschlüsselungsstärke, in dem genannten Steuerschritt eine Verschlüsselungsstärke, die zum Senden der genannten abgehenden Daten geeignet ist, vor dem Senden negoziiert wird.
  28. Verfahren nach Anspruch 25, wobei dann, wenn in dem genannten Analyseschritt ermittelt wird, dass die aktuelle Verschlüsselungsstärke beim Gebrauch zum Senden von abgehenden Daten geringer ist als die genannte geeignete Verschlüsselungsstärke, in dem genannten Steuerschritt die abgehenden Daten so modifiziert werden, dass die aktuelle Verschlüsselungsstärke eine geeignete Verschlüsselungsstärke ist.
  29. Verfahren nach Anspruch 25, wobei in dem genannten Analyseschritt, wenn ermittelt wird, dass die aktuelle Verschlüsselungsstärke beim Gebrauch zum Senden von abgehenden Daten geringer ist als die genannte geeignete Verschlüsselungsstärke, in dem genannten Steuerschritt ein Benutzer der genannten Anwendung avisiert wird, dass die Verschlüsselungsstärke beim Gebrauch nicht ausreicht.
  30. Verfahren nach einem der Ansprüche 23 bis 29, wobei der genannte Analyseschritt das Identifizieren von Kreditkartennummern in den genannten abgehenden Daten beinhaltet.
  31. Verfahren nach Anspruch 30, wobei der genannte Analyseschritt das Unterscheiden eines vorbestimmten Satzes von einer oder mehreren Kreditkartennummern von anderen Kreditkartennummern beinhaltet, und wobei die genannten Regeln der genannten Richtliniendaten eine andere geeignete Verschlüsselungsstärke für abgehende Daten, die Kreditkartennummern enthalten, in diesem vorbestimmten Satz definiert als für andere Kreditkartennummern.
  32. Verfahren nach Anspruch 31, wobei die genannten Regeln der genannten Richtliniendaten vorgeben, dass es keine geeignete Verschlüsselungsstärke für den genannten vorbestimmten Satz von einer oder mehreren Kreditkartennummern gibt.
  33. Verfahren nach einem der Ansprüche 23 bis 32, wobei der genannte Analyseschritt das Identifizieren von ein oder mehreren Kreditkartennummern, Kontocodes, Benutzernamen, Passwörtern, Namen und Adressen und/oder anderen vorbestimmten Schlüsselwörtern im Inhalt der genannten abgehenden Daten beinhaltet.
  34. Verfahren nach einem der Ansprüche 23 bis 33, wobei die genannten Regeln in den genannten Richtliniendaten eine geeignete Verschlüsselungsstärke für die genannten abgehenden Daten vorgeben, die von der Adresse abhängig ist, zu der die genannten abgehenden Daten gesendet werden sollen.
  35. Verfahren nach einem der Ansprüche 23 bis 34, wobei die genannte Anwendung ein Web-Browser ist.
  36. Verfahren nach Anspruch 35, wobei der genannte Analyseschritt durch ein Einsteck-Modul (70, 72) des genannten Web-Browsers ausgeführt wird.
  37. Verfahren nach Anspruch 36, wobei der genannte Web-Browser der Microsoft Internet Explorer ist und das genannte Einsteck-Modul ein Browser Helper Object ist.
  38. Verfahren nach einem der Ansprüche 23 bis 34, wobei die genannte Anwendung ein Email-Client ist.
  39. Verfahren nach Anspruch 38, wobei der genannte Analyseschritt durch ein Einsteck-Modul (74) des genannten Email-Client ausgeführt wird.
  40. Verfahren nach Anspruch 39, wobei der genannte Email-Client der Microsoft Gutlook Email-Client ist und das genannte Einsteck-Modul eine Microsoft Exchange Client-Erweiterung ist.
  41. Verfahren nach einem der Ansprüche 23 bis 34, wobei die genannte Anwendung eine Instant-Messaging-Anwendung ist.
  42. Verfahren nach Anspruch 41, wobei der genannte Analysator ein Einsteck-Modul der genannten Instant-Messaging-Anwendung ist.
  43. Verfahren nach einem der Ansprüche 23 bis 42, wobei das genannte Computernetz, an das die genannten ein oder mehreren Workstations angeschlossen werden können, ein öffentliches Computernetz ist, und wobei die genannten ein oder mehreren Workstations zusammen ein privates Computernetz bilden.
  44. Verfahren nach einem der Ansprüche 23 bis 43, das ferner den Schritt des Bereitstellens einer Supervisor-Workstation beinhaltet, wobei die genannte Supervisor-Workstation auf die genannten Richtliniendaten zugreifen kann, so dass ein Benutzer der genannten Supervisor-Workstation die genannten Richtliniendaten bearbeiten kann.
  45. Computerprogrammprodukt zum Steuern eines Computers, der an ein öffentliches Netzwerk zum Verwalten von Informationen angeschlossen ist, wobei der Computer Zugang zu zentral definierten Richtliniendaten hat, die Regeln enthalten, die eine geeignete Verschlüsselungsstärke für zu dem öffentlichen Netzwerk gesendete abgehende Daten vorgeben, wobei die Verschlüsselungsstärke vom Inhalt der Daten abhängig ist, umfassend: ein vom Computer lesbares Aufzeichnungsmedium mit darauf aufgezeichnetem Programmcode, der bei Ausführung auf dem genannten Computer den genannten Computer so konfiguriert, dass er Folgendes tut: Ermitteln, beim Einleiten des Sendens von abgehenden Daten von einer auf dem Computer laufenden Anwendung mit der Aufgabe, wenigstens abgehende Daten zu dem genannten öffentlichen Netzwerk (10) zu senden, mittels eines in die Anwendung integrierten Analysators und mit Bezug auf die genannten Regeln in den genannten Richtliniendaten einer geeigneten Verschlüsselungsstärke für die abgehenden Daten; und Steuern des Sendens der genannten abgehenden Daten durch die genannte Anwendung in Abhängigkeit von der Ermittlung einer geeigneten Verschlüsselungsstärke.
  46. Computerprogrammprodukt nach Anspruch 45, wobei die genannten Regeln in den genannten Richtliniendaten vertrauliche Daten definieren, die nicht gesendet werden können, wobei der genannte Programmcode bei Ausführung auf dem genannten Computer die Aufgabe hat, das Senden der genannten vertraulichen Daten von der genannten Anwendung zu verhindern.
  47. Computerprogrammprodukt nach Anspruch 45 oder 46, wobei der genannte Programmcode bei Ausführung auf dem genannten Computer ferner die Aufgabe hat, die aktuelle Verschlüsselungsstärke beim Gebrauch zum Senden der genannten abgehenden Daten zu ermitteln; und das Senden der genannten abgehenden Daten von der genannten Anwendung in Abhängigkeit sowohl von der Ermittlung einer geeigneten Verschlüsselungsstärke als auch von der Ermittlung der aktuellen Verschlüsselungsstärke beim Gebrauch zu steuern.
  48. Computerprogrammprodukt nach Anspruch 47, wobei der genannte Programmcode bei Ausführung auf dem genannten Computer ferner die Aufgabe hat, wenn ermittelt wird, dass die aktuelle Verschlüsselungsstärke beim Gebrauch zum Senden von abgehenden Daten geringer ist als die genannte geeignete Verschlüsselungsstärke, das Senden der genannten abgehenden Daten von der genannten Anwendung zu verhindern.
  49. Computerprogrammprodukt nach Anspruch 47, wobei der genannte Programmcode bei Ausführung auf dem genannten Computer ferner die Aufgabe hat, wenn ermittelt wird, dass die aktuelle Verschlüsselungsstärke beim Gebrauch zum Senden von abgehenden Daten geringer ist als die genannte geeignete Versch1üsselungsstärke, eine geeignete Verschlüsselungsstärke zum Senden der genannten abgehenden Daten vor dem Senden zu negoziieren.
  50. Computerprogrammprodukt nach Anspruch 47, wobei der genannte Programmcode bei Ausführung auf dem genannten Computer ferner die Aufgabe hat, wenn ermittelt wird, dass die aktuelle Verschlüsselungsstärke beim Gebrauch zum Senden von abgehenden Daten geringer ist als die genannte geeignete Verschlüsselungsstärke, die abgehenden Daten so zu modifizieren, dass die aktuelle Verschlüsselungsstärke eine geeignete Verschlüsselungsstärke ist.
  51. Computerprogrammprodukt nach Anspruch 47, wobei der genannte Programmcode bei Ausführung auf dem genannten Computer ferner die Aufgabe hat, wenn ermittelt wird, dass die aktuelle Verschlüsselungsstärke beim Gebrauch zum Senden von abgehenden Daten geringer ist als die genannte geeignete Verschlüsselungsstärke, eine Avisierung zu geben, dass die Verschlüsselungsstärke beim Gebrauch nicht ausreicht.
  52. Computerprogrammprodukt nach einem der Ansprüche 45 bis 51, wobei der genannte Programmcode bei Ausführung auf dem genannten Computer ferner die Aufgabe hat, Kreditkartennummern in den genannten abgehenden Daten zu identifizieren.
  53. Computerprogrammprodukt nach Anspruch 52, wobei der genannte Programmcode bei Ausführung auf dem genannten Computer ferner die Aufgabe hat, einen vorbestimmten Satz von einer oder mehreren Kreditkartennummern von anderen Kreditkartennummern zu identifizieren, und wobei die genannten Regeln der genannten Richtliniendaten eine andere geeignete Verschlüsselungsstärke für abgehende Daten, die Kreditkartennummern enthalten, in diesem vorbestimmten Satz definieren als für andere Kreditkartennummern.
  54. Computerprogrammprodukt nach Anspruch 53, wobei die genannten Regeln der genannten Richtliniendaten vorgeben, dass es keine geeignete Verschlüsselungsstärke für den genannten vorbestimmten Satz von einer oder mehreren Kreditkartennummern gibt.
  55. Computerprogrammprodukt nach einem der Ansprüche 45 bis 54, wobei der genannte Programmcode bei Ausführung auf dem genannten Computer ferner die Aufgabe hat, eine oder mehrere Kreditkartennummern, Kontocodes, Benutzernamen, Passwörtern, Namen und Adressen und/oder anderen vorbestimmten Schlüsselwörtern im Inhalt der genannten abgehenden Daten zu identifizieren.
  56. Computerprogrammprodukt nach einem der Ansprüche 45 bis 55, wobei die genannten Regeln in den genannten Richtliniendaten eine geeignete Verschlüsselungsstärke für die genannten abgehenden Daten vorgeben, die von der Adresse abhängig ist, zu der die genannten abgehenden Daten gesendet werden sollen.
  57. Computerprogrammprodukt nach einem der Ansprüche 45 bis 56, wobei die genannte Anwendung ein Web-Browser ist.
  58. Computerprogrammprodukt nach Anspruch 57, wobei der genannte Programmcode bei Ausführung auf dem genannten Computer ein Einsteck-Modul (70, 72) des genannten Web-Browsers ist.
  59. Computerprogrammprodukt nach Anspruch 58, wobei der genannte Web-Browser der Microsoft Internet Explorer ist und das genannte Einsteck-Modul ein Browser Helper Object ist.
  60. Computerprogrammprodukt nach einem der Ansprüche 45 bis 56, wobei die genannte Anwendung ein Email-Client ist.
  61. Computerprogrammprodukt nach Anspruch 60, wobei der genannte Programmcode bei Ausführung auf dem genannten Computer ein Einsteck-Modul (74) des genannten Email-Client ist.
  62. Computerprogrammprodukt nach Anspruch 61, wobei der genannte Email-Client der Microsoft Gutlook E-Mail-Client ist und das genannte Einsteck-Modul eine Microsoft Exchange Client-Erweiterung ist.
  63. Computersoftwareprodukt nach einem der Ansprüche 45 bis 56, wobei die genannte Anwendung eine Instant-Messaging-Anwendung ist.
  64. Computersoftwareprodukt nach Anspruch 63, wobei der genannte Programmcode bei Ausführung auf dem genannten Computer ein Einsteck-Modul der genannten Instant-Messaging-Anwendung ist.
DE60132254T 2000-11-08 2001-11-08 Ein Informationsverwaltungssystem Expired - Lifetime DE60132254T2 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GBGB0027280.7A GB0027280D0 (en) 2000-11-08 2000-11-08 An information management system
GB0027280 2000-11-08
US923704 2001-08-07
US09/923,704 US7333956B2 (en) 2000-11-08 2001-08-07 Information management system

Publications (2)

Publication Number Publication Date
DE60132254D1 DE60132254D1 (de) 2008-02-14
DE60132254T2 true DE60132254T2 (de) 2008-12-18

Family

ID=9902787

Family Applications (9)

Application Number Title Priority Date Filing Date
DE60132493T Expired - Lifetime DE60132493T2 (de) 2000-11-08 2001-11-08 Ein Informationsverwaltungssystem
DE60132365T Expired - Lifetime DE60132365T2 (de) 2000-11-08 2001-11-08 Ein Informationsverwaltungssystem
DE60132369T Expired - Lifetime DE60132369T2 (de) 2000-11-08 2001-11-08 Ein Informationsverwaltungssystem
DE60132253T Expired - Lifetime DE60132253T2 (de) 2000-11-08 2001-11-08 Ein Informationsverwaltungssystem
DE60132252T Expired - Lifetime DE60132252T2 (de) 2000-11-08 2001-11-08 Ein Informationsverwaltungssystem
DE60131300T Expired - Lifetime DE60131300T2 (de) 2000-11-08 2001-11-08 Ein Informationsverwaltungssystem
DE60132495T Expired - Lifetime DE60132495T2 (de) 2000-11-08 2001-11-08 Ein Informationsverwaltungssystem
DE60132254T Expired - Lifetime DE60132254T2 (de) 2000-11-08 2001-11-08 Ein Informationsverwaltungssystem
DE60132251T Expired - Lifetime DE60132251T2 (de) 2000-11-08 2001-11-08 Ein datenverwaltungssystem

Family Applications Before (7)

Application Number Title Priority Date Filing Date
DE60132493T Expired - Lifetime DE60132493T2 (de) 2000-11-08 2001-11-08 Ein Informationsverwaltungssystem
DE60132365T Expired - Lifetime DE60132365T2 (de) 2000-11-08 2001-11-08 Ein Informationsverwaltungssystem
DE60132369T Expired - Lifetime DE60132369T2 (de) 2000-11-08 2001-11-08 Ein Informationsverwaltungssystem
DE60132253T Expired - Lifetime DE60132253T2 (de) 2000-11-08 2001-11-08 Ein Informationsverwaltungssystem
DE60132252T Expired - Lifetime DE60132252T2 (de) 2000-11-08 2001-11-08 Ein Informationsverwaltungssystem
DE60131300T Expired - Lifetime DE60131300T2 (de) 2000-11-08 2001-11-08 Ein Informationsverwaltungssystem
DE60132495T Expired - Lifetime DE60132495T2 (de) 2000-11-08 2001-11-08 Ein Informationsverwaltungssystem

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE60132251T Expired - Lifetime DE60132251T2 (de) 2000-11-08 2001-11-08 Ein datenverwaltungssystem

Country Status (12)

Country Link
US (13) US7333956B2 (de)
EP (9) EP1372100B1 (de)
JP (5) JP4354182B2 (de)
AT (9) ATE382914T1 (de)
AU (2) AU2002212549B2 (de)
CA (9) CA2566201C (de)
DE (9) DE60132493T2 (de)
DK (5) DK1360623T3 (de)
ES (5) ES2299521T3 (de)
GB (1) GB0027280D0 (de)
WO (1) WO2002039331A2 (de)
ZA (9) ZA200403533B (de)

Families Citing this family (329)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6981028B1 (en) * 2000-04-28 2005-12-27 Obongo, Inc. Method and system of implementing recorded data for automating internet interactions
US8972590B2 (en) * 2000-09-14 2015-03-03 Kirsten Aldrich Highly accurate security and filtering software
FR2815204B1 (fr) * 2000-10-10 2003-01-10 Gemplus Card Int Procede de protection contre la fraude dans un reseau par choix d'une icone
GB0027280D0 (en) * 2000-11-08 2000-12-27 Malcolm Peter An information management system
US7346928B1 (en) * 2000-12-01 2008-03-18 Network Appliance, Inc. Decentralized appliance virus scanning
US7778981B2 (en) * 2000-12-01 2010-08-17 Netapp, Inc. Policy engine to control the servicing of requests received by a storage server
US6912582B2 (en) * 2001-03-30 2005-06-28 Microsoft Corporation Service routing and web integration in a distributed multi-site user authentication system
US7178024B2 (en) 2001-04-05 2007-02-13 Sap Ag Security service for an electronic marketplace
US8095597B2 (en) 2001-05-01 2012-01-10 Aol Inc. Method and system of automating data capture from electronic correspondence
WO2002102009A2 (en) 2001-06-12 2002-12-19 Research In Motion Limited Method for processing encoded messages for exchange with a mobile data communication device
JP3926792B2 (ja) * 2001-06-12 2007-06-06 リサーチ イン モーション リミテッド モバイルデータ通信デバイスと交換するためのセキュアなｅメールを圧縮するシステムおよび方法
CN100410927C (zh) 2001-06-12 2008-08-13 捷讯研究有限公司 证书管理和传送系统及方法
US8725549B2 (en) * 2001-08-13 2014-05-13 Geologics Corporation System and business method for work-flow review and management
EP1296275A3 (de) * 2001-08-15 2004-04-07 Mail Morph Limited System und Verfahren zur Analyse des e-mail-Verkehrs
EP1296252B1 (de) * 2001-09-21 2007-08-01 Koninklijke KPN N.V. Computersystem, Datenübertragungsnetz, Computerprogramm und Datenträger, alle zur Filterung von einen Inhalt gemäss einer Markierungssprache einschliessenden Nachrichten
US7930756B1 (en) 2001-12-12 2011-04-19 Crocker Steven Toye Multi-level cryptographic transformations for securing digital assets
US7921284B1 (en) 2001-12-12 2011-04-05 Gary Mark Kinghorn Method and system for protecting electronic data in enterprise environment
USRE41546E1 (en) 2001-12-12 2010-08-17 Klimenty Vainstein Method and system for managing security tiers
US8065713B1 (en) 2001-12-12 2011-11-22 Klimenty Vainstein System and method for providing multi-location access management to secured items
US7681034B1 (en) 2001-12-12 2010-03-16 Chang-Ping Lee Method and apparatus for securing electronic data
US8006280B1 (en) 2001-12-12 2011-08-23 Hildebrand Hal S Security system for generating keys from access rules in a decentralized manner and methods therefor
US10360545B2 (en) 2001-12-12 2019-07-23 Guardian Data Storage, Llc Method and apparatus for accessing secured electronic data off-line
US7921288B1 (en) 2001-12-12 2011-04-05 Hildebrand Hal S System and method for providing different levels of key security for controlling access to secured items
US7783765B2 (en) 2001-12-12 2010-08-24 Hildebrand Hal S System and method for providing distributed access control to secured documents
US10033700B2 (en) 2001-12-12 2018-07-24 Intellectual Ventures I Llc Dynamic evaluation of access rights
US7565683B1 (en) 2001-12-12 2009-07-21 Weiqing Huang Method and system for implementing changes to security policies in a distributed security system
US7178033B1 (en) 2001-12-12 2007-02-13 Pss Systems, Inc. Method and apparatus for securing digital assets
US7260555B2 (en) 2001-12-12 2007-08-21 Guardian Data Storage, Llc Method and architecture for providing pervasive security to digital assets
US7380120B1 (en) 2001-12-12 2008-05-27 Guardian Data Storage, Llc Secured data format for access control
US7950066B1 (en) 2001-12-21 2011-05-24 Guardian Data Storage, Llc Method and system for restricting use of a clipboard application
US7318238B2 (en) * 2002-01-14 2008-01-08 Microsoft Corporation Security settings for markup language elements
FI119454B (fi) * 2002-02-04 2008-11-14 Nokia Corp Menetelmä ja järjestelmä digitaalisen tallenteen käyttämiseksi päätelaitteessa ja päätelaite
US8176334B2 (en) 2002-09-30 2012-05-08 Guardian Data Storage, Llc Document security system that permits external users to gain access to secured files
FI20020367A0 (fi) * 2002-02-26 2002-02-26 Nokia Corp Jaetun verkkosolmun konfiguraation hallinta
US8566698B1 (en) * 2002-03-05 2013-10-22 Hyland Software, Inc. Document management system and method
US8095589B2 (en) * 2002-03-07 2012-01-10 Compete, Inc. Clickstream analysis methods and systems
US9092788B2 (en) * 2002-03-07 2015-07-28 Compete, Inc. System and method of collecting and analyzing clickstream data
US9129032B2 (en) * 2002-03-07 2015-09-08 Compete, Inc. System and method for processing a clickstream in a parallel processing architecture
US10296919B2 (en) 2002-03-07 2019-05-21 Comscore, Inc. System and method of a click event data collection platform
US20080189408A1 (en) 2002-10-09 2008-08-07 David Cancel Presenting web site analytics
US20070055937A1 (en) * 2005-08-10 2007-03-08 David Cancel Presentation of media segments
US7865720B2 (en) * 2002-03-20 2011-01-04 Research In Motion Limited System and method for supporting multiple certificate status providers on a mobile communication device
US8423763B2 (en) * 2002-03-20 2013-04-16 Research In Motion Limited System and method for supporting multiple certificate status providers on a mobile communication device
CA2479605C (en) * 2002-03-20 2009-03-10 Research In Motion Limited System and method for checking digital certificate status
CN100563242C (zh) * 2002-03-20 2009-11-25 捷讯研究有限公司 证书信息存储系统和方法
GB0206552D0 (en) * 2002-03-20 2002-05-01 Koninkl Philips Electronics Nv Computer systems and a related method for enabling a prospective buyer to browse a vendor's webside to purchase goods or services
US7234158B1 (en) 2002-04-01 2007-06-19 Microsoft Corporation Separate client state object and user interface domains
US8613102B2 (en) 2004-03-30 2013-12-17 Intellectual Ventures I Llc Method and system for providing document retention using cryptography
US7523490B2 (en) 2002-05-15 2009-04-21 Microsoft Corporation Session key security protocol
WO2003102798A1 (en) * 2002-05-30 2003-12-11 America Online Incorporated Intelligent client-side form filler
US7356711B1 (en) * 2002-05-30 2008-04-08 Microsoft Corporation Secure registration
US8271778B1 (en) * 2002-07-24 2012-09-18 The Nielsen Company (Us), Llc System and method for monitoring secure data on a network
US7107422B2 (en) 2002-08-23 2006-09-12 International Business Machines Corporation Method, computer program product, and system for global refresh of cached user security profiles
US7512810B1 (en) 2002-09-11 2009-03-31 Guardian Data Storage Llc Method and system for protecting encrypted files transmitted over a network
US7886359B2 (en) * 2002-09-18 2011-02-08 Symantec Corporation Method and apparatus to report policy violations in messages
US7472114B1 (en) * 2002-09-18 2008-12-30 Symantec Corporation Method and apparatus to define the scope of a search for information from a tabular data source
US8041719B2 (en) * 2003-05-06 2011-10-18 Symantec Corporation Personal computing device-based mechanism to detect preselected data
US8225371B2 (en) 2002-09-18 2012-07-17 Symantec Corporation Method and apparatus for creating an information security policy based on a pre-configured template
US7444522B1 (en) * 2002-09-18 2008-10-28 Open Invention Network, Llc Dynamic negotiation of security arrangements between web services
US8661498B2 (en) 2002-09-18 2014-02-25 Symantec Corporation Secure and scalable detection of preselected data embedded in electronically transmitted messages
US7673344B1 (en) * 2002-09-18 2010-03-02 Symantec Corporation Mechanism to search information content for preselected data
US7117528B1 (en) 2002-10-24 2006-10-03 Microsoft Corporation Contested account registration
US7836310B1 (en) 2002-11-01 2010-11-16 Yevgeniy Gutnik Security system that uses indirect password-based encryption
US7136856B2 (en) * 2002-12-04 2006-11-14 International Business Machines Corporation Multi-level security profile refresh
US7334013B1 (en) 2002-12-20 2008-02-19 Microsoft Corporation Shared services management
US7890990B1 (en) 2002-12-20 2011-02-15 Klimenty Vainstein Security system with staging capabilities
US6928526B1 (en) * 2002-12-20 2005-08-09 Datadomain, Inc. Efficient data storage system
FR2849233B1 (fr) * 2002-12-24 2005-05-20 Trusted Logic Procede de securisation des systemes informatiques par confinement logiciel
DE10300609A1 (de) * 2003-01-10 2004-07-29 Wincor Nixdorf International Gmbh Rückwirkungsfreie Geräteschnittstelle
US7685631B1 (en) 2003-02-05 2010-03-23 Microsoft Corporation Authentication of a server by a client to prevent fraudulent user interfaces
US8098809B2 (en) 2003-02-11 2012-01-17 Computer Associates Think, Inc. System and method for self-supporting applications
US7606915B1 (en) 2003-02-25 2009-10-20 Microsoft Corporation Prevention of unauthorized scripts
US7624277B1 (en) 2003-02-25 2009-11-24 Microsoft Corporation Content alteration for prevention of unauthorized scripts
JP4346326B2 (ja) * 2003-02-27 2009-10-21 富士通株式会社 セキュリティシステム、情報管理システム、暗号化支援システム、およびコンピュータプログラム
US7856477B2 (en) * 2003-04-04 2010-12-21 Yahoo! Inc. Method and system for image verification to prevent messaging abuse
US7360092B1 (en) 2003-04-28 2008-04-15 Microsoft Corporation Marking and identifying web-based authentication forms
US7814128B2 (en) 2003-05-30 2010-10-12 Symantec Operating Corporation Multi-volume file support
US8707034B1 (en) 2003-05-30 2014-04-22 Intellectual Ventures I Llc Method and system for using remote headers to secure electronic files
US20050078830A1 (en) * 2003-08-15 2005-04-14 Imcentric, Inc. Method for automated installation of digital certificates to network servers
US7890585B2 (en) * 2003-09-03 2011-02-15 Lowe John C Second person review of email
US8127366B2 (en) 2003-09-30 2012-02-28 Guardian Data Storage, Llc Method and apparatus for transitioning between states of security policies used to secure electronic documents
US7703140B2 (en) 2003-09-30 2010-04-20 Guardian Data Storage, Llc Method and system for securing digital assets using process-driven security policies
US20050080861A1 (en) * 2003-10-14 2005-04-14 Daniell W. Todd Selectively displaying email folders
US8600845B2 (en) * 2006-10-25 2013-12-03 American Express Travel Related Services Company, Inc. System and method for reconciling one or more financial transactions
US7895094B2 (en) * 2003-12-15 2011-02-22 American Express Travel Related Services Company, Inc. Global account reconciliation tool
US9191215B2 (en) * 2003-12-30 2015-11-17 Entrust, Inc. Method and apparatus for providing authentication using policy-controlled authentication articles and techniques
US7966487B2 (en) * 2004-01-09 2011-06-21 Corestreet, Ltd. Communication-efficient real time credentials for OCSP and distributed OCSP
US20050154878A1 (en) * 2004-01-09 2005-07-14 David Engberg Signature-efficient real time credentials for OCSP and distributed OCSP
US7490242B2 (en) * 2004-02-09 2009-02-10 International Business Machines Corporation Secure management of authentication information
US9589117B2 (en) * 2004-02-17 2017-03-07 Hewlett-Packard Development Company, L.P. Computer security system and method
US7293034B2 (en) 2004-02-23 2007-11-06 Microsoft Coporation Dynamically customizing a user interface for the aggregation of content
US20050193197A1 (en) * 2004-02-26 2005-09-01 Sarvar Patel Method of generating a cryptosync
US8583739B2 (en) * 2004-03-02 2013-11-12 International Business Machines Corporation Facilitating the sending of mail from a restricted communications network
US7636941B2 (en) 2004-03-10 2009-12-22 Microsoft Corporation Cross-domain authentication
US8140489B2 (en) * 2004-03-24 2012-03-20 Oracle International Corporation System and method for analyzing content on a web page using an embedded filter
US7437551B2 (en) * 2004-04-02 2008-10-14 Microsoft Corporation Public key infrastructure scalability certificate revocation status validation
ATE450950T1 (de) * 2004-04-30 2009-12-15 Research In Motion Ltd System und verfahren zur prüfung digitaler zertifikate
US7882348B2 (en) * 2004-04-30 2011-02-01 Research In Motion Limited System and method for administering digital certificate checking
US8769671B2 (en) * 2004-05-02 2014-07-01 Markmonitor Inc. Online fraud solution
US7870608B2 (en) * 2004-05-02 2011-01-11 Markmonitor, Inc. Early detection and monitoring of online fraud
US7913302B2 (en) * 2004-05-02 2011-03-22 Markmonitor, Inc. Advanced responses to online fraud
US20070107053A1 (en) * 2004-05-02 2007-05-10 Markmonitor, Inc. Enhanced responses to online fraud
US9203648B2 (en) * 2004-05-02 2015-12-01 Thomson Reuters Global Resources Online fraud solution
US8041769B2 (en) * 2004-05-02 2011-10-18 Markmonitor Inc. Generating phish messages
US7457823B2 (en) 2004-05-02 2008-11-25 Markmonitor Inc. Methods and systems for analyzing data related to possible online fraud
EP1605330A1 (de) * 2004-06-11 2005-12-14 ARM Limited Anzeige eines gesicherten Bedienungszustandes
WO2005125114A1 (en) 2004-06-21 2005-12-29 Research In Motion Limited System and method for handling electronic messages
US8484295B2 (en) * 2004-12-21 2013-07-09 Mcafee, Inc. Subscriber reputation filtering method for analyzing subscriber activity and detecting account misuse
US7953814B1 (en) 2005-02-28 2011-05-31 Mcafee, Inc. Stopping and remediating outbound messaging abuse
US7360110B1 (en) 2004-06-30 2008-04-15 Symantec Operating Corporation Parameterization of dimensions of protection systems and uses thereof
US7386752B1 (en) 2004-06-30 2008-06-10 Symantec Operating Corporation Using asset dependencies to identify the recovery set and optionally automate and/or optimize the recovery
US7836448B1 (en) * 2004-06-30 2010-11-16 Emc Corporation System and methods for task management
US8261122B1 (en) 2004-06-30 2012-09-04 Symantec Operating Corporation Estimation of recovery time, validation of recoverability, and decision support using recovery metrics, targets, and objectives
US7325161B1 (en) 2004-06-30 2008-01-29 Symantec Operating Corporation Classification of recovery targets to enable automated protection setup
US7360123B1 (en) 2004-06-30 2008-04-15 Symantec Operating Corporation Conveying causal relationships between at least three dimensions of recovery management
US7707427B1 (en) 2004-07-19 2010-04-27 Michael Frederick Kenrich Multi-level file digests
US20060036849A1 (en) * 2004-08-09 2006-02-16 Research In Motion Limited System and method for certificate searching and retrieval
US9094429B2 (en) 2004-08-10 2015-07-28 Blackberry Limited Server verification of secure electronic messages
US7549043B2 (en) * 2004-09-01 2009-06-16 Research In Motion Limited Providing certificate matching in a system and method for searching and retrieving certificates
US7631183B2 (en) * 2004-09-01 2009-12-08 Research In Motion Limited System and method for retrieving related certificates
US7640428B2 (en) * 2004-09-02 2009-12-29 Research In Motion Limited System and method for searching and retrieving certificates
GB0419889D0 (en) * 2004-09-08 2004-10-13 Ibm Accessing a data item in a memory of a computer system
US7644266B2 (en) * 2004-09-23 2010-01-05 International Business Machines Corporation Apparatus, system, and method for message level security
US7607006B2 (en) * 2004-09-23 2009-10-20 International Business Machines Corporation Method for asymmetric security
JP2006094241A (ja) * 2004-09-24 2006-04-06 Fuji Xerox Co Ltd 暗号化装置、暗号化処理方法及びプログラム、並びに該暗号化装置を用いた情報保護システム
US20060070126A1 (en) * 2004-09-26 2006-03-30 Amiram Grynberg A system and methods for blocking submission of online forms.
NL1027274C2 (nl) 2004-10-18 2006-04-19 Ebuzon B V Werkwijze en systeem voor het via een netwerk verzenden van elektronische post.
US7716139B2 (en) * 2004-10-29 2010-05-11 Research In Motion Limited System and method for verifying digital signatures on certificates
US7886144B2 (en) 2004-10-29 2011-02-08 Research In Motion Limited System and method for retrieving certificates associated with senders of digitally signed messages
US9160755B2 (en) * 2004-12-21 2015-10-13 Mcafee, Inc. Trusted communication network
US20140068409A1 (en) * 2004-12-21 2014-03-06 Signaturelink, Inc. Systems and Methods for Capturing Real Time Client Side Data and For Generating a Permanent Record
US9015472B1 (en) 2005-03-10 2015-04-21 Mcafee, Inc. Marking electronic messages to indicate human origination
US8738708B2 (en) * 2004-12-21 2014-05-27 Mcafee, Inc. Bounce management in a trusted communication network
JP4695388B2 (ja) * 2004-12-27 2011-06-08 株式会社リコー セキュリティ情報推定装置、セキュリティ情報推定方法、セキュリティ情報推定プログラム及び記録媒体
US7620974B2 (en) * 2005-01-12 2009-11-17 Symantec Distributed traffic scanning through data stream security tagging
US7617532B1 (en) * 2005-01-24 2009-11-10 Symantec Corporation Protection of sensitive data from malicious e-mail
US20090171847A2 (en) * 2005-01-24 2009-07-02 Microsoft Corporation Multi-merchant purchasing environment for downloadable products
US7548889B2 (en) * 2005-01-24 2009-06-16 Microsoft Corporation Payment information security for multi-merchant purchasing environment for downloadable products
US20060167811A1 (en) * 2005-01-24 2006-07-27 Microsoft Corporation Product locker for multi-merchant purchasing environment for downloadable products
US8011003B2 (en) 2005-02-14 2011-08-30 Symantec Corporation Method and apparatus for handling messages containing pre-selected data
US20060184549A1 (en) * 2005-02-14 2006-08-17 Rowney Kevin T Method and apparatus for modifying messages based on the presence of pre-selected data
US20060212696A1 (en) * 2005-03-17 2006-09-21 Bustelo Leugim A Method and system for selective information delivery in a rich client form
HU0500314D0 (en) * 2005-03-18 2005-05-30 Fon Telekommunikacios Kft B V Method and device for achieving and checking telephone calls, in particular to penitentiaries, prisons
US7743254B2 (en) * 2005-03-23 2010-06-22 Microsoft Corporation Visualization of trust in an address bar
JP4158927B2 (ja) * 2005-03-25 2008-10-01 インターナショナル・ビジネス・マシーンズ・コーポレーション 情報提示装置、情報提示方法、プログラム
US7353034B2 (en) 2005-04-04 2008-04-01 X One, Inc. Location sharing and tracking using mobile phones or other wireless devices
JP2006303963A (ja) * 2005-04-21 2006-11-02 Internatl Business Mach Corp <Ibm> 情報を管理するシステム、方法およびプログラム
WO2006116427A2 (en) * 2005-04-26 2006-11-02 Boloto Group, Inc. Creating or maintaining relationships within a private network or virtual private network of servers and clients
US9384345B2 (en) 2005-05-03 2016-07-05 Mcafee, Inc. Providing alternative web content based on website reputation assessment
US7562304B2 (en) * 2005-05-03 2009-07-14 Mcafee, Inc. Indicating website reputations during website manipulation of user information
US8566726B2 (en) * 2005-05-03 2013-10-22 Mcafee, Inc. Indicating website reputations based on website handling of personal information
US8438499B2 (en) 2005-05-03 2013-05-07 Mcafee, Inc. Indicating website reputations during user interactions
US8078740B2 (en) 2005-06-03 2011-12-13 Microsoft Corporation Running internet applications with low rights
US10021062B2 (en) * 2005-07-01 2018-07-10 Cirius Messaging Inc. Secure electronic mail system
WO2007005868A2 (en) * 2005-07-01 2007-01-11 Markmonitor, Inc. Enhanced fraud monitoring systems
US7783711B2 (en) * 2005-07-01 2010-08-24 0733660 B.C. Ltd. Electronic mail system with functionally for senders to control actions performed by message recipients
JP4595728B2 (ja) * 2005-07-26 2010-12-08 富士ゼロックス株式会社 電子メール送信装置、プログラム、インターネットファックス送信装置、スキャン画像開示装置及び送信装置
US7756932B2 (en) * 2005-07-29 2010-07-13 Research In Motion Limited System and method for processing messages being composed by a user
WO2007016787A2 (en) 2005-08-09 2007-02-15 Nexsan Technologies Canada Inc. Data archiving system
US9105028B2 (en) 2005-08-10 2015-08-11 Compete, Inc. Monitoring clickstream behavior of viewers of online advertisements and search results
US20070047726A1 (en) * 2005-08-25 2007-03-01 Cisco Technology, Inc. System and method for providing contextual information to a called party
US8340289B2 (en) * 2005-09-29 2012-12-25 Research In Motion Limited System and method for providing an indication of randomness quality of random number data generated by a random data service
US7797545B2 (en) * 2005-09-29 2010-09-14 Research In Motion Limited System and method for registering entities for code signing services
US20070083918A1 (en) * 2005-10-11 2007-04-12 Cisco Technology, Inc. Validation of call-out services transmitted over a public switched telephone network
KR100902627B1 (ko) * 2005-10-14 2009-06-15 리서치 인 모션 리미티드 마스터 암호화 키들을 보호하는 시스템 및 방법
US7953971B2 (en) * 2005-10-27 2011-05-31 Research In Motion Limited Synchronizing certificates between a device and server
US7730187B2 (en) * 2006-10-05 2010-06-01 Limelight Networks, Inc. Remote domain name service
US7987511B2 (en) 2005-11-23 2011-07-26 Research In Motion Limited E-mail with secure message parts
ATE396576T1 (de) * 2005-11-23 2008-06-15 Research In Motion Ltd E-mail mit sicheren nachrichtenteilen
US8243895B2 (en) * 2005-12-13 2012-08-14 Cisco Technology, Inc. Communication system with configurable shared line privacy feature
US8005459B2 (en) 2005-12-16 2011-08-23 Research In Motion Limited System and method of authenticating login credentials in a wireless communication system
US9407662B2 (en) 2005-12-29 2016-08-02 Nextlabs, Inc. Analyzing activity data of an information management system
WO2007095157A2 (en) 2006-02-10 2007-08-23 Fair Isaac Corporation Consumer-driven secure sockets layer modulator
US8503621B2 (en) * 2006-03-02 2013-08-06 Cisco Technology, Inc. Secure voice communication channel for confidential messaging
US8468595B1 (en) * 2006-03-22 2013-06-18 Trend Micro Incorporated Content filtering prior to data encryption
US7912908B2 (en) * 2006-03-27 2011-03-22 Alcatel-Lucent Usa Inc. Electronic message forwarding control
US8701196B2 (en) 2006-03-31 2014-04-15 Mcafee, Inc. System, method and computer program product for obtaining a reputation associated with a file
ES2308624T3 (es) * 2006-04-04 2008-12-01 MULLER MARKEN GMBH &amp; CO. BETRIEBS-KG Verificacion automatica de datos de contacto de messenger.
US20070274300A1 (en) * 2006-05-04 2007-11-29 Microsoft Corporation Hover to call
US20100017305A1 (en) * 2006-05-31 2010-01-21 Lawrence Edward Strodtman Systems and methods for wine tasting and the marketing of wine, and wine packaging useful therewith
US20070282696A1 (en) * 2006-05-31 2007-12-06 Lawrence Edward Strodtman Systems and methods for wine tasting and the marketing of wine, and wine packaging useful therewith
JP4290179B2 (ja) * 2006-06-15 2009-07-01 キヤノン株式会社 署名検証装置、及び、その制御方法、プログラム、記憶媒体
US8346265B2 (en) * 2006-06-20 2013-01-01 Alcatel Lucent Secure communication network user mobility apparatus and methods
US7814161B2 (en) 2006-06-23 2010-10-12 Research In Motion Limited System and method for handling electronic mail mismatches
US8185737B2 (en) 2006-06-23 2012-05-22 Microsoft Corporation Communication across domains
ATE414958T1 (de) 2006-07-11 2008-12-15 Research In Motion Ltd System und verfahren zur dynamischen modifizierung zulässiger eigenschaften einer elektronischen nachricht
US8396211B2 (en) 2006-07-11 2013-03-12 Research In Motion Limited System and method for dynamic modification of allowable electronic message properties
JP4337853B2 (ja) * 2006-09-04 2009-09-30 コニカミノルタビジネステクノロジーズ株式会社 アプリケーションプログラム配布装置、画像処理装置、及びプログラム
EP1921560A1 (de) * 2006-11-10 2008-05-14 Nokia Siemens Networks Gmbh & Co. Kg Verfahren und System zur Bereitstellung von sensitiven Daten
US8687785B2 (en) 2006-11-16 2014-04-01 Cisco Technology, Inc. Authorization to place calls by remote users
US20080133673A1 (en) * 2006-12-04 2008-06-05 Abdelhadi Sanaa F Method and apparatus to control contents in a document
US8423615B1 (en) * 2006-12-06 2013-04-16 Google Inc. System and method for restricting distribution of electronic messages
US7822851B2 (en) * 2007-01-18 2010-10-26 Internet Probation and Parole Control, Inc. Remote user computer control and monitoring
US7870596B2 (en) * 2007-02-01 2011-01-11 Microsoft Corporation Accessing network resources outside a security boundary
US20080189767A1 (en) * 2007-02-01 2008-08-07 Microsoft Corporation Accessing file resources outside a security boundary
US8255696B2 (en) * 2007-05-01 2012-08-28 Microsoft Corporation One-time password access to password-protected accounts
EP1990750A1 (de) * 2007-05-09 2008-11-12 Nokia Siemens Networks Oy Verfahren und Vorrichtung zur Datenverarbeitung und Kommunikationssystem mit einer derartigen Vorrichtung
US7823761B2 (en) * 2007-05-16 2010-11-02 The Invention Science Fund I, Llc Maneuverable surgical stapler
US7770789B2 (en) * 2007-05-17 2010-08-10 Shift4 Corporation Secure payment card transactions
ES2748847T3 (es) * 2007-05-17 2020-03-18 Shift4 Corp Transacciones de tarjeta de pago seguras
US7841523B2 (en) * 2007-05-17 2010-11-30 Shift4 Corporation Secure payment card transactions
US7891563B2 (en) * 2007-05-17 2011-02-22 Shift4 Corporation Secure payment card transactions
US8793801B2 (en) * 2007-05-18 2014-07-29 Goldman, Sachs & Co. Systems and methods to secure restricted information in electronic mail messages
US10019570B2 (en) * 2007-06-14 2018-07-10 Microsoft Technology Licensing, Llc Protection and communication abstractions for web browsers
US9305042B1 (en) * 2007-06-14 2016-04-05 West Corporation System, method, and computer-readable medium for removing credit card numbers from both fixed and variable length transaction records
US8068588B2 (en) * 2007-06-26 2011-11-29 Microsoft Corporation Unified rules for voice and messaging
US8135383B2 (en) * 2007-07-30 2012-03-13 Lsi Corporation Information security and delivery method and apparatus
RU2010110551A (ru) * 2007-08-22 2011-09-27 Рафи РЕФАЭЛИ (IL) Процесс защищенного приобретения через терминал для работы с кредитными картами
US7783666B1 (en) 2007-09-26 2010-08-24 Netapp, Inc. Controlling access to storage resources by using access pattern based quotas
US9087427B2 (en) 2007-09-27 2015-07-21 Wayne Fueling Systems Llc Conducting fuel dispensing transactions
US7975308B1 (en) * 2007-09-28 2011-07-05 Symantec Corporation Method and apparatus to secure user confidential data from untrusted browser extensions
US8656489B1 (en) * 2007-09-29 2014-02-18 Symantec Corporation Method and apparatus for accelerating load-point scanning
US8359355B2 (en) * 2007-10-16 2013-01-22 International Business Machines Corporation System and method for verifying access to content
EP2204757B1 (de) * 2007-10-25 2014-06-25 Fujitsu Limited Verfahren und einrichtung für die kontrolle der informationsübertragungen zwischen einer informationsverarbeitungseinrichtung und einer informationsspeicherungseinrichtung sowie zwischen der informationsverarbeitungseinrichtung und einem netzwerk
US8539029B2 (en) 2007-10-29 2013-09-17 Microsoft Corporation Pre-send evaluation of E-mail communications
US9547870B1 (en) * 2007-11-02 2017-01-17 Fair Isaac Corporation System and methods for selective advertising
JP4935658B2 (ja) * 2007-12-11 2012-05-23 ブラザー工業株式会社 ブラウザプログラムおよび情報処理装置
JP4593615B2 (ja) * 2007-12-28 2010-12-08 キヤノンＩｔソリューションズ株式会社 情報処理システム、情報処理方法及びプログラム
US20090182647A1 (en) * 2008-01-15 2009-07-16 Ebay Inc. Systems and methods for enhancing product value metadata
US8250378B1 (en) 2008-02-04 2012-08-21 Crossroads Systems, Inc. System and method for enabling encryption
US20090204812A1 (en) * 2008-02-13 2009-08-13 Baker Todd M Media processing
US20090234851A1 (en) * 2008-03-14 2009-09-17 International Business Machines Corporation Browser Use of Directory Listing for Predictive Type-Ahead
US7996373B1 (en) 2008-03-28 2011-08-09 Symantec Corporation Method and apparatus for detecting policy violations in a data repository having an arbitrary data schema
US7996374B1 (en) 2008-03-28 2011-08-09 Symantec Corporation Method and apparatus for automatically correlating related incidents of policy violations
US8065739B1 (en) 2008-03-28 2011-11-22 Symantec Corporation Detecting policy violations in information content containing data in a character-based language
US8990313B2 (en) 2008-04-01 2015-03-24 Microsoft Technology Licensing, Llc Download of current portions of email messages
US8280963B2 (en) * 2008-04-10 2012-10-02 Microsoft Corporation Caching and exposing pre-send data relating to the sender or recipient of an electronic mail message
US8601258B2 (en) * 2008-05-05 2013-12-03 Kip Cr P1 Lp Method for configuring centralized encryption policies for devices
US8677129B2 (en) * 2008-05-13 2014-03-18 Fair Isaac Corporation Consumer-driven secure sockets layer modulator
US8095604B2 (en) * 2008-06-06 2012-01-10 International Business Machines Corporation Automatically modifying distributed communications
US8316100B2 (en) * 2008-06-06 2012-11-20 International Business Machines Corporation Autonomic correction of incorrect identities in repositories
US8756284B2 (en) 2008-06-06 2014-06-17 International Business Machines Corporation Minimizing incorrectly addressed communications when working with ambiguous recipient designations
US8171088B2 (en) * 2008-06-06 2012-05-01 International Business Machines Corporation Facilitating correction of incorrect identities in propagated electronic communications
US20090313101A1 (en) * 2008-06-13 2009-12-17 Microsoft Corporation Processing receipt received in set of communications
US8788350B2 (en) * 2008-06-13 2014-07-22 Microsoft Corporation Handling payment receipts with a receipt store
US7523309B1 (en) * 2008-06-27 2009-04-21 International Business Machines Corporation Method of restricting access to emails by requiring multiple levels of user authentication
MX2011000733A (es) * 2008-07-18 2011-06-28 Absolute Software Corp Manejo de privacidad para dispositivos de rastreo.
WO2010011180A1 (en) 2008-07-25 2010-01-28 Resolvo Systems Pte Ltd Method and system for securing against leakage of source code
US10354229B2 (en) 2008-08-04 2019-07-16 Mcafee, Llc Method and system for centralized contact management
US8843566B2 (en) * 2008-08-20 2014-09-23 First Data Corporation Securing outbound mail
US8826443B1 (en) 2008-09-18 2014-09-02 Symantec Corporation Selective removal of protected content from web requests sent to an interactive website
US10637832B2 (en) * 2008-09-30 2020-04-28 EMC IP Holding Company LLC Method and apparatus providing a framework for secure information lifecycle
US9569528B2 (en) * 2008-10-03 2017-02-14 Ab Initio Technology Llc Detection of confidential information
US8463897B2 (en) * 2008-10-09 2013-06-11 At&T Intellectual Property I, L.P. Systems and methods to emulate user network activity
US8296563B2 (en) * 2008-10-22 2012-10-23 Research In Motion Limited Method of handling a certification request
US8644511B2 (en) * 2008-11-05 2014-02-04 Comcast Cable Communications, LLC. System and method for providing digital content
US8613040B2 (en) * 2008-12-22 2013-12-17 Symantec Corporation Adaptive data loss prevention policies
US9444823B2 (en) * 2008-12-24 2016-09-13 Qualcomm Incorporated Method and apparatus for providing network communication association information to applications and services
US8589502B2 (en) * 2008-12-31 2013-11-19 International Business Machines Corporation System and method for allowing access to content
US8386573B2 (en) * 2008-12-31 2013-02-26 International Business Machines Corporation System and method for caching linked email data for offline use
US8935752B1 (en) 2009-03-23 2015-01-13 Symantec Corporation System and method for identity consolidation
US8584251B2 (en) * 2009-04-07 2013-11-12 Princeton Payment Solutions Token-based payment processing system
US8763142B2 (en) 2009-04-07 2014-06-24 Princeton Payment Solutions Tokenized payment processing schemes
US9342697B1 (en) * 2009-04-09 2016-05-17 Trend Micro Incorporated Scalable security policy architecture for data leakage prevention
US9397981B2 (en) * 2009-04-20 2016-07-19 International Business Machines Corporation Method and system for secure document exchange
DE102009038035A1 (de) * 2009-08-19 2011-02-24 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Konfiguration von Infotainmentanwendungen in einem Kraftfahrzeug
CN102014145A (zh) * 2009-09-04 2011-04-13 鸿富锦精密工业（深圳）有限公司 文件传输安全管控系统及方法
US9268954B2 (en) * 2009-10-07 2016-02-23 Ca, Inc. System and method for role discovery
US8578504B2 (en) * 2009-10-07 2013-11-05 Ca, Inc. System and method for data leakage prevention
US9077543B2 (en) * 2009-10-09 2015-07-07 Apple Inc. Methods and apparatus for digital attestation
JP5521479B2 (ja) * 2009-10-14 2014-06-11 富士通株式会社 プログラム、データ記憶装置及びデータ記憶システム
US8666812B1 (en) * 2009-11-10 2014-03-04 Google Inc. Distributing content based on transaction information
WO2011101784A1 (en) * 2010-02-16 2011-08-25 Tigertext Inc. A messaging system apparatuses circuits and methods of operation thereof
US20110219424A1 (en) * 2010-03-05 2011-09-08 Microsoft Corporation Information protection using zones
US9838349B2 (en) * 2010-03-08 2017-12-05 Microsoft Technology Licensing, Llc Zone classification of electronic mail messages
US9406048B2 (en) * 2010-07-07 2016-08-02 Mark Meister Email system for preventing inadvertant transmission of propriety message or documents to unintended recipient
US20120059663A1 (en) * 2010-09-03 2012-03-08 Kate Levesque Methods and apparatus for patient visit workflow
US20120079043A1 (en) * 2010-09-27 2012-03-29 Research In Motion Limited Method, apparatus and system for accessing an application across a plurality of computers
US10164922B2 (en) 2010-09-27 2018-12-25 International Business Machines Corporation Secure electronic message conveyance
US8656453B2 (en) * 2010-11-10 2014-02-18 Software Ag Security systems and/or methods for cloud computing environments
US10534931B2 (en) 2011-03-17 2020-01-14 Attachmate Corporation Systems, devices and methods for automatic detection and masking of private data
US8631460B2 (en) 2011-03-23 2014-01-14 CipherPoint Software, Inc. Systems and methods for implementing transparent encryption
US8627404B2 (en) * 2011-08-24 2014-01-07 Raytheon Company Detecting addition of a file to a computer system and initiating remote analysis of the file for malware
US8930492B2 (en) 2011-10-17 2015-01-06 Blackberry Limited Method and electronic device for content sharing
US8990266B2 (en) 2011-10-18 2015-03-24 CipherPoint Software, Inc. Dynamic data transformations for network transmissions
US8959425B2 (en) 2011-12-09 2015-02-17 Microsoft Corporation Inference-based extension activation
KR101236544B1 (ko) * 2012-01-12 2013-03-15 주식회사 엘지씨엔에스 결제 방법 및 이와 연관된 결제 게이트웨이 서버, 모바일 단말 및 시점 확인서 발행 서버
US9679163B2 (en) 2012-01-17 2017-06-13 Microsoft Technology Licensing, Llc Installation and management of client extensions
US8954580B2 (en) 2012-01-27 2015-02-10 Compete, Inc. Hybrid internet traffic measurement using site-centric and panel data
US9900395B2 (en) 2012-01-27 2018-02-20 Comscore, Inc. Dynamic normalization of internet traffic
US9256445B2 (en) 2012-01-30 2016-02-09 Microsoft Technology Licensing, Llc Dynamic extension view with multiple levels of expansion
US9449112B2 (en) 2012-01-30 2016-09-20 Microsoft Technology Licensing, Llc Extension activation for related documents
US8843822B2 (en) 2012-01-30 2014-09-23 Microsoft Corporation Intelligent prioritization of activated extensions
WO2013167169A1 (en) * 2012-05-08 2013-11-14 Nokia Siemens Networks Oy Method and apparatus
US8837739B1 (en) * 2012-05-13 2014-09-16 Identillect Technologies, Inc. Encryption messaging system
US10068083B2 (en) * 2012-09-28 2018-09-04 International Business Machines Corporation Secure transport of web form submissions
US9767269B2 (en) * 2012-10-15 2017-09-19 Nec Corporation Security-function-design support device, security-function-design support method, and program
WO2014135179A1 (en) * 2013-03-04 2014-09-12 Selinko S.A. Method for providing e-commerce secure transactions
US9009815B2 (en) 2013-03-15 2015-04-14 International Business Machines Corporation Increasing chosen password strength
US10902081B1 (en) 2013-05-06 2021-01-26 Veeva Systems Inc. System and method for controlling electronic communications
CN105493121B (zh) * 2013-05-06 2019-04-16 维我系统公司 用于控制电子通信的系统和方法
US10140382B2 (en) 2013-05-06 2018-11-27 Veeva Systems Inc. System and method for controlling electronic communications
US9369488B2 (en) * 2013-05-28 2016-06-14 Globalfoundries Inc. Policy enforcement using natural language processing
US9210139B2 (en) * 2013-06-05 2015-12-08 The Boeing Company Secure relay system
CN104252479B (zh) 2013-06-27 2018-05-18 华为技术有限公司 信息的处理方法、装置和系统
US10437903B2 (en) * 2013-09-20 2019-10-08 Jesse Lakes Redirection service profiling
CN105531679B (zh) * 2013-10-10 2018-05-15 英特尔公司 在网络客户端上进行的异常检测
RU2691843C2 (ru) * 2013-10-11 2019-06-18 Виза Интернэшнл Сервис Ассосиэйшн Система сетевых токенов
DE102013020742A1 (de) * 2013-12-10 2015-06-11 Tobias Rückert Verfahren und System zur Übermittlung einer elektronischen Nachricht
US20150170084A1 (en) * 2013-12-12 2015-06-18 International Business Machines Corporation Augmenting business process execution using natural language processing
US9338137B1 (en) * 2015-02-13 2016-05-10 AO Kaspersky Lab System and methods for protecting confidential data in wireless networks
US9948633B2 (en) * 2015-10-28 2018-04-17 Citrix Systems, Inc. Systems and methods for policy driven fine grain validation of servers' SSL certificate for clientless SSLVPN access
CN105871584A (zh) * 2015-12-02 2016-08-17 乐视体育文化产业发展（北京）有限公司 一种键值对数据库中的客户端配置更新方法、设备及系统
CN105867837A (zh) * 2015-12-02 2016-08-17 乐视体育文化产业发展（北京）有限公司 一种分布式高速缓存系统中的客户端配置更新方法、设备及系统
US9559997B1 (en) * 2016-01-11 2017-01-31 Paul Everton Client agnostic email processing
US10841262B2 (en) * 2016-01-11 2020-11-17 Etorch, Inc. Client-agnostic and network-agnostic device management
US11323399B2 (en) * 2016-01-11 2022-05-03 Mimecast North America, Inc. Client-agnostic and network-agnostic device management
US10979393B2 (en) * 2016-01-11 2021-04-13 Mimecast North America, Inc. Identity-based messaging security
US9824332B1 (en) 2017-04-12 2017-11-21 eTorch Inc. Email data collection compliance enforcement
JP6677887B2 (ja) * 2016-03-28 2020-04-08 富士通クライアントコンピューティング株式会社 メール配信プログラム、メールサーバ及びメール配信方法
US10091235B1 (en) * 2016-06-07 2018-10-02 Juniper Networks, Inc. Method, system, and apparatus for detecting and preventing targeted attacks
US20180012190A1 (en) * 2016-07-06 2018-01-11 International Business Machines Corporation Automatic inference of meeting attendance
GB2569742A (en) * 2016-10-28 2019-06-26 Flexiwage Ltd An employee determined payroll payment processing method and system
CN106779369B (zh) * 2016-12-03 2020-09-25 安徽中医药大学第一附属医院 一种医院轮转排班方法
US10389743B1 (en) 2016-12-22 2019-08-20 Symantec Corporation Tracking of software executables that come from untrusted locations
US11393046B1 (en) * 2017-01-17 2022-07-19 Intuit Inc. System and method for perpetual rekeying of various data columns with a frequency and encryption strength based on the sensitivity of the data columns
US10303895B1 (en) 2017-01-19 2019-05-28 Intuit Inc. System and method for perpetual rekeying of various data columns with respective encryption keys and on alternating bases
US10127513B1 (en) * 2017-04-28 2018-11-13 Cyara Solutions Pty Ltd Automated multi-channel customer journey testing
WO2019005098A1 (en) * 2017-06-30 2019-01-03 Go Logic Decision Time, Llc METHODS AND SYSTEMS FOR PROJECTIVE ASSERTION SIMULATION
CN109118360B (zh) * 2018-07-19 2021-05-18 中国联合网络通信集团有限公司 区块链对账方法、装置、设备及存储介质
US11190573B2 (en) * 2018-07-25 2021-11-30 Vmware, Inc. Techniques for improving implementation of a remote browser within a local browser
CN109710671B (zh) * 2018-12-14 2023-05-30 国云科技股份有限公司 实现数据库操作数据引流的方法及其数据库防火墙系统
US11399020B2 (en) * 2019-06-28 2022-07-26 HCL Technologies Italy S.p.A System and method for authenticating server identity during connection establishment with client machine
US11100497B2 (en) * 2019-08-20 2021-08-24 Anchor Labs, Inc. Risk mitigation for a cryptoasset custodial system using a hardware security key
WO2021059852A1 (ja) * 2019-09-24 2021-04-01 日本電気株式会社 情報変換装置、情報変換システム、情報変換方法および記録媒体
US11070533B2 (en) * 2019-10-10 2021-07-20 Forcepoint Llc Encrypted server name indication inspection
CN110727670B (zh) * 2019-10-11 2022-08-09 北京小向创新人工智能科技有限公司 基于流程图的数据结构预测传递及自动化数据处理方法
CN113595864B (zh) * 2020-04-30 2023-04-18 北京字节跳动网络技术有限公司 一种转发邮件的方法、装置、电子设备及存储介质
US20230205906A1 (en) * 2021-12-28 2023-06-29 Capital One Services, Llc Identification of sensitive content in electronic mail messages to prevent exfiltration

Family Cites Families (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2041992A1 (en) 1990-05-18 1991-11-19 Yeshayahu Artsy Routing objects on action paths in a distributed computing system
JP2865827B2 (ja) 1990-08-13 1999-03-08 株式会社日立製作所 会議システムにおけるデータ蓄積方法
US5235489A (en) * 1991-06-28 1993-08-10 Sgs-Thomson Microelectronics, Inc. Integrated solution to high voltage load dump conditions
US5325642A (en) * 1992-01-17 1994-07-05 Cooley Warren L Geodesic hazardous waste containment building
CZ293613B6 (cs) * 1992-01-17 2004-06-16 Westinghouse Electric Corporation Způsob monitorování chodu zařízení pomocí CPU
US5235642A (en) * 1992-07-21 1993-08-10 Digital Equipment Corporation Access control subsystem and method for distributed computer system using locally cached authentication credentials
US5452099A (en) * 1993-04-12 1995-09-19 Faxguard Systems Corporation Method and system for storage and/or transmission of confidential facsimile documents
JPH07154615A (ja) 1993-11-26 1995-06-16 Mita Ind Co Ltd ファクシミリ装置の暗号化装置
US5835726A (en) * 1993-12-15 1998-11-10 Check Point Software Technologies Ltd. System for securing the flow of and selectively modifying packets in a computer network
GB2295299B (en) 1994-11-16 1999-04-28 Network Services Inc Enterpris Enterprise network management method and apparatus
US6035399A (en) 1995-04-07 2000-03-07 Hewlett-Packard Company Checkpoint object
JP3426428B2 (ja) * 1995-10-27 2003-07-14 富士通株式会社 トランザクションのトレース装置
US6006333A (en) * 1996-03-13 1999-12-21 Sun Microsystems, Inc. Password helper using a client-side master password which automatically presents the appropriate server-side password to a particular remote server
US5964839A (en) 1996-03-29 1999-10-12 At&T Corp System and method for monitoring information flow and performing data collection
US5884033A (en) * 1996-05-15 1999-03-16 Spyglass, Inc. Internet filtering system for filtering data transferred over the internet utilizing immediate and deferred filtering actions
US5907680A (en) 1996-06-24 1999-05-25 Sun Microsystems, Inc. Client-side, server-side and collaborative spell check of URL's
US5787177A (en) 1996-08-01 1998-07-28 Harris Corporation Integrated network security access control system
KR19980022833A (ko) 1996-09-24 1998-07-06 최승렬 정보 유출을 추적하기 위한 장치 및 방법
US5835725A (en) * 1996-10-21 1998-11-10 Cisco Technology, Inc. Dynamic address assignment and resolution technique
US5903882A (en) 1996-12-13 1999-05-11 Certco, Llc Reliance server for electronic transaction system
US5987611A (en) * 1996-12-31 1999-11-16 Zone Labs, Inc. System and methodology for managing internet access on a per application basis for client computers connected to the internet
US6009173A (en) * 1997-01-31 1999-12-28 Motorola, Inc. Encryption and decryption method and apparatus
US5917489A (en) * 1997-01-31 1999-06-29 Microsoft Corporation System and method for creating, editing, and distributing rules for processing electronic messages
US5935249A (en) * 1997-02-26 1999-08-10 Sun Microsystems, Inc. Mechanism for embedding network based control systems in a local network interface device
US6085224A (en) * 1997-03-11 2000-07-04 Intracept, Inc. Method and system for responding to hidden data and programs in a datastream
US5944787A (en) * 1997-04-21 1999-08-31 Sift, Inc. Method for automatically finding postal addresses from e-mail addresses
US6073142A (en) 1997-06-23 2000-06-06 Park City Group Automated post office based rule analysis of e-mail messages and other data objects for controlled distribution in network environments
US6359557B2 (en) 1998-01-26 2002-03-19 At&T Corp Monitoring and notification method and apparatus
US6012067A (en) * 1998-03-02 2000-01-04 Sarkar; Shyam Sundar Method and apparatus for storing and manipulating objects in a plurality of relational data managers on the web
US6141686A (en) * 1998-03-13 2000-10-31 Deterministic Networks, Inc. Client-side application-classifier gathering network-traffic statistics and application and user names using extensible-service provider plugin for policy-based network control
US6073242A (en) * 1998-03-19 2000-06-06 Agorics, Inc. Electronic authority server
US6182097B1 (en) 1998-05-21 2001-01-30 Lucent Technologies Inc. Method for characterizing and visualizing patterns of usage of a web site by network users
US6185614B1 (en) 1998-05-26 2001-02-06 International Business Machines Corp. Method and system for collecting user profile information over the world-wide web in the presence of dynamic content using document comparators
US6728757B1 (en) * 1998-06-04 2004-04-27 America Online, Incorporated Smart HTML electronic mail
US6735701B1 (en) 1998-06-25 2004-05-11 Macarthur Investments, Llc Network policy management and effectiveness system
CN1342278A (zh) * 1998-08-04 2002-03-27 机密保护公司 用于形成封装对象产品的设备和方法以及由此形成的封装对象产品
US6154747A (en) * 1998-08-26 2000-11-28 Hunt; Rolf G. Hash table implementation of an object repository
GB9828341D0 (en) 1998-12-22 1999-02-17 Content Technologies Limited Method and system for analyzing the content of encrypted electronic data
US6654787B1 (en) * 1998-12-31 2003-11-25 Brightmail, Incorporated Method and apparatus for filtering e-mail
JP3220104B2 (ja) 1999-02-16 2001-10-22 ケイディーディーアイ株式会社 Ｕｒｌ階層構造を利用した情報自動フィルタリング方法および装置
JP2000278260A (ja) 1999-03-24 2000-10-06 Hitachi Information Systems Ltd 暗号通信方法およびそのプログラムを記録した記録媒体
WO2000068811A1 (en) 1999-04-30 2000-11-16 Network Forensics, Inc. System and method for capturing network data and identifying network events therefrom
US6467052B1 (en) * 1999-06-03 2002-10-15 Microsoft Corporation Method and apparatus for analyzing performance of data processing system
US6819682B1 (en) * 1999-09-03 2004-11-16 Broadcom Corporation System and method for the synchronization and distribution of telephony timing information in a cable modem network
AU7998000A (en) 1999-10-08 2001-04-23 Freeworks Com., Inc. Method and apparatus for mapping a community through user interactions on a computer network
WO2001039023A2 (en) 1999-11-22 2001-05-31 Avenue A, Inc. Method and facility for capturing behavioral and profile data during a customer visit to a web site
US6754829B1 (en) * 1999-12-14 2004-06-22 Intel Corporation Certificate-based authentication system for heterogeneous environments
US6460074B1 (en) * 2000-02-10 2002-10-01 Martin E. Fishkin Electronic mail system
US7426750B2 (en) * 2000-02-18 2008-09-16 Verimatrix, Inc. Network-based content distribution system
US7017187B1 (en) * 2000-06-20 2006-03-21 Citigroup Global Markets, Inc. Method and system for file blocking in an electronic messaging system
US7587499B1 (en) * 2000-09-14 2009-09-08 Joshua Haghpassand Web-based security and filtering system with proxy chaining
US8972590B2 (en) * 2000-09-14 2015-03-03 Kirsten Aldrich Highly accurate security and filtering software
US20020087645A1 (en) * 2000-09-28 2002-07-04 Kent Ertugrul Automated initiation and propagation by means of electronic mail of devices to provide voice-over-IP and other advanced communications capabilities to recipients of such electronic mail
US6650890B1 (en) * 2000-09-29 2003-11-18 Postini, Inc. Value-added electronic messaging services and transparent implementation thereof using intermediate server
US6895426B1 (en) * 2000-10-17 2005-05-17 Microsoft Corporation Addresses as objects for email messages
GB0027280D0 (en) 2000-11-08 2000-12-27 Malcolm Peter An information management system
US7320019B2 (en) * 2000-11-30 2008-01-15 At&T Delaware Intellectual Property, Inc. Method and apparatus for automatically checking e-mail addresses in outgoing e-mail communications
US6938065B2 (en) * 2000-12-12 2005-08-30 Ericsson Inc. System and method for controlling inclusion of email content
US8230018B2 (en) * 2001-05-08 2012-07-24 Intel Corporation Method and apparatus for preserving confidentiality of electronic mail
US20030037138A1 (en) * 2001-08-16 2003-02-20 International Business Machines Corporation Method, apparatus, and program for identifying, restricting, and monitoring data sent from client computers
US20030093483A1 (en) * 2001-11-13 2003-05-15 Allen Kram Henry System and method for facilitating email communications by providing convenient access to most recently and/or frequently used email addresses
US20030204722A1 (en) * 2002-04-26 2003-10-30 Isadore Schoen Instant messaging apparatus and method with instant messaging secure policy certificates
JP2007072526A (ja) * 2005-09-02 2007-03-22 Fuji Xerox Co Ltd リポジトリ及びデータ入力装置及びプログラム

Also Published As

Publication number Publication date
US9203650B2 (en) 2015-12-01
EP1365340A3 (de) 2003-12-10
CA2565929A1 (en) 2002-05-16
CA2565876A1 (en) 2002-05-16
ATE383622T1 (de) 2008-01-15
JP2009169960A (ja) 2009-07-30
CA2567147A1 (en) 2002-05-16
CA2571516A1 (en) 2002-05-16
EP1369802B1 (de) 2008-01-16
ZA200403538B (en) 2005-01-26
ZA200403537B (en) 2005-01-26
ATE384309T1 (de) 2008-02-15
DE60132369T2 (de) 2009-01-08
ATE384308T1 (de) 2008-02-15
EP1372100B1 (de) 2008-01-16
ZA200403534B (en) 2005-01-26
EP1369802A1 (de) 2003-12-10
US20080301762A1 (en) 2008-12-04
ZA200403539B (en) 2005-01-26
ES2299666T3 (es) 2008-06-01
US7797240B2 (en) 2010-09-14
DE60132365T2 (de) 2009-01-08
US20080301297A1 (en) 2008-12-04
DK1376436T3 (da) 2008-05-26
US7685626B2 (en) 2010-03-23
EP1376436B1 (de) 2008-01-09
US7945519B2 (en) 2011-05-17
US20080300904A1 (en) 2008-12-04
US20080162225A1 (en) 2008-07-03
ZA200403533B (en) 2005-01-26
ZA200403532B (en) 2005-01-26
WO2002039331A2 (en) 2002-05-16
US20050203855A1 (en) 2005-09-15
ATE377810T1 (de) 2007-11-15
JP4354182B2 (ja) 2009-10-28
CA2566262A1 (en) 2002-05-16
EP1360623B1 (de) 2008-01-02
EP1376436A1 (de) 2004-01-02
AU2002212549B2 (en) 2009-04-02
EP1369800A1 (de) 2003-12-10
DE60132365D1 (de) 2008-02-21
AU1254902A (en) 2002-05-21
DE60132495D1 (de) 2008-03-06
CA2566201A1 (en) 2002-05-16
ATE382912T1 (de) 2008-01-15
US20080301761A1 (en) 2008-12-04
ES2299521T3 (es) 2008-06-01
EP1376435A2 (de) 2004-01-02
DE60132495T2 (de) 2009-01-15
GB0027280D0 (en) 2000-12-27
US7836482B2 (en) 2010-11-16
ATE382913T1 (de) 2008-01-15
ATE382914T1 (de) 2008-01-15
CA2567147C (en) 2008-06-03
EP1365340A2 (de) 2003-11-26
DE60132369D1 (de) 2008-02-21
EP1369800B1 (de) 2008-01-02
DK1376435T3 (da) 2008-05-19
US20080172338A1 (en) 2008-07-17
JP2009146456A (ja) 2009-07-02
DE60132493T2 (de) 2009-07-09
ES2299664T3 (es) 2008-06-01
US20080172717A1 (en) 2008-07-17
EP1369801B1 (de) 2007-11-07
CA2566262C (en) 2009-06-30
ZA200403535B (en) 2005-01-26
US9225553B2 (en) 2015-12-29
ZA200303545B (en) 2004-06-22
US20020087479A1 (en) 2002-07-04
DE60131300D1 (de) 2007-12-20
EP1376435A3 (de) 2004-01-07
US7333956B2 (en) 2008-02-19
US20050216771A1 (en) 2005-09-29
EP1372100A1 (de) 2003-12-17
US7669227B2 (en) 2010-02-23
DK1365340T3 (da) 2008-06-30
US20050204172A1 (en) 2005-09-15
ES2299665T3 (es) 2008-06-01
DE60132251T2 (de) 2008-12-24
DE60132254D1 (de) 2008-02-14
DE60132493D1 (de) 2008-03-06
CA2565876C (en) 2009-09-15
ATE383623T1 (de) 2008-01-15
DE60132252T2 (de) 2009-01-15
DE60132253D1 (de) 2008-02-14
WO2002039331A8 (en) 2003-09-18
EP1369801A1 (de) 2003-12-10
EP1376435B1 (de) 2008-01-02
JP2004513460A (ja) 2004-04-30
DE60132251D1 (de) 2008-02-14
US20080301454A1 (en) 2008-12-04
ZA200403536B (en) 2005-01-26
DE60132252D1 (de) 2008-02-14
CA2565895A1 (en) 2002-05-16
US8219815B2 (en) 2012-07-10
EP1365340B1 (de) 2008-01-09
DE60132253T2 (de) 2009-01-02
EP1360623A2 (de) 2003-11-12
EP1378847B1 (de) 2008-01-02
DK1378847T3 (da) 2008-04-28
US20040078334A1 (en) 2004-04-22
ATE382915T1 (de) 2008-01-15
DE60131300T2 (de) 2008-08-28
CA2565949A1 (en) 2002-05-16
US7908224B2 (en) 2011-03-15
ES2299667T3 (es) 2008-06-01
EP1378847A1 (de) 2004-01-07
JP2009146454A (ja) 2009-07-02
CA2566201C (en) 2008-10-14
CA2428238A1 (en) 2002-05-16
JP2009146455A (ja) 2009-07-02
DK1360623T3 (da) 2008-05-19

Similar Documents

Publication Publication Date Title
DE60132254T2 (de) Ein Informationsverwaltungssystem
AU2002212549A1 (en) An information management system

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: COMPUTER ASSOCIATES THINK, INC. (N.D.GES.D. ST, US