DE10324539A1

DE10324539A1 - Verfahren und System zur Beauftragung und Durchführung von Druckdienstleistungen und postalischen Leistungen

Info

Publication number: DE10324539A1
Application number: DE10324539A
Authority: DE
Inventors: Jürgen Hofmann; Joachim Rick
Original assignee: Deutsche Post AG
Current assignee: Deutsche Post AG
Priority date: 2003-05-28
Filing date: 2003-05-28
Publication date: 2004-12-23
Also published as: AU2004245156A1; WO2004108429A2; EP1634229A2; WO2004108429A3; RU2005137401A; CN1795460A; US20070061224A1

Abstract

Die Erfindung betrifft ein Verfahren zur automatisierten Beauftragung und Durchführung von Druckdienstleistungen und postalischen Leistungen innerhalb eines Versanddienst-Systems (10), bei dem die Auftragsdaten für eine zu druckende und zu versendende Postsendung (40) an einer Auftragskomponente generiert werden. Das erfindungsgemäße Verfahren zeichnet sich dadurch aus, dass Auftragsdaten durch eine Auftragskomponente generiert werden, wobei die Auftragsdaten wenigstens aus einem Bildmotiv und Zustellinformationen bestehen. Die Auftragsdaten werden über eine Schnittstelle (30) an eine Datenbank (31) übermittelt und zur Aufbereitung der Auftragsdaten zu einem Druckauftrag einer Aufbereitungskomponente (70) übermittelt. Der erzeugte Druckauftrag wird einer Druckproduktion (50) übergeben, welche daraus eine Postsendung (40) erstellt. Die Postsendung (40) wird daraufhin einem Distributionssystem (90) übergeben und die Druckleitung und die postalische Leistung über eine Rechnungskomponente (91) abgerechnet. DOLLAR A Die Erfindung betrifft ferner ein System zur Durchführung des Verfahrens.

Description

Die Erfindung betrifft ein Verfahren zur automatisierten Beauftragung und Durchführung von Druckdienstleistungen und postalischen Leistungen innerhalb eines Versanddienst-Systems, bei dem die Auftragsdaten für eine zu druckende und zu versendende Postsendung an einer Auftragskomponente generiert werden.
Die Erfindung betrifft ferner ein System zur Durchführung eines Verfahrens zur automatisierten Beauftragung und Durchführung von Druckdienstleistungen und postalischen Leistungen innerhalb eines Versanddienst-Systems.

Innerhalb bekannter Systeme für Druckdienstleistungen in Kombination mit postalischen Dienstleistungen (Versanddienst-Systeme) treten zunehmend sogenannte hybride Mail-Dienste auf. Anbieter von derartigen Diensten ermöglichen es den Benutzern eines zugehörigen Systems, elektronische Daten für postalische Produkte wie Briefe, Postkarten, Mailings, etc. einzuliefern, woraufhin diese Daten aufbereitet und gegebenenfalls mit zusätzlichen Mehrwertdiensten versehen, in die physischen Endprodukte umgewandelt werden. Danach werden die adressierten Produkte zur Distribution einem Logistikprozess zugeführt.

Bei den adressierten Sendungen kann es sich beispielsweise um klassische Formen von Briefen, Postkarten oder elektronische Nachrichten in Form von E-Mails handeln. Derartige Sendungen werden in hohem Aufkommen insbesondere für Werbe- und/oder Informationskampagnen eingesetzt. Beispielsweise werden um fangreiche Mailingkampagnen dazu genutzt, neue Unternehmen bestimmten Bevölkerungsgruppen bekannt zu machen und Informationsbroschüren oder Kataloge zu verschicken. Ferner werden zu bestimmten Anlässen wie Sonderaktionen und -veranstaltungen Informationssendungen in erheblichem Umfang verschickt. Auch für Grußkartenaktionen zu Feiertagen wie Weihnachten eignen sich Mailingkampagnen verschiedenster Formen.

Typischerweise ist für einen Benutzer eines hybriden Mailingsystems die Teilnahme an dem Dienst jedoch mit vielen Einschränkungen und Hindernissen verbunden. Beispielsweise werden ihm Mindesteinlieferungsmengen vorgegeben, da die Produktion ansonsten für den Anbieter des Dienstes nicht wirtschaftlich ist. Auch die Abrechnung der jeweiligen Dienstleistung ist ohne Vorgabe von Mindesteinlieferungsmengen für den Anbieter unwirtschaftlich. Ferner muss für die Erstellung der elektronischen Daten herkömmlicherweise ein spezielles Hilfsmittel des Anwenders verwendet werden. Dabei handelt es sich häufig um eine spezielle Software, die in der Umgebung des Kunden installiert werden muss, um die Daten des Kunden so aufzubereiten, dass sie bei einem Druckauftrag an den Anbieter verarbeitet werden können. Bekannt ist auch die Verwendung von Konvertern im Bereich des Anbieters, um übermittelte Kundendaten produktionsgerecht aufbereiten zu können.

Die Erstellung eines Auftrags zum Drucken und Versenden einer einzelnen Postsendung, deren Gestaltung vom Benutzer gewählt werden kann, ist mit derartigen Systemen jedoch nicht möglich. Es besteht daher ein Bedarf nach einem Verfahren und einem System, das es einem Benutzer ermöglicht, einen Dienstleister beispielsweise mit dem personalisierten Druck einer einzelnen Postkarte und der anschließenden Versendung der Postkarte zu beauftragen.

Aufgabe der vorliegenden Erfindung ist es daher, ein Verfah ren zur Beauftragung und Durchführung von Druckdienstleistungen und postalischen Leistungen innerhalb eines Systems bereitzustellen, bei dem ein Benutzer mit geringem Aufwand an einer Auftragskomponente des Systems einen Auftrag für eine einzelne zu versendende Postsendung generieren kann, wobei die Gestaltung der Postsendung vom Benutzer zu einem hohen Grade frei wählbar ist.

Aufgabe der Erfindung ist es ferner, ein System zur Durchführung eines solchen Verfahrens zur Beauftragung und Durchführung von einzelnen Druckdienstleistungen und postalischen Leistungen bereitzustellen.

Diese Aufgabe wird erfindungsgemäß durch ein Verfahren zur automatisierten Beauftragung und Durchführung von Druckdienstleistungen und postalischen Leistungen innerhalb eines Versanddienst-Systems gelöst, bei dem die Auftragsdaten für eine zu druckende und zu versendende Postsendung an einer Auftragskomponente generiert werden, wobei das Verfahren durch folgende Schritte gekennzeichnet ist:

– Generierung von Auftragsdaten durch eine Auftragskomponente, wobei die Auftragsdaten wenigstens aus einem Bildmotiv und Zustellinformationen bestehen;
– Übermittlung der Auftragsdaten über eine Schnittstelle an eine Datenbank,
– Aufbereitung der Auftragsdaten zu einem Druckauftrag in einer mit der Datenbank in Verbindung stehenden Aufbereitungskomponente,
– Übermittlung des Druckauftrags an eine Druckproduktion,
– Erstellung einer Postsendung in der Druckproduktion,
– Übergabe der Postsendung an ein Distributionssystem, und
– Abrechnung der Druckleistung und der postalischen Leistung über eine Rechnungskomponente.

In einem besonders bevorzugten Ausführungsbeispiel der Erfindung handelt es sich bei der zu druckenden und zu versendenden Postsendung um eine Postkarte, welche typischerweise eine Motivseite und eine Textseite mit Grußtext, gegebenenfalls Werbung und Zustellinformationen umfasst. Es können auch andere Karten wie beispielsweise Grußkarten oder Klappkarten erzeugt werden. Bei der verwendeten Auftragskomponente kann es sich um verschiedene Mittel handeln. Vorteilhaft ist beispielsweise die Generierung eines Auftrags für eine zu druckende und zu versendende Postsendung über Applikationen einer Website mit einem zugehörigen Server. Als Website oder Webpage bezeichnet man ein im World Wide Web veröffentlichtes HTML-File. Die Website und der Server können dabei zu einem festen Versanddienst-System oder zu Zahlern gehören, welche flexibel an dem Versanddienst-System teilnehmen können. Unter Zahlern sind in diesem Zusammenhang Benutzer des Versanddienst-Systems zu verstehen, welche anderen Benutzern das Erzeugen und Versenden von Postsendungen ermöglichen, wobei die Kosten für die erbrachten Dienstleistungen teilweise oder vollständig vom Zahler übernommen werden. Diese Zahler melden sich vorzugsweise am Versanddienst-System an, wodurch sogenannte Sponsored Events mit bestimmten Eigenschaften wie der Dauer oder der Anzahl gesponserter Postsendungen erzeugt werden.

