DE602004009161T2

DE602004009161T2 - Vorrichtung und verfahren zur bildmanipulation

Info

Publication number: DE602004009161T2
Application number: DE602004009161T
Authority: DE
Inventors: Adam Elgar; Tom Elgar
Original assignee: Serverside Group Ltd
Current assignee: Serverside Group Ltd
Priority date: 2003-02-18
Filing date: 2004-02-17
Publication date: 2008-07-03
Anticipated expiration: 2024-02-18
Also published as: EP1602072A2; MXPA05009939A; US7931199B2; CA2516479A1; EP1847964A3; EP1847964B1; WO2004074961A3; EP1847964A2; JP2006518071A; NZ573835A; US20110072988A1; NZ543516A; DE602004009161D1; AU2009200590A1; US20070156837A1; CA2516479C; AU2009200591B2; CN101676954A; US20150379504A1; US20040160624A1

Description

Technisches Gebiet
Die Erfindung betrifft Verfahren und Vorrichtungen zur Manipulation von Bildern und insbesondere Verfahren und Vorrichtungen zur Reproduzierung von personalisierten Bildern auf Verbrauchergütern an benutzerfernen Orten. Ein bevorzugtes Ausführungsbeispiel beinhaltet eine online arbeitende erzeugnisbasierte Bildmanipulationssoftware.
Hintergrund
Der Wunsch von Kunden bzw. Benutzern nach Selbstdifferenzierung, insbesondere nach Differenzierung von persönlichen Gütern im Massenmarkt, nimmt ständig zu. Dies ergibt sich eindeutig aus der derzeitigen Beliebtheit von kundenspezifischen Handyklingeltönen und Handygehäusen. Um personalisierte Grafiken auf Kundenerzeugnissen bereitzustellen, besteht daher Bedarf an einem schnellen und einfach zu verwendenden Grafikmanipulationsprogrammpaket, das Benutzer in die Lage versetzt, erzeugnisspezifische Gestaltungen zu erstellen, und zwar insbesondere von Orten aus, die vom Hauptbildspeicher und der Druckeinrichtung entfernt sind. Das Bereitstellen eines derartigen Grafikmanipulationsprogrammpaketes über das Internet hat sich jedoch als nicht einfach erwiesen.
Ein Problem rührt von der offenen Natur des Internets selbst her. Um Internetbenutzer in die Lage zu versetzen, Hunderttausende von nicht verifizierten Webseiten zu besuchen und dabei dennoch den Schutz des Computers des Benutzers vor Viren und böswilligen Hackern zu gewährleisten, darf ein Browser nicht zulassen, dass die Webseiten auf Dateien auf dem Computer des Benutzers zugreifen. Die Browser sind daher „passive" Endgeräte, wenn auch äußerst vielseitige. Es ist in der Tat nicht einfach, etwas mit einem Internetbrowser aktiv zu „tun", da dieser einfach zwischen Online-Ressourcen navigiert sowie dem Benutzer Informationen und Bilder präsentiert. Zum Zwecke der Gestaltung eines graphischen Bildes zur Anwendung bei bzw. zur Anbringung an einem persönlichen Gegenstand kann ein Internetbenutzer daher in die Lage versetzt werden, Bilder innerhalb der Browserumgebung zu manipulieren; er ist jedoch nicht in der Lage, diese Bilder zu speichern.
Das Problem der Manipulation von Bildern, die an einem Erzeugnis angebracht werden sollen, das entfernt von dem Benutzer ist, wurde bislang auf zwei Arten gelöst, von denen jede Nachteile aufweist. Bei einer Lösung manipuliert der Benutzer Bilder auf seinem oder ihrem Rechner ohne Verwendung eines Browsers. Diese Lösung weist den Vorteil auf, dass sie, sobald sie auf dem lokalen Rechner installiert ist, äußerst schnell ist; sie leidet jedoch an drei grundsätzlichen Nachteilen. Zunächst muss der Benutzer, damit das Programm auf dem Client-Rechner laufen kann, ein Programm herunterladen. Dies erfordert Zeit und ist unbequem, da die Software nicht besehen oder geprüft werden kann, bis sie vollständig heruntergeladen ist. Zudem muss das Programm auf dem Rechner des Benutzers installiert werden, wo es dann dauerhaft verbleibt, bis es entfernt wird. Dies nimmt Speicherplatz auf der Festplatte des Clients in Anspruch, verlangsamt den Computer des Benutzers und kann Systemabstürze verursachen. Schließlich kann das heruntergeladene Programm auch Computerviren enthalten.
Bei einer anderen Lösung zur Bildmanipulation wird ein Bild direkt auf einem Server unter Verwendung von Java-Applets oder einem anderen auf ähnliche Weise arbeitenden Zusatzprogramm bzw. Plug-in manipuliert, so beispielsweise einer gängigen Activex-Steuerung. Immer dann, wenn der Benutzer die Schnittstelle verwendet, um eine Manipulation an dem Bild vorzunehmen, wird der Server eigens aufgerufen, die Serversoftware ändert die Position des Bildes und sendet die Informationen zurück an den Client-Rechner. Die theoretischen Vorteile von Java und ähnlichen Programmen bestehen darin, dass sie auf einem beliebigen Client-Rechner laufen können und dabei identische Ergebnisse erzeugen, sowie darin, dass die Software nicht auf dem Client-Rechner installiert werden muss, da die Java-Applets innerhalb einer Java Virtual Machine des Browsers laufen. Gleichwohl besteht bei Java und ähnlichen Programmen das Problem, dass das Internet einfach nicht schnell genug ist, um eine ausreichende Benutzerfreundlichkeit zu gewährleisten. In der Praxis kann es aufgrund der Tatsache, dass das Java-Applet nicht weiß, auf welcher Art von Rechner es laufen wird, bei verschiedenen Rechnern sehr unterschiedlich reagieren.
Die europäische Patentveröffentlichung Nr. 0878956A offenbart ein Verfahren und ein System zum Bearbeiten von Fotos über das Internet, die Druckschrift US2002/057454 hingegen zum Bearbeiten von Druckmaterialien über das Internet.
Die deutsche Patentveröffentlichung Nr. 10055649 offenbart ein Verfahren zur Personalisierung von Bildern, die an Erzeugnissen angebracht werden.
Die koreanische Patentveröffentlichung Nr. 2002-00330704 offenbart ein Verfahren zum Bearbeiten der Gestaltung einer Kreditkarte.
Zusammenfassung
Bei einem Ausführungsbeispiel entsprechend der Erfindung wird ein Transaktionskartenbildpersonalisierungscomputersystem zur Manipulation von Bildern entsprechend Anspruch 1 offenbart.
Bei zugehörigen Ausführungsbeispielen kann darüber hinaus das an dem Bildspeicher gehaltene Bild eine relativ höhere Auflösung als die grafische Darstellung zumindest eines Abschnittes des Bildes aufweisen. Der Bildprozessor kann des Weiteren Mittel zum Kommunizieren einer die vorgenommenen Manipulationen enthaltenden Version des Bildes an eine Bilddruckvorrichtung, die sicher vor der Benutzerschnittstelle gehalten wird, umfassen. Das Computersystem kann des Weiteren Mittel zum Zuordnen eines eindeutigen Identifizierers an den die Manipulationen an der grafischen Darstellung vornehmenden Benutzer umfassen, wobei die Internetkommunikationsverbindung wirksam ist, um den eindeutigen Identifizierer zwischen der Benutzerschnittstelle und dem Bildprozessor zu übertragen. Der Bildprozessor kann zudem Mittel zum Empfangen eines Hash-Wertes umfassen, der sich auf denjenigen Benutzer bezieht, der die Manipulationen an der grafischen Darstellung vorgenommen hat. Die browserbasierte Benutzerschnittstelle kann an einem Kiosk präsentiert werden, zu dem ein Kunde Zugang hat. Das Computersystem kann des Weiteren eine Datenbank umfassen, die in der Lage ist, die Informationen über die an der grafischen Darstellung vorgenommenen Manipulationen zu speichern, sodass eine Manipulation an dem in dem Bildspeicher gehaltenen Bild anders als in Echtzeit vorgenommen werden kann, oder alternativ die chargenweise bzw. batchweise Verarbeitung von Aufträgen zum Drucken auf die verschiedenen Erzeugnisse ermöglicht wird. Das Computersystem kann des Weiteren einen Drucker zum auf eine Transaktionskarte erfolgenden Drucken eines Bildes umfassen, die durch Vornehmen von Manipulationen erzeugt wird, die diejenigen, die an der grafischen Darstellung vorgenommen worden sind, emulieren.
Bei einem weiteren Ausführungsbeispiel entsprechend der Erfindung wird ein Verfahren zum Betreiben eines Transaktionskartenbildpersonalisierungscomputersystems nach Anspruch 7 offenbart.
Bei zugehörigen Ausführungsbeispielen kann das Verfahren des Weiteren ein Übertragen eines eindeutigen Identifizierers zwischen der Benutzerschnittstelle und dem Bildprozessor umfassen, wobei der eindeutige Identifizierer dem Benutzer zugeordnet ist, der die Manipulationen an der grafischen Darstellung vornimmt. Das Verfahren kann zudem ein Empfangen eines Hash-Wertes an dem Bildprozessor umfassen, wobei sich der Hash-Wert auf den Benutzer bezieht, der die Manipulationen an der grafischen Darstellung vornimmt; oder das Präsentieren der browserbasierten Benutzerschnittstelle an einem Kiosk, der für einen Kunden zugänglich ist. Das Verfahren kann des Weiteren ein Speichern von Informationen über die an der grafischen Darstellung vorgenommenen Manipulationen in einer Datenbank umfassen, sodass die Manipulationen an dem in dem Bildspeicher gehaltenen Bild anders als in Echtzeit vorgenommenen werden können, oder alternativ das batchweise bzw. chargenweise Verarbeiten von Druckaufträgen für verschiedene Erzeugnisse ermöglicht wird. Das Verfahren kann zudem das auf eine Transaktionskarte erfolgende Drucken eines Bildes umfassen, das durch Vornehmen von Manipulationen erzeugt worden ist, die diejenigen emulieren, die an der grafischen Darstellung vorgenommen worden sind.
Bei einem weiteren Ausführungsbeispiel entsprechend der Erfindung wird ein Transaktionskartenbildpersonalisierungscomputerprogrammerzeugnis nach Anspruch 13 offenbart.
Bei zugehörigen Ausführungsbeispielen kann das System des Weiteren einen Front-End-Server zum Präsentieren der Benutzerschnittstelle sowie einen Back-End-Server umfassen, der den Bildprozessor umfasst sowie mit dem Front-End-Server und dem Bildspeicher kommuniziert. Der Front-End-Server kann des Weiteren Mittel zum Kommunizieren einer Benutzermanipulationsdatenkette bzw. eines Benutzermanipulationsdatenstrings an den Back-End-Server umfassen. Die grafische Darstellung des ursprünglichen Bildes kann eine größenangepasste (resized) Version des ursprünglichen Bildes enthalten. Die Benutzermanipulationen können Vorgänge umfassen, die unter den Vorgängen Drehen, Größenanpassen (resize), Positionieren, Kippen (flip), Steuern der Helligkeit, Durchführen einer Augenrötereduzierung und Anpassen von Opazitätsstufen ausgewählt sind. Die Benutzermanipulationsdaten können des Weiteren Daten umfassen, die sich auf wenigstens ein Bild zur Überlagerung des ursprünglichen Bildes beziehen. Das wenigstens eine Bild zur Überlagerung kann wenigstens einen transparenten Abschnitt umfassen.
Kurzbeschreibung der Zeichnung
Für ein tieferes Verständnis der vorliegenden Erfindung sowie zur Darlegung, wie diese in der Praxis umgesetzt wird, erfolgt nachstehend beispielhalber die Bezugnahme auf die begleitende Zeichnung, die sich wie folgt zusammensetzt.
1 zeigt ein Computersystem zur Fernmanipulation von Bildern entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung.
2 zeigt ein Verfahren zum Betreiben eines Computersystems zur Fernmanipulation von Bildern entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung.
3 bis 10 zeigen Bildschirme einer Kreditkartengestaltungswebseite, die entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung verwendet wird.
11 zeigt ein Verfahren zum Betreiben eines Computersystems zur Fernmanipulation von Bildern unter Verwendung eines eindeutigen Kundenidentifizierers entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung.
12 zeigt ein Verfahren zum Betreiben eines Computersystems zur Fernmanipulation von Bildern unter Verwendung eines Hash-Wertes zur Vermeidung der Notwendigkeit der Gestaltung und Vorhaltung eines eindeutigen Kundenidentifizierers während der Kartenanwendung und des Drucklebenszyklus entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung.
13 zeigt ein System entsprechend einem Ausführungsbeispiel der Erfindung, bei dem ein Bild unter Verwendung eines Kartenausgabekiosks oder eines ladeninternen Sofortausgabesystems gestaltet wird.
14 zeigt ein System, bei dem eine Datenbank zur Speicherung von Informationen zwischen benutzerseitigen Bildauswahloptionen und einer Back-End-Bilderzeugung entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung verwendet wird.
Detailbeschreibung
Ein Ausführungsbeispiel entsprechend der Erfindung versetzt einen Benutzer in die Lage, ein Bild über eine Browserschnittstelle zu manipulieren, und ist in zwei Softwareabschnitte unterteilt, die hier als Front-End-Software und Back-End-Software bezeichnet werden.
Die Front-End-Software arbeitet vollständig innerhalb eines Internetbrowsers und muss in den meisten Fällen nicht heruntergeladen werden, da sie mit den Beschränkungen des Browsers auskommt. Bei einem Ausführungsbeispiel ist die eingesetzte Front-End-Software die Flash-Software, die bei der Firma Macromedia Inc. aus 600 Townsend Street, San Francisco, CA 94103, USA erhältlich ist, oder eine gleichwertige Software. Die Front-End-Software ist eine reine grafische Benutzerschnittstelle (GUI graphical user interface) und versetzt einen Benutzer in die Lage, Grafiken auf seinem/ihrem Bildschirm zu gestalten und zu bearbeiten, um eine Darstellung eines gewünschten Bildes aufzubauen. Darstellungen von Repertoirebildern (Anfangsbildern) können einem Benutzer in einer Bildschirmbilddatenbank präsentiert und/oder von dem Benutzer auf Anfrage erzeugt werden. Das Bild, dessen Ausgabe man wünscht, kann aus einer oder mehreren repräsentativen Komponenten aufgebaut sein, von denen jede eine Position aufweist, die relativ zu einem Ursprung definiert ist, und kann auf Grundlage eines Satzes von vorbestimmtem Regeln manipuliert werden, so beispielsweise von Regeln, die an dem Bild oder dessen Komponenten ein Größenanpassen (resize), Drehen, Kippen (flip), Spiegeln und Bewegen relativ zu anderen Komponenten zulassen. Die repräsentativen graphischen Komponenten können beispielsweise zum Aufbau relativ komplexer Gestaltungen verwendet werden, die aus einer Mehrzahl von unterschiedlichen Schichten und/oder Transparenzen, die unter Verwendung von Flash-Szenen aufgebaut werden, bestehen.
Ist die Gestaltung fertig, so werden bei einem Ausführungsbeispiel entsprechend der Erfindung Anweisungen dahingehend, wie das fertige Bild aussieht, an die Back-End-Software, die auf einem Server läuft, gesendet. Bei dem bevorzugten Ausführungsbeispiel werden diese Anwendungen zusammen (gleichzeitig) gesendet, nachdem die Manipulation beendet ist, und weisen die Form einer Textkette bzw. eines Textstrings für jede Komponente des Bildes auf. So kann beispielsweise die Textkette bzw. der Textstring „makeimage.aspx" für eine Grafikkomponente folgendermaßen aussehen.
id+ = 030, x = 182, y = 32,3, flip = yes, rotate = 270, scale = 190.6, user = 230
Hierbei ist „id" ein Bildidentifizierer, „x" und „y" definieren die Position einer Komponente relativ zu einem vorbestimmten Ursprung; „flip", „rotate" und „scale" definieren Manipulationen einer Art, wie sie aus dem Stand der Technik bekannt ist; und „user" ist eine den Benutzer identifizierende Zahl. Fachleuten auf dem einschlägigen Gebiet erschließt sich, dass auf diese Weise ein Bündel von Bildmanipulationen definiert werden kann. Ein fertiges Bild kann durch eine oder mehrere graphische Komponenten dargestellt werden. Für eine Mehrzahl von Textketten bzw. Textstrings oder eine erweiterte Textkette bzw. einen erweiterten Textstring ist es daher möglich, ein Bild zu definieren, das aus einer Mehrzahl von separaten graphischen Komponenten besteht. Die graphischen Komponenten, die beispielsweise in Flash-Movie-Szenen verwendet werden, werden mit einem Minimum an Rechnerressourcen erzeugt und manipuliert. Die Gestaltungen, die als Ergebnis entstehen, können auf der Back-End-Seite (Server) unter Verwendung der einschlägigen (und im Allgemeinen viel größeren) Bilddateien neugestaltet werden. Relativ komplizierte Gestaltungen können durch Einsetzen von zwei oder mehr Bildkomponenten mit getrennten Identifizierern verwirktlicht werden. Die Bildidentifizierer für grafische Komponenten desselben Bildes können eine gemeinsame Eigenschaft aufweisen. In Entsprechung zu Ausführungsbeispielen der Erfindung müssen die Anweisungen, die in der Textkette bzw. dem Textstring enthalten sind, die bzw. der die Manipulation definiert, die zur Gestaltung des fertigen Bildes erforderlich ist, nicht alle in einer einzigen Textkette bzw. einem einzigen Textstring enthalten sein. Anstatt dessen kann eine Reihe von Textketten bzw. Textstrings getrennt übertragen werden, um dieselbe Vielzahl von Anweisungen zu übertragen. Darüber hinaus müssen die Manipulationen auf den entfernten Servern nicht den Empfang der gesamten Folge von Textketten bzw. Textstrings abwarten, sondern können anstatt dessen in Stufen ausgeführt werden, wenn jede Kette bzw. jeder String empfangen wird. Unabhängig von der Anzahl der verwendeten Textketten bzw. Textstrings besteht ein Vorteil eines Ausführungsbeispieles entsprechend der Erfindung darin, dass eine kleinere emulierte Version des Bildes von dem Benutzer mit einem Minimum an Rechnerressourcen manipuliert werden kann und Anweisungen effizient als Textketten bzw. Textstrings übertragen werden können, anstatt dass die ineffiziente (und zeitaufwändige) Übertragung von großen Bilddateien oder von Teilen hiervon zwischen dem Kunden und einem Bilderzeugungsserver von Nöten wäre. Darüber hinaus ist die Notwendigkeit, einen Server mit einer Bildänderung immer dann, wenn eine einzelne Manipulation vorgenommen worden ist, aufzurufen, ebenfalls nicht mehr gegeben.
Die Back-End-Software ist entsprechend einem Ausführungsbeispiel der Erfindung für die Erzeugung des fertigen Bildes verantwortlich, und zwar durch Interpretieren der an der Darstellung (gemäß Definition in der oder jeder Textkettendatei bzw. Textstringdatei) vorgenommenen Manipulationen und durch Vornehmen von entsprechenden Manipulationen an einem oder mehreren in einem entfernten Bildspeicher gehaltenen Repertoirebildern. Die in der Front-End-Software verwendeten Bilder sind rechentechnisch weniger aufwändige Darstellungen derjenigen Bilder, die auf dem Server gehalten werden. Im Ergebnis kann die Back-End-Software Bildtransformationen vornehmen, die diejenigen, die auf dem Client-Rechner sichtbar sind, genau wiedergeben. Sobald das gewünschte Bild von der Back-End-Software gestaltet worden ist, kann das Bild an eine beliebige gewünschte Vorrichtung ausgegeben werden, so beispielsweise eine Vorrichtung zum Drucken des Bildes auf einen personalisierten Kundengegenstand. Auf diese Weise wird die grafische Darstellung angezeigt und an der Benutzerschnittstelle mittels der Flash-Software manipuliert, wobei nur eine minimale Menge an Informationen im Zusammenhang mit dem Bild und den daran vorgenommenen Manipulationen an den entfernten Bildprozessor übertragen werden muss.
Wie vorstehend erwähnt worden ist, kann die Front-End-Software Macromedia-Flash oder ein anderes Erzeugnis einsetzen. Die Software kann anstatt dessen auch beispielsweise HTML und Javascript (DHTML) ohne Herunterladen einsetzen, obwohl die grafische Schnittstelle relativ schwach ist. Die Verwendung von Flash oder einer gleichwertigen Software bietet Vorteile dahingehend, dass sie einen vollen Zugriff auf die lokalen Dateien des Benutzers nicht zulässt, sodass das Risiko einer Übertragung von Computerviren auf den Rechner des Benutzers nicht gegeben ist. Die Verwendung der Flash-Software macht zudem nicht erforderlich, dass der Benutzer Software über das Flash-Zusatzprogramm hinausgehend installiert, das sich auf dem Markt für Browser bereits durchgesetzt hat.
Das bevorzugte Ausführungsbeispiel ermöglicht daher eine online erfolgende Bildmanipulation durch Emulieren der browserbasierten Transformationen (so beispielsweise des Größenanpassens (resize) oder Überlagerns von Bildern), die von dem Benutzer an einer Darstellung des Bildes vorgenommen werden, auf dem Server, sodass die erzeugten Bilder für die Gestaltung eines personalisierten Erzeugnisses verwendet werden können.
Die online erfolgende Bildmanipulation wird bei einem Ausführungsbeispiel der Erfindung durch Bereitstellen einer Zweistufenarchitektur ermöglicht. So ist ein Programm vorhanden, das eine Bildmanipulation am Bildschirm eines Benutzers ermöglicht, sowie ein zweites Programm auf einem Server, das diese Manipulation emuliert, sodass die Bilder für die Gestaltung eines personalisierten Erzeugnisses ausgegeben werden können. Bei dem bevorzugten Ausführungsbeispiel kann der Back-End-Prozess oder Elemente hiervon in einer sicheren Berechnungsumgebung ausgeführt werden. Zudem können kundenspezifische Bilder unter sehr hoher Sicherheit (beispielsweise Sicherheit auf Bankniveau) auf ein Erzeugnis aufgedruckt werden. Auf diese Weise kann ein Benutzer mit Internetzugang kundenspezifische Bilder zum Drucken auf ein entferntes Erzeugnis, das einer sicheren Behandlung, so beispielsweise einer Sicherheit auf Bankniveau, bedarf, gestalten. So können beispielsweise Betrugsabwehr- und Diebstahlabwehrmaßnahmen beinhalten, dass die Erzeugung von Kreditkarten und anderen Arten von Transaktionskarten an sicheren Orten stattfindet. Die Kundenspezifischheit der Gestaltungen, mit denen derartige Karten versehen werden, erfolgt damit bei Verwendung bevorzugter Ausführungsbeispiele ohne die Notwendigkeit, dass der Benutzer einen direkten Rechnerzugang zu der sicheren Umgebung erhält.
Ein online verfügbares Bildbearbeitungswerkzeug bedient sich bei einem Ausführungsbeispiel der Erfindung der Browserumgebung von HTML und Macromedia-Flash als grafischer Benutzerschnittstelle für Fernsoftware, die die an dem Client-Rechner vorgenommenen Handlungen emuliert. Dies ermöglicht ein schnelles Erfolgserlebnis für den Benutzer sowie ein qualitativ hochwertiges Enderzeugnis. Gleichwohl muss die browserbasierte clientseitige Umgebung, die eine Manipulation durch den Benutzer ermöglicht, nicht notwendigerweise Flash von Macromedia sein. Ein beliebiges anderes gleichwertiges Softwarewerkzeug, das in der Lage ist, die erforderliche Funktionalität bereitzustellen, kann ebenfalls verwendet werden, so beispielsweise ein beliebiges Werkzeug, das in der Lage ist, eine Darstellung eines Bildes zu erzeugen, Manipulationen hieran vorzunehmen und die Ergebnisse durch einen Satz von Befehlen an die serverseitige Software zu übertragen, damit ein Bildprozessor auf der Serverseite die Front-End-Handlungen emulieren und ein fertiges Bild gestalten kann, das auf dem Server gespeichert werden kann. Die Front-End-Software ermöglicht das Hochladen von Bildern von dem Computer des Benutzers auf den Server, damit die eigenen Bilder des Benutzers manipuliert und mit „Repertoirebildern" und Berandungselementen überlagert werden können. Durch Kommunizieren mit der Back-End-Software wird es damit möglich, personalisierte Güter für einen Benutzer zu erzeugen. Derartige personalisierte Güter umfassen beispielsweise Kreditkarten, Bezahlkarten, Mobiltelefongehäuse, Krüge, T-Shirts, Geschenkkarten und gerahmte Drucke.
Ein Ausführungsbeispiel entsprechend der Erfindung weist den Vorteil auf, dass qualitativ hochwertige Bilder während des Manipulationsprozesses nicht in den Browser des Kunden hochgeladen werden müssen, da anstatt dessen zum Vorteil des Benutzers einfache und webtaugliche Formate verwendet werden, wodurch das System schnell und einfach zu verwenden ist. Gleichwohl werden, wenn die Informationen übertragen sind, die ursprünglichen qualitativ hochwertigen Bilder verwendet, sodass auch die Druckergebnisse qualitativ hochwertig sind. Ein Ausführungsbeispiel entsprechend der Erfindung erlaubt zudem das Bereitstellen einer einfachen und dennoch schnellen Grafikmanipulation ohne Verkomplizierung durch das Herunterladen von Programmen. Darüber hinaus ruft eine Benutzerschnittstelle entsprechend der vorliegenden Erfindung nicht fortwährend einen Server auf. Damit ist die Schnittstelle schnell und benutzerfreundlich, und die Internetbandbreite wird effizient genutzt. Ein weiterer Vorteil eines Ausführungsbeispieles der Erfindung besteht darin, dass das ursprüngliche Bild in der Manipulationsphase nicht über das Internet übertragen wird, sodass die Möglichkeiten, das Bild zu hacken, stark verringert sind. Da die Schnittstelle innerhalb der Macromedia-Flash-Umgebung läuft, ist die Schnittstelle darüber hinaus plattformunabhängig. Da das fertige Bild auf einem Server unter Kontrolle eines einzigen Unternehmens gestaltet werden kann, kann die Ausgabe des fertigen Bildes auch in standardisierter Größe und Auflösung erfolgen. Dies erlaubt eine einfache Zusammenarbeit mit Druckern, vereinfacht die Erzeugung eines personalisierten Erzeugnisses und vereinfacht die bildweise erfolgende Abrechnung.
1 und 2 beschreiben beispielhalber die Erzeugung einer Kreditkarte entsprechend einem Ausführungsbeispiel der Erfindung.
Bei dem Ausführungsbeispiel von 1 greift ein Kunde entsprechend der Erfindung auf Software zu, nachdem er um eine Kreditkarte auf der Webseite 101 eines Kartenausgebers (so beispielsweise einer Bank) nachgesucht hat. In dem ersten Schritt gibt der Kartenausgeber an den Kunden eine eindeutige Identifikationsnummer 103 aus, die an den Bildzusammenstellungsserver 108 weitergeleitet wird, der gegebenenfalls von einer Firma, die nicht diejenige des Kartenausgebers ist, betrieben wird. Der Kartenausgeber ordnet den eindeutigen Kundenidentifizierer 103 den Finanzinformationen des Kunden 104 zu. Diese Zuordnung kann in einer Finanzkontozuordnungstabelle 124 erfolgen, die in einer Umgebung vorgehalten wird, die sicher vor der Benutzerschnittstelle ist. Der zugeordnete Kundenidentifizierer 103 und die Finanzinformationen 104 werden über eine Firewall 102 an einen Druckerserver 109 einer Bank (oder eines anderen Kartenausgebers) weitergeleitet. Anschließend startet der Kunde die Front-End-Software 105, die von einem Webseitenserver oder einem anderen Front-End-Server betrieben werden kann. Der Kunde wählt ein Bild 107 – in 1 von der Computerfestplatte 106 des Kunden – und lädt es auf den Bildzusammenstellungsserver 108 hoch. Das Bild 107 kann aus einer beliebigen geeigneten Quelle stammen, so beispielsweise einer Bildbibliothek, die vom Betreiber des Bildzusammenstellungsservers 108 vorgehalten wird. Die Back-End-Software 110, die auf dem Bildzusammenstellungsserver 108 läuft, gibt nun das ursprüngliche Bild in eine Datenbank ein und erzeugt eine webtaugliche kleinere Kopie 111, die an die Front-End-Software 105 gesendet wird. Der Kunde nimmt nun je nach Wunsch Bildmanipulationen 112, so beispielsweise Größenanpassungen (resize), Drehungen und Platzierungen des Bildes, vor. Die Back-End-Software 110 ordnet die kundenseitige Bildauswahl sowie nachfolgende Manipulationen und Auswahlvorgänge dem eindeutigen Kundenidentifizierer 103 zu. Anschließend wählt der Kunde ein weiteres Bild 113, das mit dem ersten Bild 117 überlagert wird, und positioniert das Bild 113 je nach Wunsch. Das Überlagerungsbild 113 kann beispielsweise ein transparenter Zierrahmen für das hochgeladene Bild 107 sein und auf einem Bildserver 114 vorgehalten werden. Die Back-End-Software 110 überträgt eine webtaugliche kleinere Version 115 des Überlagerungsbildes 113 an den Kunden, damit die Gestaltung einer Kombination 116 des ursprünglichen manipulierten Bildes 107 mit dem Überlagerungsbild 113 erfolgen kann. Sobald eine Zustimmung 117 des Kunden zu der endgültigen Gestaltung 116 abgegeben und der Front-End-Software 105 gegenüber mitgeteilt worden ist, überträgt die Front-End-Software 105 eine Kette bzw. einen String von Benutzermanipulationsdaten 118 an den Bildzusammenstellungsserver 108. Die Kette bzw. der String 118 verkapselt die kundenseitigen Bildauswahloptionen und Manipulationen. Bei Empfang dieser Kette bzw. dieses Strings 118 greift die Back-End-Software 110 auf die ursprünglichen Kopien der Bilder aus der Bildbibliothek zurück und führt genau diejenigen Operationen, die der Kunde mit der Front-End-Software 105 ausgeführt hat, für die endgültige Kundengestaltung aus. Auf diese Weise emuliert die Back-End-Software 110 die Manipulationen am Benutzerende entsprechend derjenigen Informationen, die in der Textkette bzw. dem Textstring (hier auch als Ergebnisscript bezeichnet) übertragen worden sind. An diesem Punkt kann die Back-End-Software 110 das fertige Bild 119 an den Druckerserver 120 ausgeben, was über eine Firewall 121 geschehen kann. Das fertige Bild 119 und der zugeordnete Kundenidentifizierer 103 können anschließend an den Druckerserver 109 einer Bank (oder eines anderen Kartenausgebers) weitergeleitet werden, der wiederum auf die Finanzkontozuordnungstabelle 124 zugreift, um die zugeordneten sicheren Kundenfinanzinformationen 104 zu erhalten. Die Finanzinformationen 104 und das fertige Bild können anschließend an den Kreditkartendrucker 122 gesendet werden, der eine kundenspezifische Kreditkarte 123 druckt. Sämtliche Bilder, die von dem Kunden in der Front-End-Software 105 verwendet werden, werden über die Back-End-Software 110 ausgegeben. Die einzigen Informationen, die an die Back-End-Software 100 von der Front-End-Software 105 (außer der Bildanforderungen) ausgegeben werden, sind Daten dahingehend, wie das Bild des Kunden aussieht. Diese Informationen können leicht verschlüsselt werden, um die Sicherheit zu erhöhen. Die Anzahl der Bilder, die bei den Gestaltungen kombiniert werden, ist nicht auf ein oder zwei Bilder (entsprechend den Bildern 107 und 113) beschränkt. Das Skript kann vielmehr einfach auf mehrere Schichten erweitert werden. Darüber hinaus müssen die transparenten Rahmenbildschichten nicht vor einer nichttransparenten Bildschicht ausgewählt und manipuliert werden. Die Bildschichten können vielmehr in einer beliebigen Reihenfolge gestaltet werden. Text kann ebenfalls über eine ähnliche Replikation in das Bild eingefügt werden. Das ausgegebene Bild kann an eine beliebige Art von Rechner gesendet werden, weshalb die möglichen Anwendungen äußerst vielfältig sind. So kann die Software nicht nur im Zahlungskartenmarkt verwendet werden, sondern auch für Nichtzahlungskarten und Telefonkarten. Bei bestimmten Ausführungsbeispielen können Schichten als Muster und/oder Markierungen eingesetzt werden, die hier Transparenzen genannt werden. Bei einem Ausführungsbeispiel kann das auf der Karte angezeigte fertige Bild auf einen vorher ausgewählten vordefinierten Bereich beschränkt sein, so beispielsweise ein „Fenster" auf einer Zahlungskarte (oder einem anderen Finanzkontenzugriffsmittel), wobei der Rest der Karte dann freibleibt, um funktionelle Merkmale der Karte aufnehmen, so beispielsweise ein Banklogo, ein Zahlungskartenhologramm oder eine Typangabe (beispielsweise für die Logos von „Visa" oder „Mastercard"). Alternativ können einige Bildschichten innerhalb eines ausgewählten Fensters auf der Karte angeordnet werden, während andere Bildschichten (beispielsweise Transparenzen) außerhalb des ausgewählten Fensters angeordnet werden und dabei die funktionellen Merkmale der Karte (so beispielsweise das Banklogo, das Zahlungskartenhologramm und dergleichen mehr) umgeben. Zudem können das Banklogo oder ein anderes Finanzmerkmal als feste Vorlage dienen, hinter die der Benutzer das Bild an eine gewünschte Position bewegen kann.
Bei dem Ausführungsbeispiel von 2 sucht in einem ersten Schritt 231 ein Kunde 251 bei einer Bank (oder einem anderen Kartenausgeber) online um eine Kreditkarte nach oder ist ein bereits vorhandener Kunde, dem die Möglichkeit geboten wird, eine neue Karte für ein bestimmtes Konto zu erzeugen. In einem Schritt 232 klickt der Kunde auf einen Link, der den Benutzer zu einer Webseite (die von einer Firma betrieben werden kann, die nicht diejenige des Kartenausgebers ist) zur Neugestaltung der Kreditkarte leitet und gelangt dorthin mit einem eindeutigen Identifizierer, der sich auf das Konto des Kunden bezieht und das den Kunden begleitet, solange er sich auf der Seite aufhält. In Schritt 233 wird der Kundenidentifizierer zum Einloggen verwendet. Alternativ kann sich der Kunde an diesem Punkt separat einloggen und den Kundenidentifizierer wiederaufnehmen. Da die Gestaltungswebseite nur den Kundenidentifizierer zur Identifizierung des Kunden verwendet, erlangt sie keine Kenntnis von irgendwelchen finanziellen Daten des Kunden. In Schritt 234 wählt der Kunde das hochzuladende Bild von seinem eigenen Computer 252, so beispielsweise ein gescanntes Bild oder eine Fotografie, aus. In Schritt 235 wird das Bild auf den Bildserver hochgeladen und kann der Einfachheit halber in einer Datenbank 253 vorgehalten werden. In Schritt 236 startet der Kunde eine browserbasierte Bildmanipulationssoftware 254. In Schritt 237 fordert die Bildmanipulationssoftware eine Reihe von Bildern in webtauglichen Formaten von einem Bildgrößenanpassungswerkzeug 255 an, weshalb der Prozess schnell und leicht vor sich geht. In Schritt 238 fordert das Bildgrößenanpassungswerkzeug das ursprüngliche Bild aus der Datenbank 253 an. In Schritt 239 wird das ursprüngliche Bild ausgegeben und auf ein webtaugliches Format und eine webtaugliche Größe angepasst. In Schritt 240 wird ein Satz von webtauglichen Bildern an die Bildmanipulationssoftware 254 (es sind dies grafische Darstellungen des ursprünglichen Bildes, an dem Manipulationen vorgenommen werden können) aus. Sobald der Kunde die gewünschte Wirkung durch Manipulation der Folge von Bildern je nach Wunsch erreicht hat, werden die zugeordneten Bildmanipulationsbefehle an eine Bildmanipulationssoftware 256 gesendet, siehe 241. Die Bildmanipulationsbefehle können beispielsweise das Drehen, Größenanpassen (resize), Positionieren, Kippen (flip), Skalieren, Steuern der Helligkeit, Verringern der Augenröte, Opazitätsstufen und anderen Manipulationen umfassen. In Schritt 242 fordert der Bildmanipulationsemulator 256 sodann das ursprüngliche Bild von dem Bildserver an, sodass das Bild bester Qualität verwendet wird. Beim Empfang der Bilder in Schritt 243 wiederholt der Emulator 256 sodann vollständig die Transformationen des Kunden und gestaltet ein Bild, das dasjenige emuliert, das online gestaltet worden ist, das sich jedoch der ursprünglichen qualitativ höherwertigen Grafiken bedient. In Schritt 244 werden dieses Bild und der zugeordnete Kundenidentifizierer an den Drucker 257 der Bank gesendet. Die Finanzdaten entsprechend dem Kundenidentifizierer werden über eine sichere Verbindung 258 zu der Bank (oder einem anderen Kartenausgeber) erhalten, woraufhin der Druckprozess in Gang gesetzt wird.
Bei einem Ausführungsbeispiel entsprechend der Erfindung, bei dem personalisierte Bilder auf Kunststoffkarten vom Kreditkartentyp aufgebracht werden, ist es notwendig, ein sehr hohes Sicherheitsniveau zu gewährleisten. Daher empfängt unter Gegebenheiten, bei denen bereits finanzielle Aufzeichnungen für einen Benutzer vorhanden sind, die Architektur von dem Kreditkartenausgeber einen eindeutigen nichtsequenziellen Kundenidentifizierer, der zu einem Satz von finanziellen Aufzeichnungen passt. Dieser Kundenidentifizierer wird durch jedes Element des Systems geleitet und mit der erzeugten Bilddatei ausgegeben. Es handelt sich hierbei um einen Vorgang vom „Mail-Merge"-Typ, wobei das personalisierte Bild des Kunden mit den finanziellen und persönlichen Aufzeichnungen des Kunden abgeglichen werden kann, damit das richtige Bild auf der Karte platziert wird. Zu keiner Zeit hat die Front-End-Software oder die Back-End-Software Kenntnis von irgendwelchen finanziellen Informationen. Der Kundenidentifizierer kann in einem automatisierten Log-In-Prozess verwendet werden. Auf diese Weise kann die Software (und zwar sowohl die Front-End- wie auch die Back-End-Software) Kenntnisse dahingehend haben, ob der Benutzer neu ist oder nicht. Einem wiederkommenden Besucher können daher Bilder präsentiert werden, die bei dessen vorhergehendem Besuch hochgeladen worden sind.
Die Architektur des Systems umfasst bei einem Ausführungsbeispiel der Erfindung zwei unterschiedliche Elemente. Das Front-End-Element, das heißt das Element, mit dem der Benutzer interagiert, ist in Macromedia-Flash eingebaut. Dieses Element versetzt den Benutzer in die Lage, eine Karte durch Manipulieren (mittels Skalieren, Drehen oder Durchführen anderer Manipulationen entsprechend den oben aufgeführten) des hochgeladenen Bildes und anschließendes Überlagern des Bildes mit Rahmen, die transparente Abschnitte enthalten können, zu gestalten. Da Flash nicht über „lokale Zugriffsrechte" auf dem Client-Rechner verfügt, weil es sich hierbei um eine browserbasierte Schnittstelle handelt, ist Flash nicht in der Lage, die endgültige Gestaltung zu speichern. Es erfolgt daher die Sendung einer Kette bzw. eines Strings von Anweisungen an ein zweites serverseitiges Element. Das zweite serverseitige Element kann in C# geschrieben sein, obwohl Java, C, C++ oder eine beliebige andere geeignete Sprache gleichermaßen geeignet sind. Die Anweisungskette bzw. der Anweisungsstring kann als „Abfragestring" (querystring) gesendet werden, das heißt als Teil der URL. So kann der String beispielsweise folgendermaßen formatiert sein.
(createpage.aspx?here_are_the_string_of_instructions&rotate=90&flip=yes...)
Es können auch andere Verfahren zum Übertragen der Gestaltungsmanipulationen des Benutzers verwendet werden, so beispielsweise unter Verwendung einer Maske im HTML-Stil oder durch Schreiben der Informationen in ein Cookie und anschließendes Neulesen der Informationen. Alternativ können die Hypertexttransferprotokollbefehle HTTP „POST" und HTTP „GET" verwendet werden, um Daten von der Benutzersitzung an den Server weiterzuleiten. HTTP „POST" arbeitet genauso wie ein Standardwebseitenformular, während HTTP „GET" mittels Ändern der URL arbeitet. So kann HTTP „GET" beispielsweise eine URL ändern, um eine Drehung, Skalierung sowie andere Auswahloptionen zu übertragen, was dann folgendermaßen aussieht:
http://www.personalcard.net/saveinfo.aspx?
rotate=90&flip=no&scale=232&x=232&y=12&y2=343&x2=333 usw.
Die vorstehende Liste von Techniken zur Übertragung der Manipulationsergebnisse ist nicht erschöpfend. Alternative und zukünftig noch entwickelte Techniken sind ebenfalls geeignet.
Der Kundenidentifizierer kann entsprechend einem Ausführungsbeispiel der Erfindung unter Verwendung eines Sitzungszustandes (session state; Sitzungsobjekt des Webservers) oder durch Weiterleiten als Teil des „Abfragestrings" weitergeleitet werden. HTML-Masken (HTML forms) können demselben Zweck dienen.
Entsprechend einem Ausführungsbeispiel der Erfindung kann ein Bild als JPEG, GIF, BitMap, PNG, Tiff und dergleichen hochgeladen werden, wobei jedoch einsichtig sein sollte, dass nahezu jedes digitale Bild hochgeladen oder ausgegeben werden kann. Von dem ursprünglich hochgeladenen Bild erstellt das System vier separate Versionen:

1. eine Thumbnail-Version (als JPEG), siehe Bildschirmmomentaufnahmen der Schnittstelle unten. Das Bild weist ungefähr eine Größe von 1 bis 2k auf;
2. eine größere, aber immer noch webtaugliche Version (die derart skaliert ist, dass eine Vergrößerung auf ein Maximum erfolgen kann, mit dem die Schnittstelle noch umgehen kann, so beispielsweise eine Skalierung von 250%, wobei dann immer noch eine 1:1-Pixelentsprechung vorhanden ist (so beispielsweise eine Bildgröße mit einer Breite von 241 × 250%, falls möglich). Es ist dies das Bild, das auf dem Bildschirm für die Gestaltung der Karte verwendet wird;
3. ein Bitmapbild im selben Maßstab wie das ursprüngliche Bild. Ein Bitmapbild kann beispielsweise in einem System verwendet werden, das C# verwendet, das eine Sprache von Microsoft ist und Bitmap als Standardbildtyp einsetzt.
4. die Ausgabegestaltung, die in Proportion zur Kreditkarte größenangepasst werden kann. Diese Gestaltung kann ein beliebiges Softwareformat sein, das für den eingesetzten Drucker verwendet werden kann, so beispielsweise BMP (Bitmap) oder PNG (Portable Network Graphic).

Die ursprünglichen Bilder können in eine Datenbank verbracht werden, sobald sie hochgeladen sind. Bei einem Ausführungsbeispiel erfordert jede Anforderung von Bildern einen Rückgriff auf die ursprüngliche Version zum Zwecke der Verwendung. Dies muss jedoch nicht der Fall sein, da, sobald eine weitere Bildversion erzeugt worden ist (beispielsweise eine Thumbnail-Version), das System diese Version gleichermaßen speichern kann, wodurch die Verarbeitung vereinfacht wird (obwohl der belegte Speicher zunimmt). Der Hauptvorteil eines Ausführungsbeispieles entsprechend der Erfindung liegt darin, dass ein Hin- und Herleiten des größten Bildes durch das Netz vom Client zum Server mit Ausnahme des anfänglichen Hochladens der Bilder nicht notwendig ist. Gleichwohl wird, wenn die fertige bearbeitete Gestaltung oder das Bild erzeugt wird, das Bild mit der höchsten Qualität verwendet.
Bei einem Ausführungsbeispiel der Erfindung gestaltet der Benutzer am Bildschirm ein Bild, das dieselbe physische Größe wie eine Kreditkarte aufweist, und zwar unter Verwendung einer Bildschirmauflösung von 72 dpi. Dies rührt daher, dass ein Computermonitor Bilder nicht mit einer höheren Auflösung als dieser darstellen kann.
Gleichwohl kann ein Drucker eine Ausgabe bei höheren Auflösungen, üblicherweise 300 dpi oder mehr vornehmen, was die Qualität erhöht. Obwohl die Front-End-Software Bilder mit niedriger Auflösung verwendet, wird die fertige Gestaltung von der Back-End-Software unter Verwendung einer Bitmapversion im vollen Maßstab des ursprünglich hochgeladenen Bildes zusammengestellt. Dies kann innerhalb der Back-End-Software unter Verwendung eines „virtuellen Bildschirms" (virtual canvas) erreicht werden, der größer als der Gestaltungsbildschirm (design canvas) innerhalb der Front-End-Software ist. Damit wird die von der Back-End-Software erzeugte Gestaltung auf einen Hintergrund größerer Größe als bei der Front-End-Software gelegt (wobei eine Auflösung von 72 dpi erhalten bleibt). Beträgt die Größe der Kreditkarte in Pixeln gleich 241 mal 153, so kann durch das Legen des Bildes auf einen „virtuellen Bildschirm" der Kreditkarte von 1050 auf 672 bei 72 dpi die Auflösung auf annähernd 300 dpi gesteigert werden, wenn die Kreditkarte schließlich gedruckt wird (und zwar wieder mit 3,3 auf 2,1 Inch). Dieses Verfahren stellt sicher, dass die maximal verfügbare dpi-Auflösung (gemäß Maximaleinstellung des Druckers) von der Back-End-Software ausgegeben wird, jedoch nur die notwendige Auflösung an die Front-End-Software gesendet wird. Dies verringert die Anforderungen an den Speicher des Client-Rechners und den Internetverkehr. Dieser Vorgang kann gleichermaßen durch Ändern der Auflösung von einem 72-dpi-Bild auf 300 bei ursprünglicher Größe erreicht werden.
Um Transparenzen einzusetzen, müssen bei einem Ausführungsbeispiel der Erfindung Bilder, die eine transparente Schicht (üblicherweise Rahmen oder Berandungselemente) enthalten, selbst in Flash-Movies umgewandelt werden. Dieser Prozess kann manuell vorgenommen werden, kann jedoch auch automatisiert werden, sodass Bilder mit Transparenzen (so beispielsweise Bitmaps oder PNG) in die Front-End-Software en passant geladen werden können. Die Back-End-Software kann das ursprüngliche PNG- oder BMP-Bild verwenden, um das Kreditkartenbild zu erzeugen.
3 bis 10 zeigen Bildschirme einer Kreditkartengestaltungswebseite, bei der eine Abfolge von Schritten entsprechend einem Ausführungsbeispiel der Erfindung vorgenommen wird. 3 zeigt einen ersten Bildschirm, wo eine Standardbibliothek von Bildern dem bestimmten Kartenausgeber, der die Kreditkartengestaltungswebseite benutzt, auf der linken Seite des Bildschirms zugeordnet wird. 4 zeigt einen Bildschirm, der Benutzer in die Lage versetzt, sich einzuloggen, sodass sie neue Bilder in die Bibliothek auf der linken Seite laden können. Dies kann bei Live-Versionen automatisiert werden. In 5 versetzt das Hochladen den Benutzer in die Lage, seinen oder ihren Rechner nach Bildern zum Hochladen zu durchsuchen. 6 zeigt einen Bildschirm mit einer neuen Bibliothek, die sowohl die Bilder des Benutzers wie auch einen Satz von Repertoirebildern enthält. In dem Bildschirm von 7 wird durch Anklicken des Thumbnail-Bildes auf der linken Seite das größere, jedoch immer noch optimierte Bild geladen. Nunmehr kann es skaliert, gekippt, bewegt oder anderen Manipulationen unterzogen werden. Einzelheiten der Karte können sichtbar gemacht oder versteckt werden. In dem Bildschirm von 8 können Frames hinzugefügt werden. Es handelt sich hierbei um Flash-Dateien (.swf), die Transparenzen zulassen. Auch diese können wiederum gekippt, skaliert, gedreht oder anderen Manipulationen unterzogen werden, wobei Einzelheiten der Karte verborgen werden können. In dem Bildschirm von 9 kann der Benutzer durch Klicken auf den roten Zurück-Knopf oder den Schritt-1-Reiter zu einem vorherigen Bildschirm zurückkehren. An diesem Punkt wird das Bild „live" dargestellt, aber der Rahmen kann ebenfalls sichtbar sein. Der Bildschirm von 10 zeigt die endgültige Version der Kreditkarte, bevor diese an die Back-End-Software zur Gestaltung gesendet wird.
Entsprechend einem weiteren Ausführungsbeispiel der Erfindung muss, wie in 12 gezeigt ist, eine Bank oder ein anderer Kartenausgeber keinen eindeutigen Identifizierer für einen Kunden erzeugen und diesen Identifizierer durch das System des Kartenausgebers leiten. Angesichts der Komplexität von Bankzahlungsverkehrssystemen kann der Verzicht auf die Notwendigkeit, einen derartigen Identifizierer zu gestalten, ein Vorteil sein.
Bevor die Alternative von 12 dargestellt wird, wird zunächst das Ausführungsbeispiel von 11 beschrieben, das für bestimmte Kartenausgeber von Nutzen sein kann, wobei hier ein eindeutiger Identifizierer für jeden Kunden erstellt wird. Bei diesem Ausführungsbeispiel wird ein eindeutiger Identifizierer für jeden Kunden erstellt, der das Gestalten einer Karte, siehe 1101, anfordert, und, siehe 1102, an den Back-End-Server 1103 weiterleitet. Der Back-End-Server 1103 gestaltet ein Bild entsprechend dem eindeutigen Identifizierer des Kunden, woraufhin der Kartenausgeber 1104 den eindeutigen Identifizierer durch das System des Kartenausgebers leitet. Eine Firma 1105, die die fertige Karte erzeugt, kann anschließend einen Softwareabruf bei dem Back-End-Server 1103 unter Verwendung des eindeutigen Identifizierers vornehmen, damit die von dem Kartenausgeber 1104 empfangenen Kontodetails dem Bild zugeordnet werden können.
Im Detail funktioniert das Ausführungsbeispiel von 11 folgendermaßen. Sucht ein. Kunde bei einem Kartenausgeber 1104 um die Gestaltung einer personalisierten Karte 1101 nach, so erstellt der Kartenausgeber 1104 einen eindeutigen Identifizierer und leitet den Identifizierer 1102 an den Back-End-Server 1103 weiter. Sobald der Kunde die Karte gestaltet, siehe 1106, werden der Benutzer und der entsprechende eindeutige Identifizierer an den Kartenausgeber ausgegeben, siehe 1107, und der Back-End-Server speichert das Kundenbild und den eindeutigen Identifizierer, siehe 1125. Die Information dahingehend, dass der Kunde eine neue Karte angefordert hat, wird anschließend zusammen mit dem eindeutigen Identifizierer an die Systeme des Kartenausgebers gesendet, siehe 1108, woraufhin eine Aufzeichnung und der eindeutige Identifizierer für den Kunden in den Systemen des Kartenausgebers gespeichert werden, siehe 1109. Der Kartenausgeber leitet anschließend den eindeutigen Identifizierer an den Back-End-Server weiter, siehe 1110, um mitzuteilen, dass gegebenenfalls eine neue Karte gestaltet und gepresst wird. Der Back-End-Server 1103 und/oder der Kartenausgeber 1104 können anschließend eine Bildprüfprozedur 1111 und 1112 ausführen, um sicherzustellen, dass das von dem Kunden erzeugte Bild für die Erzeugung annehmbar ist. Fällt das Bild durch die Prüfung des Back-End-Servers, siehe 1111, so werden der eindeutige Identifizierer und ein Grund für die Zurückweisung des Bildes anschließend an den Kartenausgeber gesendet, siehe 1113, und der Kunde wird aufgefordert, die Karte neuzugestalten, siehe 1114. Sobald das Bild angenommen worden ist, wandelt der Kartenausgeber die Aufzeichnung der Karte und den eindeutigen Identifizierer in eine Pressaufzeichnung um, siehe 1115, die an die die Karte erstellende Firma 1105 gesendet wird, siehe 1116. Der Back-End-Server kennzeichnet das Bild zum Senden an die Firma 1105 in der nächsten Bildercharge, siehe 1117. Sobald eine geeignete Anzahl von Bildern bereitsteht, sendet er das Bild und den zugeordneten eindeutigen Identifizierer an die Firma 1105, siehe 1118. Die Firma 1105 speichert, siehe 1119, als Nächstes die dem Kunden zu eigene Pressaufzeichnung und den eindeutigen Identifizierer gemäß Ermittlung von dem Kartenausgeber 1104 und speichert, siehe 1120, zudem den eindeutigen Identifizierer und das von dem Back-End-Server 1103 erhaltene Bild. Nachdem dies vollzogen ist, kann die Firma 1105 die fertige Karte erzeugen, indem zunächst die von dem Kartenausgeber 1104 bereitgestellte Aufzeichnung des Kunden ermittelt wird, siehe 1121, und zudem, siehe 1122, der eindeutige Identifizierer verwendet wird, um das zugeordnete Kundenbild zu ermitteln und es für einen Kartenrohlingsrepertoiredrucker bereitzustellen. Der Kartenrohlingsrepertoiredrucker kann anschließend das Bild auf einen vorgehaltenen Rohling drucken, siehe 1123, und den Magnetstreifen der Karte verschlüsseln. Auf Grundlage der Informationen auf dem Magnetstreifen können die Pressaufzeichnung und das Druckkartenrepertoire anschließend zusammengeführt werden, siehe 1124, um eine fertige Karte zu erzeugen.
Im Gegensatz zu dem Prozess von 11 versetzt das Ausführungsbeispiel von 12 einen Kartenausgeber in die Lage, die Notwendigkeit der Erstellung eines eindeutigen Identifizierers, der dann durch das System des Kartenausgebers geleitet wird, für jeden Kunden zu vermeiden. Anstelle dessen erzeugt der Kartenausgeber einen „Hash-Wert", so beispielsweise eine Nachrichtenübersicht oder einen anderen Ein-Weg-Code auf Grundlage einiger Kontodetails für jeden Einzelnen, damit der Kartenausgeber die Kontoinformationen des Kunden an den Back-End-Server auf vollständig sichere Weise weiterleiten kann. Wie in 12 gezeigt ist, ist der Prozess ähnlich zu demjenigen von 11, wobei ein Kartenausgeber 1204, ein Back-End-Server 1203 und eine Firma 1205 Schritte (1201 und folgende) analog zu denjenigen von 11 (1101 und folgende) ausführen. Gleichwohl besteht der Hauptunterschied in Schritten 1202, 1207, 1210, 1213, 1226 und 1227 von 12 darin, dass ein „Hash-Wert" (oder ein anderer Ein-Weg-Code) zwischen dem Kartenausgeber 1204 und dem Back-End-Server 1203 anstelle des Erfordernisses der Erstellung eines eindeutigen Identifizierers für jeden Kunden durch den Kartenausgeber, wie in 11 gezeigt ist, weitergeleitet wird. In Schritt 1202 wird zunächst ein Hash eines eindeutigen Teiles einer Kundenaufzeichnung (so beispielsweise des Namens des Kunden) erstellt. Ein Ein-Weg-Hash, so beispielsweise der MDH5-Hash, ist ein Prozess, der eine beliebige Größe aufweisende Eingabedaten (so beispielsweise den Namen und die Kontonummer des Kunden) empfängt und eine eine feste Größe aufweisende Ausgabe erzeugt, die Hash (oder Hash-Wert) genannt wird. Ein Hash hat die folgenden Eigenschaften: (i) Es sollte rechentechnisch machbar sein, eine weitere Eingabekette bzw. einen Eingabestring ausfindig zu machen, der denselben Hash-Wert erzeugt; und (ii) der Hash gibt nichts von der Eingabe, die zu dessen Erzeugung verwendet worden ist, preis. Dies bedeutet, dass die bei dem Ausführungsbeispiel von 12 verwendete Hash-Funktion den Kartenausgeber 1204 in die Lage versetzt, wenigstens einen Teil der Kundeninformationen an den Back-End-Server 1203 auf vollständig sichere Weise weiterzuleiten. Wie aus Schritten 1202, 1207, 1210, 1213, 1226 und 1227 ersichtlich ist, kann ein Hash-Wert zwischen dem Kartenausgeber 1204 und dem Back-End-Server 1203 hin und hergeleitet werden, ohne dass die Notwendigkeit der Erstellung eines eindeutigen Identifizierers für den Kartenausgeber 1204 und die Durchleitung des Identifizierers durch das System gegeben wäre.
Im Detail funktioniert das Ausführungsbeispiel von 12 folgendermaßen. Sucht ein Kunde bei einem Kartenausgeber 1204 um die Gestaltung einer personalisierten Karte 1201 nach, so erstellt der Kartenausgeber 1204 einen Hash-Wert eines eindeutigen Teiles der Kundenaufzeichnung 1202 und leitet den Hash-Wert 1226 an den Back-End-Server 1203 weiter. Sobald der Kunde die Karte 1206 gestaltet, werden der Benutzer und der entsprechende Hash-Wert an den Kartenausgeber ausgegeben, siehe 1207, und der Back-End-Server speichert, siehe 1225, das Kundenbild und den Hash-Wert. Die Information, dass der Kunde um eine neue Karte nachgesucht hat, wird anschließend an die Systeme des Kartenausgebers gesendet, siehe 1208, und es wird eine Aufzeichnung für den Kunden in den Systemen des Kartenausgebers gespeichert, siehe 1209. Der Kartenausgeber neuerstellt, siehe 1210, anschließend den Hash-Wert, der auf dem eindeutigen Teil der Kundenaufzeichnung basiert, und leitet, siehe 1227, ihn an den Back-End-Server 1203 weiter, um mitzuteilen, dass gegebenenfalls eine neue Karte gestaltet und gepresst wird. Der Back-End-Server 1203 und/oder der Kartenausgeber 1204 können anschließend eine Bildprüfprozedur 1211 und 1212 vornehmen, um sicherzustellen, dass das von dem Kunden gestaltete Bild mit Blick für die Herstellung annehmbar ist. Fällt das Bild durch die Prüfung des Back-End-Servers, siehe 1211, so werden der Hash-Wert und ein Grund für die Zurückweisung des Bildes an den Kartenausgeber gesendet, siehe 1213, und der Kunde wird aufgefordert, siehe 1214, die Karte erneut zu gestalten. Sobald das Bild angenommen ist, wandelt, siehe 1215, der Kartenausgeber die Kundenaufzeichnung in eine Pressaufzeichnung um, die an die Firma 1205, die die Karte erstellen wird, gesendet wird, siehe 1216. Der Back-End-Server kennzeichnet das Bild, siehe 1217, das an die Firma 1205 mit der nächsten Bildcharge gesendet werden soll. Steht eine geeignete Anzahl von Bildern bereit, so sendet, siehe 1218, er das Bild und den zugeordneten Hash-Wert an die Firma 1205. Die Firma 1205 speichert, siehe 1219, anschließend die von dem Kartenausgeber 1204 erhaltene Pressaufzeichnung des Kunden und speichert, siehe 1220, zudem den Hash-Wert und das Bild, die von dem Back-End-Server 1203 erhalten worden sind. Nachdem dies vollzogen ist, kann die Firma 1205 nunmehr die fertige Karte erstellen, indem zunächst die von dem Kartenausgeber 1204 bereitgestellte Aufzeichnung des Kunden ermittelt wird, siehe 1221, und zudem der Hash-Wert verwendet wird, siehe 1222, um das zugeordnete Kundenbild zu erhalten und es für einen Kartenrohlingsrepertoiredrucker bereitzustellen. Der Rohlingsrepertoiredrucker kann anschließend das Bild auf das Rohlingsrepertoire drucken, siehe 1223, und den Magnetstreifen der Karte verschlüsseln. Auf Grundlage der Informationen auf dem Magnetstreifen können die Pressaufzeichnung und das Druckkartenrepertoire anschließend zusammengeführt werden, siehe 1224, um die fertige Karte zu erstellen.
Bei einer Alternative zu dem Ausführungsbeispiel von 11 und 12, bei der ein eindeutiger Identifizierer beziehungsweise ein Hash-Wert zum Einsatz kommen, können andere Verfahren zur Erstellung eines sicheren Benutzeridentifizierers verwendet werden. So ist es beispielsweise ebenfalls möglich, dass die Benutzerinformationen bei dem Kartenausgeber zu Beginn des Prozesses verschlüsselt und bei der Kartenfirma entschlüsselt werden, und zwar unter Verwendung einer Verschlüsselungstechnik auf Basis eines privaten und eines öffentlichen Schlüssels oder eines privaten und eines weiteren privaten Schlüssels. Diese Alternative arbeitet auf eine Weise, die zu dem Prozess gemäß Beschreibung anhand von 12 ähnlich ist, wobei hier jedoch die Sicherheitsmaßnahmen modifiziert sind. So muss beispielsweise auch der Schlüssel von der Kartenfirma vorgehalten werden.
Bei einem weiteren Ausführungsbeispiel entsprechend der Erfindung kann ein sicherer Identifizierer des Bildes, der auf Grundlage der Anweisungen des Benutzers erzeugt worden ist, in das Bild selbst oder als Teil der Datendatei, in der das Bild gespeichert ist, eingebettet werden. So können beispielsweise ein Hash-Schlüssel, ein verschlüsselter Identifizierer oder ein anderer sicherer Identifizierer durch den Back-End-Server (so beispielsweise den Server 1103 oder 1203) in Zuordnung zu den Bildmanipulationsanweisungen des Benutzers weitergeleitet werden. An einem beliebigen Punkt in dem Back-End-Server-Prozess, so beispielsweise dann, wenn das Bild zum Senden an eine Kartenfirma (sobald beispielsweise die Kartenfirma 1205) bereitgestellt wird, kann das Bild anschließend derart manipuliert werden, dass der sichere Identifizierer dort eingebettet wird, so beispielsweise durch Einbetten eines Barcodes oder eines anderen maschinenlesbaren Codes, der den sicheren Identifizierer, der in dem Bild selbst angeordnet ist, verschlüsselt. Auf diese Weise kann die Kartenfirma 1215 den Barcode oder den anderen sicheren eingebetteten Identifizierer direkt aus dem Bild selbst ablesen und muss nicht beliebige Informationen von dem Back-End-Server 1203 außer dem Bild selbst, das den Barcode enthält, empfangen. Dieses Ausführungsbeispiel findet insbesondere in demjenigen Fall Anwendung, in dem der Kartenherstellungsprozess der Firma 1205 die Verwendung eines Bilddruckers beinhaltet, der nicht in der Lage ist, den sicheren Identifizierer getrennt zu speichern oder weiterzuleiten. Unter Verwendung des eingebetteten sicheren Identifizierers kann daher der Bilddrucker den sicheren Identifizierer wie auch das Bild zur Pressstufe effektiv weiterleiten, indem einfach das Bild selbst weitergeleitet wird, das den Barcode (oder den anderen eingebetteten maschinenlesbaren Identifizierer) enthält. Die Pressstufe kann anschließend das Lesen des Barcodes (oder des anderen eingebetteten maschinenlesbaren Identifizierers) aus dem Bild sowie das Nachschlagen der zugeordneten Pressaufzeichnung zur Verwendung bei der Erstellung der fertigen Karte beinhalten. Man beachte, dass die Bilddruckfunktion der Firma 1205 nicht innerhalb einer einzelnen Organisation oder Unternehmung wahrgenommen werden muss. Das Bilddrucken kann beispielsweise entsprechend einem Ausführungsbeispiel der Erfindung von einem eigenen Unternehmen oder einer eigenen Abteilung derjenigen Organisation, die das Pressen vornimmt, ausgeführt werden. Es ist einsichtig, dass eine Vielzahl von verschiedenen Techniken zum Einbetten des sicheren Identifizierers in das Bild verwendet werden kann, so beispielsweise durch Einbeziehen des Identifizierers in die Metadaten der Bilddatei, einschließlich derjenigen beiden Fälle, in denen die Bilddatei an die Firma 1205 gesendet wird oder wenn die Bilddatei von dem Back-End-Server oder der Firma verwendet wird.
Bei einem weiteren Ausführungsbeispiel entsprechend der Erfindung, das in 13 gezeigt ist, kann eine modifizierte Architektur im Zusammenhang mit einem Kartenausgabekiosk oder einem ladeninternen „Sofortausgabesystem" verwendet werden. Wie bei den vorbeschriebenen Ausführungsbeispielen laufen eine Front-End-Software auf einem clientseitigen Browser und eine Back-End-Software auf einem entfernten Webserver. Im Gegensatz zu den vorbeschriebenen Ausführungsbeispielen ist jedoch der Kartendrucker auf dem Client-Rechner (so beispielsweise am Kartenausgabekiosk) befindlich. Wie in 13 gezeigt ist, verwendet, siehe 1302, ein in dem ladeninternen Kiosk untergebrachter Browser die Front-End-Software, die von einem Internetserver 1301 bereitgestellt wird, um einen Kunden in die Lage zu versetzen, eine personalisierte Karte zu gestalten. Die Bildvorlieben des Benutzers werden anschließend gespeichert, und das Bild wird auf dem entfernten Server erzeugt, siehe 1303. Das Bild kann anschließend an dem Kiosk ausgegeben, siehe 1304, und auf die Karte des Kunden gedruckt werden, siehe 1305. Die Bilder können auf der entfernten Serverseite geprüft werden, um sicherzustellen, dass sie für das gegebenenfalls in Echtzeit erfolgende Drucken geeignet sind. Ansonsten ist der Betrieb des Systems ähnlich zu demjenigen bei den vorbeschriebenen Ausführungsbeispielen.
Bei einem weiteren Ausführungsbeispiel entsprechend der Erfindung kann, wie in 14 gezeigt ist, eine Datenbank zur Speicherung von Informationen zwischen den Bildauswahloptionen des Benutzers und der Back-End-Herstellung des Bildes eingesetzt werden. Auf diese Weise kann das System mengenflexibler gemacht werden, da die Gestaltung von Bildern auf der Back-End-Seite in Echtzeit nicht mehr notwendig ist. Wie bei den anderen Ausführungsbeispielen nimmt der Benutzer zunächst Bildauswahloptionen in der Front-End-Schnittstellen-Software vor, und die Bildmanipulationen werden an den Back-End-Server weitergeleitet, siehe 1401. Sodann werden sämtliche benutzerseitigen Manipulationen in einer Datenbank gespeichert, siehe 1402, sodass die Back-End-Software jede Manipulation, jedoch nicht in Echtzeit, aufnehmen und das hochauflösende Bild gestalten kann, siehe 1403.
Obwohl das Vorstehende anhand dessen, was derzeit als optimale Ausführung betrachtet wird, beschrieben worden ist, können andere Vorgehensweisen bei der Umsetzung der Erfindung, wo immer geeignet, eingesetzt werden, und die Erfindung soll nicht auf die spezifischen Ausgestaltungen der Vorrichtungen und Verfahrensschritte gemäß Offenbarung in der Beschreibung des bevorzugten Ausführungsbeispieles beschränkt sein. Fachleuten auf dem einschlägigen Gebiet erschließt sich, dass die Erfindung einen großen Anwendungsbereich hat und die Ausführungsbeispiele eine Vielzahl von Abwandlungen zulassen, ohne vom Schutzumfang gemäß Definition in den beigefügten Ansprüchen abzugehen.

Claims

Computersystem zur Manipulation von Bildern zur Anwendung bei bzw. Anbringung an personalisierten Finanztransaktionskarten, wobei das Computersystem umfasst: einen Bildspeicher (114, 253); einen Bildprozessor (110, 256); Mittel zum Erzeugen einer browserbasierten Benutzerschnittstelle (105, 254) zum Anzeigen, zur Manipulation an einem entfernten Endgerät, einer grafischen Darstellung (111, 115) zumindest eines Abschnitts eines ursprünglichen Bilds (107), das an dem Bildspeicher (114, 253) gehalten ist, wobei die browserbasierte Benutzerschnittstelle in der Lage ist, eine Mehrzahl von Manipulationen der grafischen Darstellung zu bewirken; einen Bildgrößenanpasser bzw. -Resizer (255), der angeordnet ist, um eine grafische Darstellung des ursprünglichen Bilds zu erzeugen, wobei die grafische Darstellung eine größenangepasste bzw. resizete Version des ursprünglichen Bilds derart umfasst, dass die grafische Darstellung zur Manipulation an dem entfernten Endgerät anzeigbar ist; eine Internet-Kommunikationsverbindung, die angeordnet ist, um die browserbasierte Benutzerschnittstelle mit dem Bildprozessor zu koppeln, wobei ein Benutzer an dem entfernten Endgerät die browserbasierte Benutzerschnittstelle verwenden kann, um ein ursprüngliches Bild hochzuladen, so dass dieses über die Internet-Kommunikationsverbindung an den Bildspeicher übertragen wird, und wobei die Verbindung wirksam ist, um Informationen über die Manipulationen zu erhalten, die an der grafischen Darstellung vorgenommen werden, und diese Informationen zwischen der browserbasierten Benutzerschnittstelle und dem Bildprozessor zu übertragen, und der Bildprozessor ist wirksam, um auf das an dem Bildspeicher gehaltene ursprüngliche Bild zuzugreifen, um Manipulationen vorzunehmen, die diejenigen emulieren, die an der grafischen Darstellung an dem entfernten Endgerät vorgenommen werden; und Mittel zum Kommunizieren einer Version des ursprünglichen Bilds, das die vorgenommenen Manipulationen umfasst, an ein Finanztransaktionskarten-Druckmittel (122, 257), das sicher von der browserbasierten Benutzerschnittstelle gehalten ist.
Computersystem gemäß Anspruch 1, bei dem das an dem Bildspeicher (114, 253) gehaltene Bild (107) eine relativ höhere Auflösung als die grafische Darstellung (111, 115) zumindest eines Abschnitts des Bilds (107) hat.
Computersystem gemäß Anspruch 1, das ferner Mittel zum Zuordnen eines eindeutigen Identifizierers (103) zu dem Benutzer umfasst, der die Manipulationen an der grafischen Darstellung (111, 115) vornimmt; wobei die Internet-Kommunikationsverbindung wirksam ist, um den eindeutigen Identifizierer (103) zwischen der Benutzerschnittstelle (105, 254) und dem Bildprozessor (110, 256) zu übertragen.
Computersystem gemäß Anspruch 1, bei dem der Bildprozessor (110, 256) Mittel zum Empfangen eines Hash-Werts umfasst, der sich auf den Benutzer bezieht, der die Manipulationen an der grafischen Darstellung (111, 115) vorgenommen hat.
Computersystem gemäß Anspruch 1, bei dem die browserbasierte Benutzerschnittstelle (105, 254) auf einem Kiosk präsentiert wird, der für einen Kunden bzw. Benutzer zugänglich ist.
Computersystem gemäß Anspruch 1, das ferner eine Datenbank umfasst, die in der Lage ist, Informationen über die an der grafischen Darstellung (111, 115) vorgenommenen Manipulationen zu speichern, so dass eine Manipulation an dem in dem Bildspeicher (114, 253) gehaltenen Bild anders als in Echtzeit vorgenommen werden kann, oder die alternativ erlaubt, dass Druckaufträge für unterschiedliche Artikel batchweise verarbeitet werden.
Verfahren zum Betreiben eines Computersystems zur Manipulation von Bildern, die an personalisierten Finanztransaktionskarten angewendet bzw. angebracht werden sollen, wobei das Verfahren umfasst: Bereitstellen einer Internet-Kommunikationsverbindung, die eine an einem entfernten Endgerät betätigbare browserbasierte Benutzerschnittstelle (105, 254) mit einem Bildprozessor (110, 256) des Computersystems koppelt; Empfangen eines ursprünglichen Bilds, das von einem Benutzer an der browserbasierten Benutzerschnittstelle des entfernten Endgeräts hochgeladen wird, und Übertragen des Bilds an einen Bildspeicher (114, 253) des Computersystems über die Internet-Kommunikationsverbindung; Erzeugen einer grafischen Darstellung von zumindest einem Abschnitt des ursprünglichen Bilds, wobei die grafische Darstellung eine größenangepasste bzw. resizete Version des ursprünglichen Bilds umfasst; Anzeigen der grafischen Darstellung zur Manipulation an der browserbasierten Benutzerschnittstelle, wobei eine Mehrzahl von Manipulationen der grafischen Darstellung unter Verwendung der browserbasierten Benutzerschnittstelle bewirkt wird; Übertragen von Informationen über Manipulationen, die an der grafischen Darstellung an dem entfernten Endgerät vorgenommen werden, zwischen der browserbasierten Benutzerschnittstelle und dem Bildprozessor über die Internet-Kommunikationsverbindung; Veranlassen, dass der Bildprozessor auf den Bildspeicher zugreift und an zumindest einem Abschnitt des ursprünglichen Bilds, das in dem Bildspeicher gehalten ist, Manipulationen vornimmt, die diejenigen emulieren, die an der grafischen Darstellung an dem entfernten Endgerät vorgenommen werden; und Veranlassen, dass der Bildprozessor eine Version des ursprünglichen Bilds, die bzw. das die vorgenommenen Manipulationen umfasst, an ein Finanztransaktionskarten-Druckmittel kommuniziert, das sicher von der browserbasierten Benutzerschnittstelle gehalten ist.
Verfahren gemäß Anspruch 7, das ferner umfasst: Übertragen eines eindeutigen Identifizierers (103) zwischen der Benutzerschnittstelle (105, 254) und dem Bildprozessor (110, 256), wobei der eindeutige Identifizierer (103) dem Benutzer zugeordnet ist, der die Manipulationen an der grafischen Darstellung (111, 115) vornimmt.
Verfahren gemäß Anspruch 7, das ferner umfasst: Empfangen eines Hash-Werts an dem Bildprozessor (110, 256), wobei sich der Hash-Wert auf den Benutzer bezieht, der die Manipulationen an der grafischen Darstellung (111, 115) vornimmt.
Verfahren gemäß Anspruch 7, das ferner umfasst: Präsentieren der browserbasierten Benutzerschnittstelle (105, 254) auf einem Kiosk, der für einen Kunden bzw. Benutzer zugänglich ist.
Verfahren gemäß Anspruch 7, das ferner umfasst: Speichern von Informationen über die an der grafischen Darstellung vorgenommenen Manipulationen in der Datenbank, so dass die Manipulationen an dem in dem Bildspeicher (114, 253) gehaltenen Bild (107) anders als in Echtzeit vorgenommen werden können, oder alternativ Erlauben, dass Druckaufträge für unterschiedliche Artikel batchweise verarbeitet werden.
Verfahren gemäß Anspruch 7, das ferner umfasst: Drucken eines Bilds, das durch Vornehmen der Manipulationen, die diejenigen emulieren, die an der grafischen Darstellung (111, 115) vorgenommen werden, auf eine Transaktionskarte.
Computerprogrammprodukt für die Personalisierung eines Bilds, das an einer Finanztransaktionskarte angewendet bzw. angebracht werden soll, das Programmcodemittel umfasst, wobei die Programmcodemittel enthalten: erste Codemittel zum Bereitstellen einer Internet-Kommunikationsverbindung, die eine Benutzerschnittstelle eines entfernten Endgeräts mit einem Bildprozessor (110, 256) des Computersystems koppelt; zweite Codemittel zum Empfangen eines ursprünglichen Bilds, das von einem Benutzer an dem entfernten Endgerät hochgeladen wird, und Übertragen des Bilds an einen Bildspeicher (114, 253) des Computersystems über die Internet-Kommunikationsverbindung; dritte Codemittel zum Erzeugen einer grafischen Darstellung von zumindest einem Abschnitt des Bilds, wobei die grafische Darstellung eine größenangepasste bzw. resizete Version des ursprünglichen Bilds umfasst; vierte Codemittel zum Anzeigen der grafischen Darstellung zur Manipulation an einer browserbasierten Benutzerschnittstelle, wobei die browserbasierte Benut zerschnittstelle wirksam ist, um einem Benutzer zu erlauben, eine Mehrzahl von Manipulationen der grafischen Darstellung zu bewirken; fünfte Codemittel zum Übertragen von Informationen über Manipulationen, die an der grafischen Darstellung an dem entfernten Endgerät vorgenommen werden, zwischen der browserbasierten Benutzerschnittstelle und dem Bildprozessor über die Internet-Kommunikationsverbindung; sechste Codemittel zum Veranlassen, dass der Bildprozessor auf den entfernten Bildspeicher zugreift und an zumindest einem Abschnitt des ursprünglichen Bilds, das in dem Bildspeicher gehalten ist, Manipulationen vornimmt, die diejenigen emulieren, die an der grafischen Darstellung an dem entfernten Endgerät vorgenommen werden; und siebte Codemittel zum Veranlassen, dass der Bildprozessor eine Version des ursprünglichen Bilds, die bzw. das die vorgenommenen Manipulationen umfasst, an ein Finanztransaktionskarten-Druckmittel kommuniziert, das sicher von der browserbasierten Benutzerschnittstelle gehalten ist.
System gemäß Anspruch 1, das ferner umfasst: einen Front-End-Server zum Präsentieren der Benutzerschnittstelle; und einen Back-End-Server (110), der den Bildprozessor (110, 256) umfasst, zum Kommunizieren mit dem Front-End-Server und mit dem Bildspeicher (114, 253).
System gemäß Anspruch 14, bei dem der Front-End-Server ferner Mittel zum Kommunizieren einer Benutzermanipulationsdatenkette bzw. -String an den Back-End-Server umfasst.
System gemäß Anspruch 1, bei dem die Benutzermanipulationen Vorgänge umfassen, die aus Drehen, Größenanpassen bzw. Resizen, Positionieren, Umdrehen bzw. Flippen, Steuern der Helligkeit, Reduzierung von roten Augen und Anpassen der Opazitätsstufen ausgewählt ist.
System gemäß Anspruch 1, bei dem Benutzermanipulationsdaten ferner Daten umfassen, die sich auf zumindest ein Bild (113) zum Überlagern auf das ursprüngliche Bild (107) beziehen.
System gemäß Anspruch 17, bei dem zumindest ein Bild (113) zum Überlagern einen transparenten Abschnitt umfasst.
System gemäß Anspruch 1, bei dem die browserbasierte Benutzerschnittstelle (105, 254) derart wirksam ist, dass ein Benutzer ein Bild, das ausgegeben werden soll, als aus einer oder mehreren repräsentativen Komponenten bestehend definieren kann, von denen jeweils die Position relativ zu einem Ursprung definiert ist und die basierend auf einem Satz vorbestimmter Regeln manipuliert werden können.
System gemäß Anspruch 1, bei dem die browserbasierte Benutzerschnittstelle (105, 254) eine Front-End-Softwre umfasst, die vollständig innerhalb eines Internetbrowsers wirksam ist.
System gemäß Anspruch 1, bei dem Instruktionen, die das Bild des abgeschlossenen Designs definieren, gleichzeitig in Form einer Textkette bzw. -String an den Bildprozessor (110, 256) gesendet werden.