Ein festes Versanddienst-System zur Beauftragung und Durchführung von Druckdienstleistungen und postalischen Leistungen kann beispielsweise von einem Postunternehmen betrieben wer den und zur Automatisierung der Vorgänge verschiedene Komponenten aufweisen. Neben einer Auftragskomponente in Form einer Website und einem zugehörigen Server ist wenigstens eine Datenbank, eine mit dieser Datenbank in Verbindung stehende Aufbereitungskomponente zur Aufbereitung von Daten in Druckaufträge und geeignete Schnittstellen zur Übermittlung der Daten zweckmäßig. Erforderlich ist ferner eine Druckproduktion zur Erzeugung von Postsendungen und eine Rechnungskomponente zur Abrechnung erbrachter Druckleistungen und postalischer Leistungen. Diese Komponenten können fest in das Versanddienst-System integriert sein, oder wie es beispielsweise für die Druckproduktion vorteilhaft ist, aus dem System ausgelagert werden. So können verschiedene Druckdienstleister an das Versanddienst-System eines Postunternehmens angeschlossen sein, wodurch eine hohe Modularität und damit eine große Flexibilität erreicht wird. Die Möglichkeit, Aufträge mit der Losgröße eins zu drucken, hängt insbesondere mit dem Vorhandensein einer entsprechenden Druckproduktion zusammen, das in der Lage ist, die Aufträge zu größeren Aufträgen zu konsolidieren.

In einem besonders bevorzugten Ausführungsbeispiel der Erfindung stellt eine Rechnungskomponente die Druckleistung und die postalische Leistung für eine über das Versanddienst-System zu versendende Postsendung demjenigen Benutzer vollständig oder teilweise in Rechnung, welcher den Auftrag generiert hat. Diese Variante entspricht der üblichen Bezahlung einer in Anspruch genommenen Dienstleistung durch einen Auftraggeber. Es hat sich jedoch als vorteilhaft erwiesen, auch andere Abrechnungsvarianten zu ermöglichen. Beispielsweise kann es für Benutzergruppen eines Systems vorteilhaft sein, ihren Kunden das kostenlose oder preisvergünstigte Versenden von Postsendungen als Werbeaktion anzubieten. Bei einem derartigen Sponsoring kann ein Kunde so beispielsweise eine Postkarte auswählen und versenden, wobei die entstehenden Kosten teilweise oder vollständig dem jeweiligen Zahler in Rechnung gestellt werden. Die Rechnungskomponente stellt dabei die Druckleistung und die postalische Leistung einem Benutzer (Zahler) vollständig oder teilweise in Rechnung, welcher den Auftrag nicht generiert hat. Die Abrechnung der Leistungen erfolgt in einem besonders bevorzugten Ausführungsbeispiel der Erfindung vor dem Druck und dem Versand der Postsendung.

Neben der Erzeugung von Aufträgen für zu druckende und zu versendende Postsendungen über eine Website in Verbindung mit einem zugehörigen Server hat es sich weiterhin als vorteilhaft erwiesen, dass ein Benutzer einen Auftrag über ein mobiles Endgerät generieren kann und die Daten für einen Auftrag einer Schnittstelle des Versanddienst-Systems übermittelt werden. Zur Bereitstellung von Daten, welche diese Schnittstelle verarbeiten kann, kann es zweckmäßig sein, dass die von dem mobilen Endgerät übermittelten Daten beispielsweise in einer zweiten zwischengeschalteten Schnittstelle in ein Format konvertiert werden, welches von dem Versanddienst-System, beziehungsweise von der Datenbank und der zugehörigen Schnittstelle, verarbeitbar ist.

Die Generierung eines Auftrags für eine Postsendung wie eine Postkarte beinhaltet wenigstens die Angabe von Zustellinformationen und die Auswahl eines Motivs für die zu druckende Postkarte. Ferner wird durch den Benutzer typischerweise ein Grußtext angegeben. Dabei kann das Kartenmotiv vom Benutzer aus einer vorgegebenen Sammlung ausgewählt oder auf Benutzerseite erzeugt und von ihm bereitgestellt werden. Auswählbare Motive können beispielsweise durch das Versanddienst-System oder einen Zahler vorgegeben werden. Dabei ist es für den Zahler besonders vorteilhaft, dass er gewünschte Eigenschaften wie Werbeaussagen in die Motive integrieren kann. Insbesondere bei einer Ausführungsform, in welcher ein Auftrag auf einem mobilen Endgerät wie einem Mobiltelefon erzeugt wird, ist es für einen Benutzer vorteilhaft, dass er mit einer Funktion des Mobiltelefons aktuelle Bilder/Fotos erzeugen und diese in Form einer Postkarte versenden kann.

Erzeugt ein Benutzer einen Auftrag für eine zu druckende und zu versendende Postsendung über eine Website in Verbindung mit einem zugehörigen Server, sind dabei insbesondere bei der Integration von Zahlern verschiedene Untervarianten möglich. Die Auswahl der Motive und die Generierung der Aufträge kann beispielsweise vollständig auf der Website des Versanddienst-Systems oder vollständig auf einer Website eines Zahlers erfolgen, so dass der Zahler lediglich Aufträge an das Versanddienst-System übermittelt.

Die Darstellungen zur Begleichung von Dienstleistungen durch einen Zahler sind besonders bevorzugt, jedoch ist die Erfindung nicht auf Anwendungsfälle beschränkt, in denen ein Zahler in Erscheinung tritt. Die Erfindung ermöglicht eine flexible Abrechnung von Dienstleistungen, sodass die Funktion des Zahlers selbstverständlich auch von anderen Zahlern von Dienstleistungen übernommen werden kann. Die Erfindung nutzt eine einfache Abrechenbarkeit von postalischen Dienstleistungen und ist somit nicht auf einzelne Anwendungsfälle des Begleichens der Rechnungen beschränkt.

Eine Begleichung der Rechnungen kann beispielsweise über eine Übermittlung einer Teilnehmeridentifikationsnummer und den Abgleich mit einer die Teilnehmeridentifikationsnummer enthaltenden Datenbank und eine Abbuchung von einem der Nummer zugeordneten Benutzerkonto erfolgen.

In dieser Ausführungsform des Verfahrens, des Systems und der Vorrichtungen zur Durchführung der Erfindung ist der so identifizierte Teilnehmer der Zahler 60. Es ist jedoch gleichfalls möglich, dass die Funktion des Zahlers 60 durch einen Zahler übernommen wird.

Die Erfindung umfasst ferner ein System zur Durchführung eines Verfahrens zur automatisierten Beauftragung und Durchführung von Druckdienstleistungen und postalischen Leistungen, bei dem an einer Auftragskomponente ein Auftrag für eine zu druckende und zu versendende Postsendung generierbar ist.

Das System umfasst in einem besonders bevorzugten Ausführungsbeispiel der Erfindung wenigstens folgende Komponenten:

– eine Auftragskomponente zur Generierung von Auftragsdaten, wobei die Daten aus wenigstens einem Bildmotiv und Zustellinformationen bestehen,
– Mittel zur Übermittlung der Auftragsdaten von einer Auftragskomponente über eine Schnittstelle zu einer Datenbank,
– eine Aufbereitungskomponente in Verbindung mit der Datenbank zur Erzeugung von Druckaufträgen aus den Auftragsdaten,
– eine Druckproduktion in Verbindung mit der Datenbank zur Erzeugung der Postsendung,
– eine Rechnungskomponente in Verbindung mit der Datenbank zur Abrechnung der Druckleistung und der postalischen Leistung.

Weitere Vorteile, Besonderheiten und zweckmäßige Weiterbildungen der Erfindung ergeben sich aus den Unteransprüchen und der nachfolgenden Beschreibung bevorzugter Ausführungsbei spiele der Erfindung anhand von Zeichnungen.

Von den Zeichnungen zeigt
1 eine Darstellung eines besonders bevorzugten Ausführungsbeispiels des erfindungsgemäßen Versanddienst-Systems;
2 eine Darstellung einer zweiseitigen Druckversion einer mit dem erfindungsgemäßen Verfahren und System erzeugten Postkarte; und
3 den Verfahrensablauf bei der Generierung eines Auftrags für eine Postkarte über Applikationen einer Website.
1 zeigt ein besonders bevorzugtes Ausführungsbeispiel des erfindungsgemäßen Systems zur Beauftragung von Druckdienstleistungen und postalischen Leistungen. In der Darstellung ist ein System 10 dabei durch eine gestrichelte Linie gegen andere Komponenten abgegrenzt, um zu verdeutlichen, welche Komponenten zum Betrieb eines derartigen Systems vorteilhaft sind. Verschiedene Komponenten können jedoch auch ausgegliedert oder zusätzlich integriert werden. Das System wird im Folgenden als Versanddienst-System bezeichnet. Das Kernstück des Versanddienst-Systems 10 wird durch eine Datenbank 31 gebildet, welche zur Datenablage und zum Datenretrieval dient und in Verbindung mit verschiedenen Komponenten des Systems steht. Die gesamte Datenhaltung findet vorzugsweise in einer relationalen Datenbank statt. Als Datenbank hat sich beispielsweise eine Oracle-Datenbank als zweckmäßig erwiesen. Die Datenbank ist über eine Schnittstelle 30 mit wenigstens einer Auftragskomponente verbunden, an der ein Auftrag für eine zu druckende und zu versendende Postsendung generierbar ist. Die Datenbank steht ferner in Verbindung mit einer Aufbereitungskomponente 70 zur Erzeugung von Druckaufträgen und einer Druckproduktion 50, welcher die erzeugten Druckaufträge zur Erzeugung der Postsendungen übermittelt werden. Es hat sich als zweckmäßig erwiesen, als Schnittstelle 30 eine JDBC-Schnittstelle (Java Data Base Connectivity-Schnittstelle) zu verwenden. Das System umfasst ferner eine Rechnungskomponente 91 zur Abrechnung der vom System erbrachten Druckleistung und der postalischen Leistung.
Bei der dargestellten Auftragskomponente 20 handelt es sich um eine Website 21 mit einem zugehörigen systemseitigen Server 22. Über Applikationen dieser Website 21 kann ein Benutzer beispielsweise einen Auftrag für eine zu versendende Postkarte erzeugen, woraufhin der Auftrag über die Schnittstelle 30 der Datenbank 31 und den an diese angeschlossenen Komponenten übermittelt wird. Bei der Auftragskomponente kann es sich jedoch auch um ein mobiles Endgerät handeln, wie es in 1 beispielhaft als Mobiltelefon 80 dargestellt ist. Für die Erfindung ist es vorteilhaft, dass Benutzer des Versanddienst-Systems 10 auch über ein derartiges mobiles Endgerät Aufträge für Druckdienstleistungen und postalische Leistungen erzeugen können. Dabei können dem Benutzer über das Mobiltelefon Postkartenmotive zur Auswahl bereitgestellt werden. Besonders vorteilhaft ist es jedoch, wenn der Benutzer durch das Mobiltelefon erzeugte digitale Bilder als Motive für eine Postkarte auswählen kann.
Erzeugt ein Benutzer einen Auftrag über ein mobiles Endgerät 80, wird dieser Auftrag ebenfalls über die Schnittstelle 30 der Datenbank 31 übermittelt. Zur Konvertierung von Daten und/oder für zusätzliche Anwendungen kann zwischen der Schnittstelle 30 und dem mobilen Endgerät 80 eine zweite Schnittstelle 81 vorgesehen sein. Diese dient beispielsweise zur Umwandlung des Datenformats und/oder zur Adressprüfung.
Die Aufbereitungskomponente 70 umfasst wenigstens zwei Komponenten, welche hier als Backenddienste 71 und 72 bezeichnet werden. Eine dieser Komponenten dient der Erstellung des Bildmotivs, während die andere Komponente Preview- und Druckdaten erzeugt. Die Datenbank steht in Verbindung mit wenigstens einer Druckproduktion 50, welcher die durch die Backenddienste erzeugten Druckaufträge übermittelt werden. Die Druckproduktion kann fester Bestandteil des Versanddienst-Systems oder modular an das System anschließbar sein. Es kann sich dabei beispielsweise um einen oder mehrere Druckdienstleister handeln, welche im Auftrag des Systems Postsendungen drucken. Die Druckproduktion erzeugt mit den erhaltenen Daten eine Postsendung 40, die sie daraufhin einem Distributionssystem 90 übergibt. Das Distributionssystem kann verschiedene Sortier- und Verteilmittel zur Zustellung der Postsendung zu einem Empfänger aufgrund der vom Benutzer angegebenen Zustellinformationen umfassen. In einem bevorzugten Ausführungsbeispiel der Erfindung besteht zwischen der Druckproduktion 50 und der Rechnungskomponente 91 eine Verbindung, so dass eine Meldung über einen durchgeführten Druck und/oder Versand an die Rechnungskomponente ergehen kann.
In einem besonders bevorzugten Ausführungsbeispiel umfasst das System 10 wenigstens einen weiteren Benutzer des Systems, welcher im Folgenden als Zahler 60 bezeichnet wird. Der Zahler ist flexibel an das System angeschlossen und weist vorzugsweise eine Website 61 mit Applikationen und einem zugehörigen Server 62 auf.
Bei dem erfindungsgemäßen Verfahren wird über die Auftragskomponente ein Auftrag für eine Druckdienstleistung in Verbindung mit einer postalischen Leistung erzeugt. Es handelt sich vorzugsweise um einen Auftrag zum Versenden einer Postkarte. Dazu wählt ein Benutzer ein Motiv zum Druck der Post karte aus und gibt Zustellinformationen zum Versand der Karte an. Die Auswahl des Motivs kann auf verschiedene Arten erfolgen. Zum einen wird dem Benutzer vom System eine Auswahl an Motiven bereitgestellt, zwischen denen er wählen kann. Zum anderen kann es vorteilhaft sein, dass der Benutzer ein eigenes Motiv erzeugen und dem System 10 zusammen mit Zustellinformationen übermitteln kann.
Bei der dargestellten Auftragskomponente 20 handelt es sich in einem besonders bevorzugten Ausführungsbeispiel der Erfindung um eine Website 21 in Verbindung mit einem zugehörigen Server 22, welche der Benutzer beispielsweise an einem Computer aufruft. Die Verbindung zwischen dem Benutzer und der Website 21 und damit dem Server 22 wird vorzugsweise über das Internet hergestellt. Erzeugt der Benutzer über ein mobiles Endgerät 80 Aufträge für Druckdienstleistungen und postalische Leistungen, die vorzugsweise als MMS-Nachrichten (Multimedia Messaging Service) über smtp oder http in das System gelangen.
In einem besonders bevorzugten Ausführungsbeispiel der Erfindung handelt es sich bei den Aufträgen für Druckdienstleistungen und postalische Leistungen um Aufträge, bei denen für den Benutzer lediglich geringe oder keine Kosten anfallen. Die Kosten werden von einem Zahler 60 übernommen. Zum Beispiel kann es für einen Zahler sinnvoll sein, anderen Benutzern des Systems diesen gesponserten Service zu Werbezwecken zur Verfügung zu stellen. Benutzer können dann eine Website besuchen und über diese kostenlos oder preisermäßigt Postkarten verschicken. Bei der Website kann es sich um die Website 21 des Versanddienst-Systems oder die Website 61 des Zahlers handeln. Auch Untervarianten, bei welchen beispielsweise der Zahler zwar spezielle Kartenmotive zur Verfügung stellt, der Benutzer jedoch den Kartenpreis bezahlt, sind möglich.
Wünscht ein Zahler 60 die gesponserte Bereitstellung von Kartenmotiven über einen Bezahlungsweg, bei dem ein Benutzer einen Auftrag generieren kann, die Kosten für die Ausführung des Auftrags jedoch bei dem Zahler abgerechnet werden, meldet er beim Versanddienst-System eine Zahleringaktion an, die im Folgenden als Sponsored Event bezeichnet wird. Sponsored Events stellen Zahlungsaktionen mit bestimmten Attributen wie beispielsweise Start-, Enddatum und maximalen Obergrenzen dar. Maximale Obergrenzen können dadurch ergänzt werden, dass Perioden definiert werden, für welche diese Obergrenzen gelten. Beispielsweise kann eine Obergrenze „500 Karten pro Tag" lauten oder als globale Obergrenze „1000 Karten über den Gesamtzeitraum" definiert sein. Die Sponsored Events werden vorzugsweise in Tabellenform in der Datenbank 31 des Systems hinterlegt. Ein Sponsored Event ist immer genau einem Produkt und genau einem Zahler zugeordnet. Es hat sich als vorteilhaft erwiesen, dass ein Zahler beliebig viele Sponsored Events haben kann.
Die Datenbank 31 übernimmt innerhalb des Systems 10 wenigstens folgende Aufgaben:

– zentrale Vorhaltung von Datenlogiken und
– zentrale Datenhaltung.

Alle Applikationen des Systems verwalten ihre Daten zweckmäßigerweise über diese Datenbank. Unter dem Begriff „Applikation" versteht man üblicherweise jegliche Anwender-Programme oder umfangreiche Software-Pakete wie beispielsweise Datenbankanwendungen. Die Datenbank 31 verwaltet neben anderen Objekten zentrale Objekte wie Zahlern, Eventstatus und Motive. Weiterhin können alle Parametrisierungs- und Steuerungsdaten der Applikationen, sowie zum Teil sogar die Applikation selbst über die Datenbank verwaltet werden. Dabei dienen die verwendeten Tabellen nicht ausschließlich der Defini tion und Konfiguration des Sponsored Events, sondern Anwendungen schreiben auch aktiv in diese Tabelle. Beispielsweise kann die Anzahl der bereits verschickten Aufträge bzw. der dabei berechneten Geldbeträge erhöht werden, um bei Erreichen jeweiliger Obergrenzen das Event zu deaktivieren.
In einem besonders bevorzugten Ausführungsbeispiel der Erfindung enthält eine Tabelle für Sponsored Events wenigstens folgende Einträge:
Für den Zugriff auf eine derartige Tabelle hat sich eine Standard-API (Application Programming Interface: Schnittstelle für Anwendungsprogramme) als besonders zweckmäßig erwiesen, die Funktionen zum Hinzufügen, Modifizieren, Löschen und Suchen enthält. Zudem ist es vorteilhaft, wenn die API eine Funktion enthält, die feststellt, ob ein Sponsored Event aktiv, inaktiv, oder temporär inaktiv ist, beziehungsweise diese Status setzt, wenn Obergrenzen, Periodenanfänge oder Periodenenden erreicht sind.
Die Anzahl verschickter Postsendungen sowie die bereits verbuchten Beträge eines Sponsored Events können beispielsweise durch einen Trigger heraufgezählt werden. Der Trigger erhöht die Anzahl verschickter Sendungen, beziehungsweise den Betrag eines Events und prüft anschließend, ob die Obergrenzen noch unterschritten oder erreicht sind. Ist eine maximale Obergrenze erreicht, wird das Event deaktiviert.
Für Sponsored Events kommen verschiedene Ausführungsvarianten in Betracht. Für alle Varianten muss der Zahler 60 dem Versanddienst-System 10 die gewünschten Kartenmotive zur Verfügung stellen. Dabei können vom System gegebenenfalls bestimmte Anforderungen vorgegeben werden. Es hat sich als zweckmäßig erwiesen, das übermittelte Datenformat, die Dateigröße, die Farbwahl, die Auflösung und/oder die Endmaße vorzugeben. Beispielsweise kann das Kartenmotiv als TIFF-Datei, in CMYK-Farben, mit einer Auflösung von mindestens 350 dpi (Pixel/Inch) und einem Endmaß von 15,25 cm × 10,90 cm (eigentliches Postkartenformat 14,85 cm × 10,5 cm + Beschnitt) gefordert sein. Es kann dabei erforderlich sein, dass das System 10 das Motiv druckgerecht aufbereitet und in die systemeigene Datenbank einpflegt. Rohdaten werden dabei bespielsweise in das System 10 eingepflegt, während Feindaten in die Druckproduktion 50 eingepflegt werden.
In einer ersten Ausführungsvariante generiert ein Benutzer einen Auftrag für eine zu druckende und zu versendende Postsendung, indem er die Website 21 des Systems 10 betritt. Auf dieser Website können gesponserte und nicht gesponserte Motive angeboten sein. Die gesponserten Motive werden wie die nicht gesponserten, kostenpflichtigen Motive in der Motivauswahl angezeigt. Beim gesponserten Motiv kann zu Werbezwecken ein Hinweis auf den Zahler in Form eines Textes oder eines Logos angezeigt werden. Der Benutzer wählt ein Motiv aus und generiert zusammen mit Zustellinformationen den Auftrag, welcher der Datenbank 31 und den daran angeschlossenen Komponenten übermittelt wird.
Diese Ausführungsform ist für den Zahler 60 mit dem geringsten Aufwand verbunden. Er muss dem System 10 lediglich das Motiv zur Verfügung stellen. Der Benutzer kann die Website 21 entweder direkt betreten, oder der Zahler richtet auf seiner Website 61 und dem zugehörigen Server 62 einen Link zu der Website des Systems ein. Allerdings erlaubt diese Ausführungsform keine weitergehende Integration des Zahlers in das System 10. Außerdem kann jeder Benutzer der Website des Systems die gesponserten Motive sehen und kostenlos verschicken. Eine Einschränkung auf Benutzer, die vorher den Webauftritt des Zahlers besucht haben, ist so nicht möglich.
Bei einer zweiten Ausführungsform wählt ein Benutzer das Motiv der gewünschten Postkarte im Webauftritt 61 des Zahlers aus und versendet die Postkarte über das System 10. Die interne Motivwahl des Systems 10 ist in diesem Fall für den Benutzer nicht zugänglich. Diese Variante stellt sicher, dass der Benutzer den Webauftritt des Zahlers besucht haben muss, um eine kostenlose Postkarte zu verschicken. Der Benutzer wird dabei durch entsprechende Links einer Website eines Zahlers automatisch auf Applikationen einer Website des Versand dienst-Systems geleitet. Der Benutzer erzeugt über diese Applikationen einen Auftrag für eine zu druckende und zu versendende Postsendung, und der Server des Versanddienst-Systems übermittelt die Daten für einen Auftrag der Datenbank. Auf Seiten des Zahlers ergibt sich für diese Form ein etwas höherer Aufwand. Dies steht hauptsächlich im Zusammenhang mit dem Erfordernis, sicherzustsellen, dass der Benutzer das System 10 tatsächlich vom Webauftritt des Zahlers aus betritt. Die automatische Weiterleitung des Benutzers von der Website des Zahlers auf die Website des Versanddienst-Systems erfolgt dabei vorzugsweise über einen wechselseitigen Kommunikationsprozesses zwischen dem Server des Zahlers und dem Server des Versanddienst-Systems. Um sicherzustellen, dass ein Benutzer des Systems 10 vom Webauftritt eines Zahlers 60 kommt, hat sich folgendes Verfahren als besonders vorteilhaft erwiesen:
Der Zahler 60 ruft serverseitig über HTTPS (Hypertext Transfer Protocol, secure) eine spezielle Seite der Website 21 auf. Dies kann beispielsweise über ein ASP-, CGI- oder ein JSP-Programm erfolgen. Die Abkürzung ASP steht für „Active Server Pages". Dabei handelt es sich um aktive Internetseiten. Diese Seiten können beispielsweise Scripte enthalten, welche auf einem Server ausgeführt werden, bevor sie im Browser erscheinen. Die Bezeichnung CGI steht für "Common Gateway Interface" und ist eine Datenaustausch-Schnittstelle zwischen einem Web-Server und einem Client, der in der Lage ist, CGI-konforme Daten zu empfangen und diese unter Umständen auch weiterzubearbeiten und an den Server zurückzuschicken. Mit der Abkürzung JSP werden „Java Server Pages" bezeichnet. JSP-Seiten sind HTML-Files mit besonders gekennzeichneten eingebetteten Java-Programmen.
Die spezielle Seite der Website 21 ist geschützt, um zu verhindern, dass Dritte Karten auf Kosten des Zahlers ver schicken. Zum einen muss der Server 62 des Zahlers 60 sich gegenüber dem System 10 durch Übergabe eines für das jeweilige gesponserte Event eindeutigen Schlüssel identifizieren. Diese Identifikation (ID) wird vom System vorab mitgeteilt. Zum anderen stellt eine ACL (Access Control List) sicher, dass nur berechtigte IP-Adressen verschiedener Zahler zugreifen dürfen. Nur in dieser Liste definierte Rechner eines Netzwerks dürfen auf bestimmte Dienste des Netzwerks zugreifen. Seine IP-Adresse muss der jeweilige Zahler vorab mitteilen. Das System 10 schaltet sie dann frei. Noch höhere Sicherheit erreicht man durch den Einsatz von Client-Zertifikaten.
Als Antwort auf den Aufruf gibt das System eine Session-ID zurück. Diese Session-ID ist der Schlüssel für den Benutzer, um eine kostenlose Postkarte zu versenden. Das Programm auf dem Webserver 62 des Zahlers 60 wertet die Rückgabe aus und leitet den Benutzer auf die Website 21 des Systems weiter. Dies kann zweckmäßigerweise über einen Link oder Redirect geschehen. Das Ausfüllen und Versenden einer gewünschten Karte erfolgt über verschiedene Seiten des Webauftritts des Systems 10, wie sie bereits beschrieben wurden. Ergibt die Überprüfung, dass ein Benutzer die Website des Versanddienst-Systems nicht über die Website des Zahlers betreten hat, ist keine Generierung eines Auftrags möglich. Der Hauptaufwand für diese Ausführungsform liegt in der Implementierung des Protokolls für die Anfragen nach einer Session-ID.
In einem weiteren Ausführungsbeispiel der Erfindung ist es möglich, die zum Ausfüllen und Versenden der Karte erforderlichen Seiten des Versanddienst-Systems 10 individuell an den Webauftritt 61 eines Zahlers 60 anzupassen und optisch in den Auftritt des Zahlers zu integrieren. Auch hier wird zuerst eine Session-ID angefordert und der Benutzer anschliessend zur Website 20 des Systems 10 geleitet. Die Postkarten werden immer noch über das System 10 ausgefüllt und versendet, das Design der Oberfläche kann aber nahezu beliebig geändert werden. Statt der einzelnen Defaultseiten des Systems werden individuell angepasste Seiten des Zahlers angezeigt. Bis auf die Abfolge der Seiten und die auf den einzelnen Seiten zu übergebenden Parameter unterliegt das Design der Seiten dabei nahezu keinen Einschränkungen.
Diese vollständige Integration in den Webauftritt des Zahlers bedingt den höchsten Aufwand. Verschiedene HTML-Seiten müssen erstellt, überprüft und in das System integriert werden. Dazu müssen die Seiten an das System 10 übergeben werden. Dort werden sie vorzugsweise getestet und integriert.
Möchte der Zahler zum Beispiel eigene Editoren verwenden oder Karten automatisiert erstellen, kann er die Aufträge in einer weiteren Ausführungsform der Erfindung auch direkt serverseitig ohne jede Nutzerinteraktion einliefern. Der Zahler 60 nutzt dabei nicht die Seiten des Systems 10, sondern erstellt die erforderlichen Daten selbst und liefert diese dann serverseitig an den Server 22 des Systems 10, der die Daten entgegennimmt und die Karten verbucht. Der Auftrag für eine zu druckende und zu versendende Postsendung wird demnach auf der Website eines Zahlers generiert, und der zugehörige Server übermittelt die Daten für den Auftrag direkt dem Server des Versanddienst-Systems, welcher die Daten der Datenbank übermittelt.
Das Erfassen der Postkartendaten und das Einliefern der Daten in das System können dabei auch völlig asynchron erfolgen. Der Zahler 60 kann die Kartendaten beispielsweise in einer Datenbank sammeln und einmal am Tag im System einliefern.
Nutzt ein Zahler die Direkteinlieferung, benötigt er keine Session-ID, sondern kann in einem einzigen Aufruf direkt einliefern. Dabei übergibt er neben den Kartendaten auch einen ZahlerKey mit dem er im Versanddienst-System 10 identifiziert ist und das zu verwendende Sponsored Event bestimmt werden kann. Aus Gründen der Abwärtskompatibilität hat es sich als vorteilhaft erwiesen, dass bei dieser Direkteinlieferung statt eines ZahlerKey auch eine gesponserte SessionID akzeptiert wird, die zuvor angefordert wurde. Der Zugriff auf die Direkteinlieferung ist vorzugsweise ebenfalls über Webserver-ACL's geschützt, um das unberechtigte Verschicken von Karten auf Kosten des Zahlers zu verhindern. Noch höhere Sicherheit erreicht man durch den Einsatz von Client-Zertifikaten. Außerdem hat es sich als zweckmäßig erwiesen, dem Anrufer eine Methode zur Verfügung zu stellen, mit der er prüfen kann, ob sein Auftrag ordnungsgemäß akzeptiert wurde.
In einer weiteren Ausführungsform der Erfindung gibt der Zahler keine Auswahl eigener Motive vor, welche ein Benutzer kostenlos oder preisreduziert versenden kann, sondern der Benutzer kann ein eigenes Motiv erzeugen und dieses vom Zahler bezahlt versenden.
In 3 ist beispielhaft der Verfahrensablauf beim Generieren eines Auftrags für eine zu druckende und zu versendende Postkarte über Applikationen einer Website dargestellt. Der Vorgang startet auf einer Startseite, für welche eine Layoutvorlage erstellt wurde. Die Layoutvorlage für die Startseite und weitere Seiten können vom Versanddienst-System 10 festgelegt oder beispielsweise von einem Zahler frei gestaltet werden. Beim Aufruf der Website 21 des Versanddienst-Systems über einen Zahler werden dann nicht die Standardseiten des Versanddienst-Systems angezeigt, sondern die vom Zahler erstellten Seiten.
Auf der Startseite wird eine Liste der Namen aller aktiven Kategorien von Motiven in einer vorgegebenen Sortierung dargestellt. Bewegt der Nutzer den Mauszeiger über eine Kategorie, wird links der Kategorieliste (CategoriesList) das Zoom-Bild dieser Kategorie angezeigt. Initial wird vorzugsweise das Zoom-Bild der ersten Kategorie laut Sortierung angezeigt. Klickt der Nutzer auf eine Kategorie aus der Liste, wird eine Übersichtsseite für die Kategorie geöffnet. Auf der Startseite kann sich ferner ein Link befinden, welcher den Benutzer zu dem Zweig der Anwendung führt, in welcher er ein eigenes Motiv hochladen kann. Die daraufhin erscheinende Seite ist in 3 mit "Upload" bezeichnet. An dieser Stelle hat sich eine Motiv-API zum Auslesen der Kategorieinformationen als zweckmäßig erwiesen.
Die Seite "CategoriesList" zeigt eine Liste der Preview-Bilder aller aktiven Kategorien. Klickt der Nutzer ein Preview-Bild an, gelangt er zur Motivübersicht der gewählten Kategorie (CategorieView). An dieser Stelle hat sich ebenfalls eine Motiv-API zum Auslesen der Kategorieinformationen als zweckmäßig erwiesen.
Die Seite mit der Motivliste "CategorieView" zeigt die Previewbilder aller aktiven Motive in der gewählten Kategorie. Bei Klick auf ein Motiv gelangt der Nutzer zur Seite "MotifView". Auf dieser Seite wird zur Motivdetailansicht das Zoom-Bild des Motives angezeigt. Auf dieser Seite können schon vor dem späteren Bezahlvorgang vorab Preisinformationen zu einem gewählten Motiv angezeigt werden. Dies kann nur eine Information über die Nicht-Portobestandteile sein, da der Nutzer erst auf späteren Seiten entscheidet, wohin er seine Karte schicken wird und die Portoinformationen zu diesem Zeitpunkt daher noch nicht vorliegen. Zum Auslesen der Kategorie- und Bildinformationen ist eine Motiv-API und zur Er mittlung und Anzeige des Preises eine Pricing-API vorteilhaft.
Hat sich der Nutzer für die Verwendung eines eigenen Motiven entschieden, lädt er auf der Seite "Upload" sein Motiv hoch. Beispielsweise kann er über einen "Durchsuchen"-Button die zu verwendende Datei bestimmen. Ein "Weiter"-Button stößt den Upload an und sendet die Daten an "OwnMotifPreview", welche die Daten entgegennimmt und daraus das Vorschaubild erzeugt und ausliefert.
OwnMotifView nimmt die Bilddaten entgegen und prüft diese darauf, ob die Datei nicht größer ist als eine maximal zulässige Obergrenze. Ist die angegebene Datei größer als eine konfigurierte Obergrenze (MaxDenySize), ist von Missbrauchsversuchen auszugehen. Der Upload wird abgebrochen und zweckmäßigerweise eine Fehlermeldung zurückgeliefert.
Wurden die Daten entgegengenommen und keine Fehler detektiert, nimmt die Anwendung eine Vorabprüfung des Bildes vor. Dabei wird geprüft, ob:

– Das Bild einen gültigen JPG-Header hat.
– Der Dateiname auf .jpg oder .jpeg endet (caseinsensitiv).
– die DPI-Zahl nicht höher ist als die maximal zulässige (Obergrenze vorzugsweise konfigurierbar, Default ist z.B. 300)
– die Dateigröße nicht höher ist als die maximal zulässige. (Obergrenze ist vorzugsweise konfigurierbar, Default ist z.B. 300 KB)

Entspricht die Datei nicht den Anforderungen, kann eine Fehlerseite angezeigt werden. Ist die Datei korrekt, wird ein MOTIF_BUILDER-Task angelegt und die Datei als Task_File abge speichert. Der Task erzeugt aus dem JPG des Nutzers ein PreviewBild, das zeigt, wie das Bild auf der Postkarte positioniert wird und das Druck-PDF. Die Anwendung fragt in konfigurierbaren Abständen den Status des Tasks ab (Polling). Liegt das Ergebnis innerhalb eines konfigurierbaren Zeitraumes vor, wird die Vorschau-Seite mit dem Preview-Bild ausgeliefert. Das Preview-Bild hat bei nicht postkartenformatfüllenden Bildern einen weißen Rahmen und wird mit einem 1 Punkt starken Rahmen umfasst dargestellt, um bei nicht postkartenformatfüllenden Bildern die Positionierung zu verdeutlichen. Liegt das Taskergebnis nicht vor, oder ist ein Fehler aufgetreten, wird eine Fehlerseite angezeigt.
Dem Benutzer werden auf der Vorschauseite (OwnMotifView) Links zu einem HTML-Editor (EditHTML) und einem Java-Editor (EditJava) angeboten.
Auf der Seite "EditHTML" gibt der Nutzer seinen Postkartentext, die Anschriftsdaten und (optional) seine email-Adresse über ein HTML-Formular ein. Es werden die Buttons "Zurück", "Vorschau" und "Weiter" angeboten. "Zurück" führt je nachdem, ob der Nutzer ein eigenes oder ein StandardMotiv verwendet, zurück zu "MotifView" oder "OwnMotifView".
"Vorschau" bietet dem Benutzer die optionale Möglichkeit eines Vorschau-PDFs. Dieses wird in einem separaten Fenster (TextPreview) geöffnet. "Weiter" speichert die Daten des Benutzers und schickt sie an SendPostcard, welche einen Userjob anlegt.
Bei "Vorschau" und "Weiter" werden die Benutzereingaben vorzugsweise zunächst clientseitig mit JavaScript vorgeprüft. Dabei wird beispielsweise geprüft, ob eine angegebene email-Adresse RFC-konform ist und ob Adressdaten eingegeben wurden. Bei "Weiter" wird zusätzlich geprüft, ob die Allgemeinen Geschäftsbedingungen (AGB) bestätigt wurden. Wenn als Land Deutschland gewählt wurde, wird geprüft, ob Postleitzahl, Ort und mindestens zwei weitere Adressfelder ausgefüllt wurden, und ob die Postleitzahl beispielsweise für Deutschland fünfstellig und numerisch ist. Ist ein Fehler festgestellt worden, wird der Benutzer mit einer Alert-Box auf den Fehler hingewiesen. Sind alle Prüfungen erfolgreich bestanden, werden die Daten an eine spezielle (serverseitige) Interaktionssseite gesendet.
Bei "Vorschau" legt die Interaktionsseite einen Task an, der Duck-PDF und Vorschau-PDF erzeugt. Die Anwendung fragt in konfigurierbaren Abständen den Status des Tasks ab (Polling). Liegt das Ergebnis nicht innerhalb eines konfigurierbaren Zeitraumes vor, oder ist ein Fehler aufgetreten, wird eine Fehlerseite angezeigt. War der Task erfolgreich, wird das Preview-PDF in einem separaten Fenster (TextPreview) geöffnet.
Bei "Weiter" prüft die Interaktionsseite, ob schon aktuelle Vorschau- und Druck-PDFs vorliegen, die der Nutzer eventuell bereits über "Vorschau" erzeugt hat. Liegen aktuelle PDFs vor, werden diese verwendet; der Task muss nicht nochmals aufgerufen werden. Liegen noch keine PDFs vor oder hat der Benutzer seine Kartendaten gegenüber denen für die PDF-Erzeugung verwendeten geändert, wird ein Task angelegt, der die PDFs neu erzeugt. Anschließend werden die Daten an SendPostcard aufgerufen, die den Userjob anlegt.
Auf der Seite "EditJava" gibt der User Kartentext und Adressdaten über ein Javaapplet ein. Zusätzlich wird in das Applet der Hinweis über die Allgemeinen Geschäftsbedingungen aufgenommen. Das Applet sendet die Kartentext-Daten in einem speziellen XML-Format an den Server 22. Der Vorteil vom Applet ist, dass dem Benutzer eine WYSIWYG-Funktionalität ("What You See Is What You Get") für die Dateneingabe bereitgestellt werden kann.
Es werden die Buttons "Zurück", "Vorschau" und "Weiter" angeboten. "Zurück" führt je nachdem, ob der Nutzer ein eigenes oder ein Standard-Motiv verwendet, zurück zu "MotifView" oder "OwnMotifView".
"Vorschau" bietet dem Benutzer die optionale Möglichkeit eines Vorschau-PDF. Dieses wird in einem separaten Fenster (TextPreview) geöffnet. "Weiter" speichert die Daten des Benutzers und schickt sie an SendPostcard, welche den Userjob anlegt.
Bei "Vorschau" und "Weiter" werden die Benutzereingaben zunächst clientseitig mit JavaScript vorgeprüft. Die Überprüfung erfolgt dabei wie bei dem HTML-Editor.
Die angebotenen Schriftarten und Farben sind vorzugsweise konfigurierbar. Wählt der Benutzer keine Schriftart oder Farbe aus, hat es sich als zweckmäßig erwiesen, auf Default-Einstellung zurückzugreifen. Passt der eingegebene Kartentext nicht auf die dafür vorgesehene Fläche, erfolgt zweckmäßigerweise eine Warnung, das PDF wird jedoch erzeugt. Nicht mehr passender Text wird dabei abgeschnitten.
Die Seite "TextPreview" wird durch den "Vorschau"-Button auf EditJava und EditHTML aufgerufen. TextPreview wird als separates Fenster geöffnet, das lediglich das erzeugte Vorschau-PDF der Textseite und kein Layout enthält. Der Benutzer kann über Browserfunktionalitäten das PDF speichern oder drucken und das Fenster wieder schließen.
Hat der Nutzer seine Karte via EditHTML oder EditJava erstellt, werden die Auftragsdaten an SendPostcard gesendet. Bei SendPostcard handelt es sich um eine für den Benutzer nicht sichtbare Seite. Die Seite nimmt die Daten entgegen, prüft die Adressdaten und die AGB-Zustimmung zusätzlich zur bereits erfolgten clientseitigen Prüfung erneut (nach denselben Kriterien) und legt anschließend den Userjob an und führt die Ermittlung des Preises für die Postkarte durch. Waren diese erfolgreich, führt SendPostcard einen Redirect auf eine Rechnungskomponente 91 durch, über den die Bezahlung abgewickelt wird. Diese Rechnungskomponente wird im Folgenden als Billingserver bezeichnet.
Der Billingserver 91 ist zuständig für die Abwicklung der Bezahlung von Aufträgen. Der Billingserver kann dabei Module für eine unbeschränkte Anzahl von Zahlungssystemen aufnehmen. Auch wenn der Billingserver in 3 als separate Komponente dargestellt ist, wird er vorzugsweise nicht in Form einer separaten Anwendung oder Instanz betrieben, sondern ist ein integraler Teil des Frontendes und wird im Folgenden auch als Teil des Frontendes betrachtet.
Der Billingserver stellt fest, welche Zahlungsmethoden für einen Auftrag zur Verfügung stehen und bietet diese dem Benutzer für einen interaktiven Zahlungsvorgang an. Beispielsweise können Micro-Zahlungssysteme wie T-Pay, Firstgate, etc. zur Anwendung kommen.
Der Billingserver ist vorzugsweise so erweitert, dass der Bezahlvorgang für gesponserte Userjobs immer automatisch, ohne dass er durch den Benutzer angestoßen wird, geschieht. Gesponserte Jobs können dabei beispielsweise mit Bankeinzug bezahlt werden, wodurch vorausgesetzt wird, dass der Zahler eine aktive Bankverbindung besitzt. Wird ein Bezahlvorgang über einen Benutzer oder einen Zahler bestätigt, wird der Nutzer automatisch auf eine Bestätigungsseite (SendConfirmation) weitergeleitet.
Unabhängig davon, wie der Auftrag für eine zu druckende und zu versendende Postkarte generiert wurde, übergibt die Schnittstelle 30 die Daten für diesen Auftrag einer Aufbereitungskomponente 70. In einem besonders bevorzugten Ausführungsbeispiel der Erfindung umfasst die Aufbereitungskompo nente zwei sogenannte Backenddienste, welche die für die anschließende Druckproduktion 50 vorzugsweise benötigten PDF-Dateien sowie die Preview-Dateien erzeugen. Ein Backenddienst zur Bildmotiv-Erstellung 71 erzeugt Preview- und Druckdaten für das Motiv. Eine weitere Komponente zur Textvorlagen-Erstellung 72 erzeugt ein Druck- und Preview-PDF der Textseite. Die Druckdateien werden vorzugsweise als PDF-Dateien in einem speziellen Postkartenformat erzeugt, das beispielsweise einen zusätzlichen Rand besitzt, um so einen weißen Rand oder das Überschneiden mit anderen Motiven auf der resultierenden Postsendung zu vermeiden.
Im Folgenden wird beispielhaft die Aufbereitung und Konvertierung von Daten für die Produktion einer Postkarte beschrieben. Es hat sich dabei als zweckmäßig erwiesen, dass der Text für eine zu erzeugende Postkarte in drei Formaten eingeliefert werden kann: Plain-Text (einfacher Text), RTF (Rich Text Format) und XML (Extensible Markup Language).
Das XML-Format entspricht den Druckanweisungen, wie sie auf Seiten der Kartenproduktion vorzugsweise verarbeitet werden. Hiermit können einzeilige Textblöcke, Linien und Bilder millimetergenau positioniert werden. Daher erfolgt vorzugsweise eine Konvertierung in das XML-Format.
Das Format Plain-Text wird daher innerhalb der Aufbereitungskomponente 70 in ein XML-Format konvertiert, so dass ein zugehöriger Vorlagenerstellungs-Kern lediglich das XML-Format verarbeiten können muss. Das Format RTF wird ebenfalls durch ein Modul in XML konvertiert.
Das Plain Text-Format entspricht normalem, unformatiertem Text und wird vom Frontend geliefert, wenn der Text vom Benutzer in eine HTML-Auftragskomponente eingegeben wurde. Die Schriftart und -größe des gesamten Textes der Karte kann dabei vom Frontend übergeben werden. Bevorzugt ist dabei, dass der über eine Website oder ein mobiles Endgerät eingegebene Text von den Backend-Diensten der Aufbereitungskomponente zeilenweise positioniert wird. Ist eine Textzeile breiter als der Textbereich einer Postkarte, so wird dieser an einem geeigneten Leerzeichen umgebrochen.
Für das Motiv einer Postkarte wird vorzugsweise das Format JPG unterstützt. Enthält das JPG-Bild Angaben über dessen Auflösung (in dpi), ist es vorteilhaft, diese zu verwenden, um die reale Größe des Bildes (in mm) zu bestimmen. Liegen keine Angaben zur Auflösung vor, wird zweckmäßigerweise von einer Standardauflösung ausgegangen. Die Standardauflösung kann beispielsweise 96 dpi betragen.
Die zu druckenden Dokumente bestehen aus einer Produktions-Textseite 100 und einer Produktions-Motivseite 110, wie sie in 2 nebeneinander liegend dargestellt sind. Die Dokumente werden vorzugsweise als einseitige PDF-Dateien in einem speziellen Postkartenformat erzeugt, das einen zusätzlichen Rand besitzt, um so einen weißen Rand oder das Überschneiden mit anderen Motiven auf der resultierenden Postkarte zu vermeiden.
Die Produktions-Textseite 100 kann beispielsweise Elemente wie Kartentext 101, Zustellinformationen (Empfängeradresse) 102, Angaben zu Copyrights 103, ein Firmenlogo 104, einen Freimachungsvermerk oder eine Briefmarke 105, einen Vorausverfügungsvermerk 106 und/oder ein graphisches Element in Form eines senkrechten Striches 107 zur Aufteilung der Postkarte in zwei Bereiche enthalten. Das Layout dieser Seite kann fest vorgegeben werden, wobei bestimmte Parameter wie Ränder und Abstände zweckmäßigerweise konfigurierbar sind. Möchte der Benutzer beispielsweise eine eigene Logodatei hochladen, kann dies über einen entsprechenden Link geschehen.
In einem besonders bevorzugten Ausführungsbeispiel der Erfindung erzeugen die Backenddienste eine Produktions-PDF-Datei und optional eine Vorschau-PDF-Datei. Die Produktions-PDF-Datei enthält eine Seite, die vorzugsweise größer ist als eine normale Postkarte, auf welcher der gegebene Text positioniert ist.
Zusätzlich zu der Produktions-PDF-Datei können zwei verschiedene Vorschau-PDF-Dateien erzeugt werden:

– eine PDF-Datei mit einer Seite (DIN A6) bei der die Text-PDF-Datei über einer statischen PDF-Datei platziert ist, um dem Kunden einen Eindruck der entstehenden Postkarte zu geben.
– eine PDF-Datei auf einer Seite etwas größer als DIN A5, auf der die beiden Postkarten-Seiten (Bild und Text) untereinander angeordnet werden.

Schriftarten, die nicht Standardschriftarten des PDF-Formates sind und im TrueType-Format vorliegen, werden in die PDF-Datei eingebettet und können damit dem Drucker verfügbar gemacht werden.
Wird vom Benutzer des Systems ein eigenes Bildmotiv heraufgeladen, so wird eine PDF-Datei erzeugt, die das vom Kunden herauf geladene Bildmotiv enthält, das nach bestimmten Regeln positioniert wird. Wird ein Bild nicht in einem bestimmten Farbraum hochgeladen, kann es in den erforderlichen Farbraum konvertiert werden. Da der CMYK-Farbraum für den Druck von Postkarten bevorzugt wird, wird ein im RGB-Farbraum hochgeladenes Bild für das Produktions-PDF in den CMYK-Farbraum konvertiert. Für das erzeugte Vorschau-Bild (JPG) kann der RGB- Farbraum beibehalten werden, bzw. das Bild in den RGB-Farbraum konvertiert werden, falls CMYK hochgeladen wurde.
Die Backenddienste analysieren das vom Benutzer hochgeladene Bild und erzeugen daraus eine PDF-Datei für die Produktion und ein JPG-Bild für die Vorschau im Frontend. Die Skalierung/Positionierung wird nicht vom Backenddienst durchgeführt, sondern es wird mit entsprechenden Parametern (Breite, Höhe, Position) in die PDF-Datei eingebunden. Somit kann das Bild von einem RIP (Raster Image Processor) optimal berechnet werden. Das Bild für die Produktion wird vor der Platzierung in der PDF-Datei in das CMYK-Farbmodell konvertiert, um so ein optimales Druckergebnis zu erzielen.
Neben dem hochauflösenden Bild in der PDF-Seite wird ein JPG-Bild mit definierten Ausmaßen, zwecks Vorschau im Frontend, erzeugt. Dieses Bild besitzt einen weißen Hintergrund und entspricht im Layout der entstandenen PDF-Datei.
Die Aufbereitungskomponente 70 übergibt die durch die Backenddienste erzeugten Druckaufträge einer Druckproduktion 50, welche die Druckaufträge ausführt. Diese Druckproduktionskomponente ist vorzugsweise so ausgestaltet, dass sie unterschiedliche postalische Produkte erzeugen kann. So kann sie beispielsweise Postkarten oder Briefe drucken. Um möglichst flexibel die unterschiedlichsten Postprodukte erzeugen zu können, kann es dabei zweckmäßig sein, verschiedene Druckproduktionskomponenten an das System 10 anzuschließen und/oder in das System zu integrieren. So kann eine Druckproduktion beispielsweise jeweils ein bestimmtes postalisches Produkt erzeugen. Bei den Druckproduktionen kann es sich um systemeigene Komponenten oder um angeschlossene Druckdienstleister handeln, welche Druckaufträge entgegennehmen und diese nach Durchführung einem Distributionssystem 90 übergeben.
Für den Fall, dass der Benutzer ein Motiv für eine Postkarte aus einer vorgegebenen Sammlung auswählt, liegen diese Motive als vorgerippte PostScript-Dateien mit Schnittmarken auf einem lokalen Datenspeicher des Druckers. Die PostScript-Dateien haben beispielsweise das Format: 151,5 × 108 mm. Die Schnittmarken sind so ausgelegt, dass auf das Format 148,5 × 105 mm beschnitten wird. Für die Produktion benötigt die Druckproduktion 50 eine Referenz auf die lokal an der Druckmaschine vorgehaltenen Datei.
Für alle Text-Seiten gibt es vorgerippte PostScript-Dateien auf dem Collator. Diese Dateien beinhalten beispielsweise das Zahlerlogo, den Freimachungsvermerk und den senkrechten Strich in der Mitte. Alle weiteren Texte (Copyright, Textfeld, Adressfeld) befinden sich in einer PDF-Datei, die von den Backenddiensten erzeugt wurde. Die SDL (Service Data Line) ist eine eindeutige Nummerierung für Reprints und wird während der Produktion erzeugt.
Lädt der Benutzer eine eigene Bild-Datei hoch, um diese auf der Motivseite einzufügen, wird für die Produktion eine PDF-Datei benötigt, auf der sich das Bild befindet. Diese PDF-Datei wurde von einem Backenddienst erzeugt. Die Druckproduktion 50 fügt während der Produktion Schnittmarken ein. Die Erstellung der Textseite entspricht der bereits beschriebenen Erzeugung dieser Seite bei Auswahl von vorgegebenen Motiven durch einen Benutzer.
Das erfindungsgemäße Verfahren und das zugehörige System zur Durchführung des Verfahrens bringen verschiedene Vorteile mit sich. Zum einen ermöglicht es Benutzern des Systems, die Versendung von einzelnen Postsendungen in Auftrag zu geben, wobei die Benutzer die Postsendung in einem hohen Maße selbst gestalten können. Ein Benutzer kann nicht nur zwischen einer vorgegebenen Auswahl an Motiven wählen, sondern er kann auch eigene Bilder hochladen. Durch die bevorzugte Generierung von Aufträgen über Applikationen einer Website ist das Versenden von Postsendungen sehr einfach und erfordert keine speziell angepassten Zusatzkomponenten auf der Benutzerseite. Auch die Generierung von Aufträgen über ein mobiles Endgerät wie ein Mobiltelefon stellt eine komfortable und schnelle Möglichkeit dar, digitale Bilder zu erzeugen und diese beispielsweise als Postkarte zu versenden. Insbesondere für Zahler bieten sich durch die beschriebenen Ausführungsformen von Sponsored Events verschiedene Möglichkeiten, das gesponserte Versenden von Postkarten als Werbeaktion zu nutzen. Der erforderliche Aufwand für einen Zahlerauftritt kann dabei stufenweise vom Zahler bestimmt werden.

10: Versanddienst-System
20: Auftragskomponente, Frontend
21: Website Versanddienst-System
22: Server Versanddienst-System
30: Schnittstelle Frontend
40: Postalisches Produkt
50: Druckproduktion
60: Zahler
61: Website Sponsor
62: Server Sponsor
70: Aufbereitungskomponente, Backenddienste
71: Bildmotiv-Erstellung
72: Textvorlagen-Erstellung
80: Mobiles Endgerät
81: Schnittstelle Mobiles Endgerät
90: Distributionssystem
91: Rechnungskomponente/Billingserver
100: Textseite
101: Kartentext
102: Zustellinformationen
103: Angaben zu Copyrights
104: Firmenlogo
105: Freimachungsvermerk, Briefmarke
106: Vorausverfügungsvermerk
107: Graphische Elemente zur Postkartenaufteilung
108: Postkartenmotiv
110: Motivseite

Claims

Verfahren zur automatisierten Beauftragung und Durchführung von Druckdienstleistungen und postalischen Leistungen innerhalb eines Versanddienst-Systems (10), bei dem die Auftragsdaten für eine zu druckende und zu versendende Postsendung (40) an einer Auftragskomponente generiert werden, gekennzeichnet durch folgende Schritte: – Generierung von Auftragsdaten durch eine Auftragskomponente, wobei die Auftragsdaten wenigstens aus einem Bildmotiv und Zustellinformationen bestehen; – Übermittlung der Auftragsdaten über eine Schnittstelle (30) an eine Datenbank (31), – Aufbereitung der Auftragsdaten zu einem Druckauftrag in einer mit der Datenbank (30) in Verbindung stehenden Aufbereitungskomponente (70), – Übermittlung des Druckauftrags an eine Druckproduktion (50), – Erstellung einer Postsendung (40) in der Druckproduktion (50), – Übergabe der Postsendung (40) an ein Distributionssystem (90), und – Abrechnung der Druckleistung und der postalischen Leistung über eine Rechnungskomponente (91).
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Auftragskomponente einen Auftrag für eine zu druckende und zu versendende Postsendung dadurch generiert, dass ein Benutzer wenigstens ein Bildmotiv und Zustellinformationen angibt.
Verfahren nach einem oder beiden der Ansprüche 1 und 2, dadurch gekennzeichnet, dass es sich bei dem Bildmotiv für einen Auftrag um ein auf Benutzerseite erzeugtes Bild oder ein Bild aus einer ihm vorgegebenen Auswahl handelt.
Verfahren nach einem oder mehreren der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass es sich bei der zu druckenden und zu versendenden Postsendung (40) um eine Postkarte, Grußkarte und/oder Klappkarte handelt.
Verfahren nach einem oder mehreren der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Rechnungskomponente (91) die Druckleistung und die postalische Leistung einem Benutzer des Versanddienst-Systems (10) vollständig oder teilweise in Rechnung stellt, wobei dieser Benutzer den Auftrag für eine zu druckende und zu versendende Postsendung generiert hat.
Verfahren nach einem oder mehreren der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Rechnungskomponente (91) die Druckleistung und die postalische Leistung einem im Versanddienst-Systems (10) angemeldeten Benutzer (Zahler) (60) vollständig oder teilweise in Rechnung stellt, wobei dieser Benutzer den Auftrag für eine zu druckende und zu versendende Postsendung nicht generiert hat.
Verfahren nach einem oder mehreren der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die Abrechnung der Druckleistung und der postalischen Leistung über die Rechnungskomponente (91) vor dem Druck und Versand einer Postsendung (40) erfolgt.
Verfahren nach einem oder mehreren der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass der Auftrag für eine zu druckende und zu versendende Postsendung (40) über Applikationen einer Website in Verbindung mit einem zugehörigen Server generiert wird, und die Auftragsdaten über eine Schnittstelle (30) einer Datenbank (31) übermittelt werden.
Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass es sich bei der Website in Verbindung mit einem zugehörigen Server um eine Website (21) des Versanddienst-Systems (10) oder eine Website (61) eines Zahlers (60) handelt.
Verfahren nach einem oder beiden der Ansprüche 8 und 9, dadurch gekennzeichnet, dass der Benutzer durch entsprechende Links einer Website (61) eines Zahlers (60) automatisch auf Applikationen einer Website (21) des Versanddienst-Systems (10) geleitet wird, dass der Benutzer über diese Applikationen einen Auftrag für eine zu druckende und zu versendende Postsendung (40) erzeugt, und der Server (22) die Daten für einen Auftrag einer Datenbank (31) übermittelt.
Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass die automatische Weiterleitung des Benutzers von der Website (61) des Zahlers (60) auf die Website (21) des Versanddienst-Systems (10) über einen wechselseitigen Kommunikationsprozess zwischen dem Server (62) des Zahlers (60) und dem Server (22) des Versanddienst-Systems (10) erfolgt.
Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass der wechselseitige Kommunikationsprozess die Überprüfung umfasst, ob der Benutzer die Website (21) des Versanddienst-Systems (10) über die Website (61) der Zahlers (60) betreten hat.
Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass keine Generierung eines Auftrags möglich ist, falls die Überprüfung ergibt, dass der Benutzer die Website (21) des Versanddienst-Systems (10) nicht über die Website (61) des Zahlers (60) betreten hat.
Verfahren nach einem oder beiden der Ansprüche 8 und 9, dadurch gekennzeichnet, dass der Auftrag für eine zu druckende und zu versendende Postsendung (40) auf der Website (61) eines Zahlers (60) generiert wird, und der zugehörige Server (62) die Daten für den Auftrag dem Server (22) des Versanddienst-Systems (10) übermittelt, welcher die Daten der Datenbank (31) übermittelt.
Verfahren nach einem oder mehreren der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass der Auftrag für eine zu druckende und zu versendende Postsendung (40) über ein mobiles Endgerät (80) generiert wird und dass die Daten für einen Auftrag über eine Schnittstelle (30) einer Datenbank (31) übermittelt werden.
Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass die Daten für einen Auftrag der Schnittstelle (30) über eine zweite Schnittstelle (81) übermittelt werden.
Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass die zweite Schnittstelle (81) die Daten in ein Format konvertiert, welches von der Schnittstelle (30) verarbeitbar ist.
System zur Durchführung eines Verfahrens zur automatisierten Beauftragung und Durchführung von Druckdienstleistungen und postalischen Leistungen, bei dem an einer Auftragskomponente ein Auftrag für eine zu druckende und zu versendende Postsendung (40) durch einen Benutzer generierbar ist, dadurch gekennzeichnet, dass es zur Durchführung eines Verfahrens nach einem oder mehreren der Ansprüche 1 bis 17 geeignet ist.
System zur automatisierten Beauftragung und Durchführung von Druckdienstleistungen und postalischen Leistungen, bei dem an einer Auftragskomponente ein Auftrag für eine zu druckende und zu versendende Postsendung (40) durch einen Benutzer generierbar ist, dadurch gekennzeichnet, dass das System wenigstens folgende Komponenten umfasst – eine Auftragskomponente zur Generierung von Auftragsdaten, wobei die Daten aus wenigstens einem Bildmotiv und Zustellinformationen bestehen, – Mittel zur Übermittlung der Auftragsdaten von einer Auftragskomponente über eine Schnittstelle (30) zu einer Datenbank (31), – eine Aufbereitungskomponente (70) in Verbindung mit der Datenbank (31) zur Erzeugung von Druckaufträgen aus den Auftragsdaten, – eine Druckproduktion (50) in Verbindung mit der Datenbank (31) zur Erzeugung der Postsendung (40), – eine Rechnungskomponente (91) in Verbindung mit der Datenbank (31) zur Abrechnung der Druckleistung und der postalischen Leistung.
System nach Anspruch 19, dadurch gekennzeichnet, dass die Auftragskomponente durch eine Website und einen zugehörigen Server gebildet wird.
System nach Anspruch 20, dadurch gekennzeichnet, dass die Auftragskomponente durch ein mobiles Endgerät (80) gebildet wird.
System nach einem oder mehreren der Ansprüche 19 bis 21, dadurch gekennzeichnet, dass es sich bei der Schnittstelle (30) um eine http-Schnittstelle handelt.
System nach einem oder beiden der Ansprüche 21 und 22, dadurch gekennzeichnet, dass zur Übermittlung von Daten für einen Auftrag zwischen ein mobiles Endgerät (80) und eine Schnittstelle (30) eine zweite Schnittstelle (81) geschaltet ist, wobei die zweite Schnittstelle (81) so ausgestaltet ist, dass sie von dem mobilen Endgerät (80) empfangene Daten in ein Format konvertieren kann, welches von der Schnittstelle (30) verarbeitbar ist.