WO2004108429A2 - Verfahren und system zur beauftragung und durchführung von druckdienstleistungen und postalischen leistungen - Google Patents

Verfahren und system zur beauftragung und durchführung von druckdienstleistungen und postalischen leistungen Download PDF

Info

Publication number
WO2004108429A2
WO2004108429A2 PCT/DE2004/000893 DE2004000893W WO2004108429A2 WO 2004108429 A2 WO2004108429 A2 WO 2004108429A2 DE 2004000893 W DE2004000893 W DE 2004000893W WO 2004108429 A2 WO2004108429 A2 WO 2004108429A2
Authority
WO
WIPO (PCT)
Prior art keywords
order
user
data
website
component
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/DE2004/000893
Other languages
English (en)
French (fr)
Other versions
WO2004108429A3 (de
Inventor
Jürgen Hofmann
Joachim Rick
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Deutsche Post AG
Original Assignee
Deutsche Post AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Deutsche Post AG filed Critical Deutsche Post AG
Priority to AU2004245156A priority Critical patent/AU2004245156A1/en
Priority to EP04730195A priority patent/EP1634229A2/de
Priority to US10/559,488 priority patent/US20070061224A1/en
Publication of WO2004108429A2 publication Critical patent/WO2004108429A2/de
Publication of WO2004108429A3 publication Critical patent/WO2004108429A3/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Managing shopping lists, e.g. compiling or processing purchase lists
    • G06Q30/0635—Managing shopping lists, e.g. compiling or processing purchase lists replenishment orders; recurring orders
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00016—Relations between apparatus, e.g. franking machine at customer or apparatus at post office, in a franking system
    • G07B17/00024—Physical or organizational aspects of franking systems
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00016—Relations between apparatus, e.g. franking machine at customer or apparatus at post office, in a franking system
    • G07B17/00024—Physical or organizational aspects of franking systems
    • G07B2017/00072—Hybrid mail, i.e. mail delivered using different physical means along the mail delivery path, e.g. email and envelope

Definitions

  • the invention relates to a method for the automated commissioning and implementation of printing services and postal services within a shipping service system, in which the order data for a mail item to be printed and sent are generated on an order component.
  • the invention further relates to a system for carrying out a method for the automated commissioning and implementation of printing services and postal services within a shipping service system.
  • So-called hybrid mail services are increasingly occurring within known systems for printing services in combination with postal services (shipping service systems).
  • Providers of such services enable the users of an associated system to submit electronic data for postal products such as letters, postcards, mailings, etc., whereupon this data is processed and, if necessary, provided with additional value-added services, into which physical end products are converted. The addressed products are then sent to a logistics process for distribution.
  • the addressed items can be, for example, classic forms of letters, postcards or electronic messages in the form of emails.
  • Such programs are used in high volume, in particular for advertising and / or information campaigns. For example, extensive mailing campaigns are used to make new companies known to certain population groups and to send information brochures or catalogs. In addition, information programs are sent out to a considerable extent on certain occasions such as special promotions and events. Mailing campaigns of various forms are also suitable for greeting card campaigns for holidays such as Christmas.
  • Another object of the invention is to provide a system for carrying out such a method for the commissioning and implementation of individual printing services and postal services.
  • This object is achieved according to the invention by a method for the automated commissioning and implementation of printing services and postal services within a shipping service system, in which the order data for a mail item to be printed and sent is generated on an order component, the method being characterized by the following steps :
  • order data by an order component, the order data consisting of at least one image motif and delivery information
  • the postal item to be printed and sent is a postcard, which typically comprises a motif page and a text page with greeting text, possibly advertising and delivery information. Other cards such as greeting cards or folding cards can also be generated.
  • the order component used can be various means. For example, it is advantageous to generate an order for a mail item to be printed and sent via applications of a website with an associated server.
  • a website or webpage is an HTML file published on the World Wide Web.
  • the website and the server can belong to a fixed shipping service system or to payers who can flexibly participate in the shipping service system.
  • payers are to be understood as users of the shipping service system which enable other users to generate and send mail items, the costs for the services rendered being borne in part or in full by the payer.
  • These payers preferably register with the shipping service system, so that sponsored events with certain properties such as the duration or the number of sponsored mail items are generated.
  • a fixed shipping service system for ordering and performing printing services and postal services can be operated by a postal company, for example which and to automate the processes have different components.
  • a processing component connected to this database for processing data into print jobs and suitable interfaces for transmitting the data are useful.
  • Print production for the generation of mail items and an invoice component for the billing of print services and postal services performed are also required.
  • These components can be permanently integrated into the shipping service system, or, as is advantageous for print production, for example, be outsourced from the system.
  • various print service providers can be connected to the mail service system of a postal company, resulting in a high degree of modularity and thus great flexibility.
  • the ability to print batch size one jobs is particularly related to the existence of a print production facility that is able to consolidate the jobs into larger jobs.
  • an invoice component bills the printing service and the postal service for a mail item to be sent via the shipping service system in full or in part to the user who generated the order.
  • This variant corresponds to the usual payment for a service used by a client.
  • the invoice component bills the printing service and the postal service completely or partially for a user (payer) who did not generate the order.
  • the services are billed before the mail item is printed and sent.
  • a user can generate an order via a mobile terminal and the data for an order of an interface of the shipping service System are transmitted.
  • the data transmitted by the mobile terminal can be converted, for example in a second intermediate interface, into a format which is used by the shipping service system or by the database and the associated interface is processable.
  • the generation of an order for a mail item such as a postcard at least includes the specification of delivery information and the selection of a motif for the one to be printed
  • a greeting text is typically provided by the user.
  • the card motif can be selected by the user from a predefined collection or generated and provided by the user. Selectable motifs can be specified, for example, by the shipping service system or a payer. It is particularly advantageous for the payer that he can integrate desired properties such as advertising messages into the motifs. In particular in an embodiment in which an order is generated on a mobile terminal such as a mobile phone, it is advantageous for a user that he can generate current images / photos with a function of the mobile phone and send them in the form of a postcard.
  • a user creates an order for a mail item to be printed and sent via a website in conjunction with an associated server
  • various sub-variants are possible, in particular when integrating payers.
  • the selection of the motifs and the generation of the orders can, for example, be carried out entirely on the website of the shipping service system or entirely on a website of a payer, so that the payer only transmits orders to the shipping service system.
  • the representations for the payment of services by a payer are particularly preferred, but the invention is not restricted to use cases in which a payer appears.
  • the invention enables flexible billing of services, so that the function of the payer can of course also be taken over by other payers of services.
  • the invention uses simple billing of postal services and is therefore not restricted to individual use cases for settling the bills.
  • the invoices can be paid, for example, by transmitting a subscriber identification number and comparing it with a database containing the subscriber identification number and debiting a user account assigned to the number.
  • the subscriber identified in this way is the payer 60.
  • the function of the payer 60 it is likewise possible for the function of the payer 60 to be performed by a person Payer is taken over.
  • the invention further comprises a system for carrying out a method for automated commissioning and implementation of printing services and postal services, in which an order for a mail item to be printed and sent can be generated on an order component.
  • the system comprises at least the following components:
  • an order component for generating order data the data consisting of at least one image motif and delivery information
  • Fig. 1 is an illustration of a particularly preferred
  • FIG. 2 shows an illustration of a two-sided print version of a postcard generated with the method and system according to the invention.
  • Fig. 3 shows the process flow when generating an order for a postcard via applications of a website.
  • FIG. 1 shows a particularly preferred exemplary embodiment of the system according to the invention for the commissioning of printing services and postal services.
  • a system 10 is delimited from other components by a dashed line in order to clarify which components are advantageous for operating such a system.
  • various components can also be outsourced or additionally integrated.
  • the system is referred to below as the shipping service system.
  • the core of the shipping service system 10 is formed by a database 31, which is used for data storage and data retrieval and is connected to various components of the system.
  • the entire data storage preferably takes place in a relational database.
  • an Oracle database has proven to be useful as a database.
  • the database is connected via an interface 30 to at least one order component on which an order for a mail item to be printed and sent can be generated is.
  • the database is also connected to a processing component 70 for generating print jobs and a print production 50, to which the generated print jobs for generating the mail items are transmitted. It has proven to be expedient to use a JDBC interface (Java Data Base Connectivity interface) as the interface 30.
  • the system also includes an invoice component 91 for billing the printing service and the postal service provided by the system.
  • the illustrated order component 20 is a website 21 with an associated system-side server 22. Via applications on this website 21, a user can, for example, generate an order for a postcard to be sent, whereupon the order via the interface 30 of the database 31 and the these connected components is transmitted.
  • the order component can also be a mobile terminal, as is shown as an example in FIG. 1 as a mobile phone 80. It is advantageous for the invention that users of the shipping service system 10 can also generate orders for printing services and postal services via such a mobile terminal.
  • the user can be provided with postcard motifs for selection via the mobile phone. However, it is particularly advantageous if the user can select digital images generated by the mobile phone as motifs for a postcard.
  • a second interface 81 can be provided between the interface 30 and the mobile terminal 80 for converting data and / or for additional applications. This is used, for example, to convert the data format and / or to check the address.
  • the processing component 70 comprises at least two components, which are referred to here as back-end services 71 and 72. One of these components is used to create the image motif, while the other component generates preview and print data.
  • the database is connected to at least one print production 50, to which the print jobs generated by the backend services are transmitted. Print production can be an integral part of the shipping service system or it can be modularly connected to the system.
  • Print production uses the received data to generate a mail item 40, which it then passes on to a distribution system 90.
  • the distribution system can include various sorting and distribution means for delivering the mail item to a recipient on the basis of the delivery information specified by the user.
  • the system 10 comprises at least one further user of the system, who is referred to below as the payer 60.
  • the payer is flexibly connected to the system and preferably has a website 61 with applications and an associated server 62.
  • an order for a print service in connection with a postal service is generated via the order component. It is preferably an order to send a postcard.
  • a user chooses a motif for printing the post card and provides delivery information for sending the card.
  • the motif can be selected in different ways.
  • the system provides the user with a selection of motifs to choose from.
  • it can be advantageous for the user to be able to generate their own motif and transmit it to the system 10 together with delivery information.
  • the illustrated order component 20 is a website 21 in connection with an associated server 22, which the user calls up, for example, on a computer.
  • the connection between the user and the website 21 and thus the server 22 is preferably established via the Internet.
  • the user uses a mobile terminal 80 to generate orders for printing services and postal services, which preferably enter the system as MMS messages (multimedia messaging service) via smtp or http.
  • MMS messages multimedia messaging service
  • the orders for printing services and postal services are orders in which the user incurs little or no costs.
  • the costs are borne by a payer 60.
  • a payer may want to make this sponsored service available to other users of the system for promotional purposes. Users can then visit a website and use it to send postcards for free or at a discount.
  • the website can be the website 21 of the shipping service system or the website 61 of the payer. Sub-variants in which, for example, the payer provides special card motifs but the user pays the card price are also possible.
  • a payer 60 wishes the sponsored provision of card motifs via a payment method, in which a user can generate an order, but the costs for executing the order are billed to the payer, he registers a payer ringing action with the shipping service system, hereinafter referred to as Sponsored Event is called.
  • Sponsored events represent payment actions with certain attributes such as start and end dates and maximum upper limits. Maximum upper limits can be supplemented by defining periods for which these upper limits apply. For example, an upper limit may be “500 cards per day” or may be defined as a global upper limit “1000 cards over the entire period”.
  • the sponsored events are preferably stored in table form in the database 31 of the system. A sponsored event is always assigned to exactly one product and exactly one payer. It has proven to be advantageous that a payer can have any number of sponsored events.
  • the database 31 performs at least the following tasks within the system 10:
  • the term “application” is usually understood to mean any user programs or extensive software packages such as, for example, database applications.
  • the database 31 manages central objects such as payers, event status and
  • a table for sponsored events contains at least the following entries:
  • API Application Programming Interface: interface for application programs
  • a standard API Application Programming Interface: interface for application programs
  • the API contains a function that determines whether a sponsored event is active, inactive, or temporarily inactive, or sets this status when upper limits, start of periods or end of periods have been reached.
  • the number of mail items sent and the amounts already booked for a sponsored event can be counted up, for example, using a trigger.
  • the trigger increases the number of mailings sent, or the amount of an event, and then checks whether the upper limits are still undershot or reached. If a maximum upper limit is reached, the event is deactivated.
  • the payer 60 must provide the shipping service system 10 with the desired card motifs.
  • the system may specify certain requirements. It has proven to be expedient, the transmitted data format, the
  • the card motif can be a TIFF file, in CMYK colors, with a resolution of at least 350 dpi (pixels / inch) and a final size of 15.25 cm x 10.90 cm (actual postcard format 14.85 cm x 10) , 5 cm + bleed). It may be necessary for the system 10 to prepare the motif for printing and to enter it in the system's own database. Raw data are entered into the system 10, for example, while fine data are entered into the print production 50.
  • a user generates an order for a mail item to be printed and sent by entering the website 21 of the system 10.
  • Sponsored and non-sponsored motifs may be offered on this website.
  • the sponsored motifs are displayed in the motif selection like the non-sponsored, paid motifs.
  • a reference to the payer can be displayed in the form of a text or logo for advertising purposes. The user dials in
  • Motif and, together with delivery information, generates the order which is transmitted to the database 31 and the components connected to it.
  • This embodiment involves the least effort for the payer 60. He only has to provide the system 10 with the motif. The user can either enter the website 21 directly, or the payer establishes a link to the system website on his website 61 and the associated server 62. However, this allows
  • Embodiment no further integration of the payer in the system 10.
  • every user of the system's website can see the sponsored motifs and send them free of charge. A restriction to users who have previously visited the payer's website is not possible.
  • a user selects the motif of the desired postcard in the payer's website 61 and sends the postcard via the system 10.
  • the internal motif selection of the system 10 is in this case for the
  • This variant ensures that the user must have visited the payer's website in order to send a free postcard.
  • the user is automatically linked to the applications of a shipping company's website by means of corresponding links on a payer's website. service system.
  • the user uses these applications to create an order for a mail item to be printed and sent, and the server of the shipping service system transmits the data for an order to the database.
  • this form results in somewhat more effort. This is primarily related to the need to ensure that the user actually enters the system 10 from the payer's website.
  • the automatic forwarding of the user from the website of the payer to the website of the shipping service system is preferably carried out via a mutual communication process between the server of the payer and the server of the shipping service system.
  • the following method has proven to be particularly advantageous:
  • the payer 60 calls up a special page of the website 21 via HTTPS (Hypertext Transfer Protocol, secure). This can be done, for example, via an ASP, CGI or a JSP program.
  • ASP Active Server Pages
  • CGI stands for "Common Gateway Interface "and is a data exchange interface between a web server and a client that is able to receive CGI-compliant data and, under certain circumstances, to process it further and send it back to the server.
  • JSP Java Server Pages
  • JSP pages are HTML files with specially marked embedded Java programs.
  • the special page of website 21 is protected to prevent third parties from using cards at the expense of the payer.
  • the server 62 of the payer 60 must identify itself to the system 10 by transferring a key that is unique to the sponsored event. The system communicates this identification (ID) in advance.
  • ID identification
  • ACL Access Control List
  • An ACL Access Control List ensures that only authorized IP addresses of different payers are allowed to access. Only computers in a network defined in this list may access certain services of the network. The payer must provide his IP address in advance. The system 10 then unlocks them. Even higher security can be achieved by using client certificates.
  • the system In response to the call, the system returns a session ID.
  • This session ID is the key for the user to send a free postcard.
  • the program on the web server 62 of the payer 60 evaluates the return and forwards the user to the website 21 of the system. This can expediently be done via a link or redirect.
  • the filling out and sending of a desired card takes place via various pages of the website of the system 10, as have already been described. If the check shows that a user has not accessed the website of the shipping service system via the website of the payer, an order cannot be generated.
  • the main effort for this embodiment is the implementation of the protocol for the requests for a session ID.
  • the payer 60 does not use the pages of the system 10, but creates the necessary data himself and then delivers it to the server 22 of the system 10 on the server side, which receives the data and books the cards.
  • the order for a mail item to be printed and sent is accordingly generated on a payer's website, and the associated server transmits the data for the order directly to the server of the shipping service system, which transmits the data to the database.
  • the recording of the postcard data and the delivery of the data to the system can also be carried out completely asynchronously.
  • the payer 60 can, for example, collect the card data in a database and deliver it to the system once a day. If a payer uses direct delivery, he does not need a session ID, but can deliver directly in a single call. In addition to the card data, he also transfers a payer key with which he is identified in the shipping service system 10 and with which the sponsored event to be used can be determined. For reasons of backward compatibility, it has proven to be advantageous that with this direct delivery, instead of a payer key, a sponsored SessionID is also accepted, which was previously requested. Access to direct delivery is preferably also protected via web server ACLs to prevent unauthorized mailing of cards at the expense of the payer. Even higher security can be achieved by using client certificates. It has also been found useful to provide the caller with a method to check whether his order has been properly accepted.
  • the payer does not specify a selection of own motifs which a user can send free of charge or at a reduced price, but the user can generate his own motif and send it paid for by the payer.
  • FIG. 3 shows, by way of example, the process sequence when generating an order for a postcard to be printed and sent via applications on a website.
  • the process starts on a start page for which a layout template has been created.
  • the layout template for the start page and further pages can be determined by the shipping service system 10 or, for example, freely designed by a payer.
  • the website 21 of the shipping service system is called up via a payer, the standard pages of the shipping service system are not displayed, but the pages created by the payer.
  • a list of the names of all active categories of motifs is shown in a predefined order. If the user moves the mouse pointer over a category, the zoom image of this category is displayed to the left of the category list (CategoriesList).
  • the zoom picture of the first category is preferably displayed according to the sorting. If the user clicks on a category from the list, an overview page for the category is opened. There can also be a link on the start page that leads the user to the branch of the application in which he can upload his own motif. The page that then appears is labeled “Upload” in FIG. 3. At this point, a motif API for reading out the category information has proven to be useful.
  • the "CategoriesList” page shows a list of the preview images of all active categories. If the user clicks on a preview picture, he gets to the motif overview of the selected category (CategorieView). At this point, a motif API for reading out the category information has also proven to be useful.
  • the page with the motif list "CategorieView” shows the preview images of all active motifs in the selected category. Clicking on a motif takes the user to the "MotifView” page. The zoom image of the motif is displayed on this page for the motif detail view. On this page, price information for a selected motif can be displayed in advance before the later payment process. This can only be an information about the non-postage components, since the user only decides where to go on later pages
  • a motif API is used to read out the category and image information and determination and display of the price a pricing API advantageous.
  • OwnMotifView accepts the image data and checks whether the file is not larger than a maximum permissible upper limit. If the specified file is larger than a configured upper limit (MaxDenySize), attempts to misuse it can be assumed. The upload is canceled and an error message is expediently returned.
  • MaxDenySize a configured upper limit
  • the application pre-checks the image. It is checked whether:
  • the image has a valid JPG header.
  • the dpi number is not higher than the maximum allowed. (Upper limit preferably configurable, default is e.g. 300)
  • the file size is not larger than the maximum allowed. (Upper limit is preferably configurable, default is e.g. 300 KB)
  • an error page can be displayed.
  • a MOTIF_BUILDER task is created and the file is saved as Task_File stores.
  • the task creates a preview image from the user's JPG, which shows how the image is positioned on the postcard and the print PDF.
  • the application polls the status of the task at configurable intervals. If the result is available within a configurable period, the preview page is delivered with the preview image.
  • the preview image has a white frame for images that do not fill the postcard format and is displayed with a 1-point frame to clarify the positioning of images that do not fill the postcard format. If the task result is not available or an error has occurred, an error page is displayed.
  • the user is offered links to an HTML editor (EditHTML) and a Java editor (EditJava) on the preview page (OwnMotifView).
  • EditHTML HTML editor
  • EditJava Java editor
  • Preview offers the user the option of a preview PDF. This is opened in a separate window (TextPreview). "Next” saves the user's data and sends it to SendPostcard, which creates a user job.
  • the user input is preferably first checked on the client side using JavaScript. For example, it checks whether a specified email address is RFC-compliant and whether address data has been entered. With “Next” it is additionally checked whether the general terms and conditions (GTC) have been confirmed. If Germany is selected as the country, it is checked whether the postcode or city and at least two further address fields have been filled in, and whether the postcode for Germany, for example, has five digits and is numeric. If an error has been identified, the user is notified of the error with an alert box. If all tests have been passed successfully, the data are sent to a special (server-side) interaction page.
  • GTC general terms and conditions
  • the interaction page creates a task that generates Duck PDF and Preview PDF.
  • the application polls the status of the task at configurable intervals. If the result is not available within a configurable period or if an error has occurred, an error page is displayed. If the task was successful, the preview PDF is opened in a separate window (TextPreview).
  • the interaction page checks whether there are current preview and print PDFs that the user may have already created via "Preview”. If current PDFs are available, they will be used; the task does not have to be called again. If there are no PDFs yet or if the user has changed their map data compared to those used for PDF generation, a task is created that generates the PDFs again. The data is then called up on SendPostcard, which creates the user job.
  • the user enters card text and address data using a Java applet.
  • the applet sends the card text data to the server 22 in a special XML format.
  • WYSIWYG functionality What You See Is What You Get
  • the buttons “Back”, “Preview” and “Next” are offered. "Back” leads back to "MotifView” or “OwnMotifView” depending on whether the user uses his own or a standard motif.
  • Preview offers the user the option of a preview PDF. This is opened in a separate window (TextPreview). "Next” saves the user's data and sends it to SendPostcard, which creates the user job.
  • the fonts and colors offered are preferably configurable. If the user does not select a font or color, it has proven to be useful to use the default setting. If the entered map text does not fit on the designated area, a warning is advised, but the PDF is generated. Text that is no longer suitable is cut off.
  • TextPreview is called up by clicking the "Preview” button on EditJava and EditHTML.
  • TextPreview is opened as a separate window that only contains the generated preview PDF of the text page and no layout. The user can save or print the PDF via browser functionalities and close the window again.
  • SendPostcard is a page that is not visible to the user.
  • the site accepts the data, checks the address data and the terms and conditions in addition to the client-side check that has already been carried out (based on the same criteria) and then creates the user job and carries out the determination of the price for the postcard. If these were successful, SendPostcard redirects to an invoice component 91, via which the payment is processed. This invoice component is referred to below as the billing server.
  • the billing server 91 is responsible for processing the payment of orders.
  • the billing server can accommodate modules for an unlimited number of payment systems. Even if the billing server is shown in FIG. 3 as a separate component, it is preferably not operated in the form of a separate application or instance, but is an integral part of the front end and is also considered below as part of the front end.
  • the billing server determines which payment methods are available for an order and offers them to the user for an interactive payment process.
  • micro-payment systems such as T-Pay, Firstgate, etc. can be used.
  • the billing server is preferably expanded in such a way that the payment process for sponsored user jobs always takes place automatically, without the user initiating it.
  • Sponsored jobs can be paid for by direct debit, for example, which presupposes that the payer has an active bank account. If a payment process is confirmed by a user or a payer, the user is automatically forwarded to a confirmation page (SendConfirmation).
  • the processing component comprises nente two so-called back-end services, which generate the PDF files and the preview files that are preferably required for the subsequent print production 50.
  • a backend service for image creation 71 generates preview and print data for the motif.
  • Another component for creating text templates 72 generates a print and preview PDF of the text page.
  • the print files are preferably generated as PDF files in a special postcard format which, for example, has an additional border in order to avoid a white border or the overlap with other motifs on the resulting mail item.
  • the preparation and conversion of data for the production of a postcard is described below as an example. It has proven useful that the text for a postcard to be generated can be delivered in three formats: Piain text (simple text), RTF (Rieh Text Format) and XML (Extensible Markup Language).
  • the XML format corresponds to the printing instructions as they are preferably processed on the card production side.
  • one-line text blocks, lines and pictures can be positioned with millimeter precision. Therefore, it is preferably converted into XML format.
  • the format plain text is therefore converted into an XML format within the editing component 70, so that an associated template creation core only has to be able to process the XML format.
  • the RTF format is also converted to XML by a module.
  • the Piain Text format corresponds to normal, unformatted text and is supplied by the frontend when the text has been entered by the user in an HTML order component.
  • the font and size of the entire text of the card can be transferred from the front end. It is preferred that the text entered via a website or a mobile device is positioned line by line by the backend services of the editing component. If a line of text is wider than the text area of a postcard, it is wrapped with a suitable space.
  • the JPG format is preferably supported for the motif of a postcard. If the JPG image contains information about its resolution (in dpi), it is advantageous to use it to determine the real size of the image (in mm). If no information on the resolution is available, a standard resolution is expediently assumed.
  • the standard resolution can be 96 dpi, for example.
  • the documents to be printed consist of a production text page 100 and a production motif page 110, as shown side by side in FIG. 2.
  • the documents are preferably created as single-sided PDF files in a special postcard format that has an additional border in order to avoid a white border or the overlap with other motifs on the resulting postcard.
  • the production text page 100 can, for example, elements such as card text 101, delivery information (recipient address) 102, information on copyrights 103, a company logo 104, a
  • the layout of this page can be predefined, with certain parameters such as
  • Edges and distances are expediently configurable. For example, if the user wants their own logo file upload, this can be done via a corresponding link.
  • the backend services generate a production PDF file and optionally a preview PDF file.
  • the production PDF file contains a page that is preferably larger than a normal postcard on which the given text is positioned.
  • Text PDF file is placed over a static PDF file to give the customer an impression of the resulting postcard.
  • Fonts that are not standard fonts in the PDF format and are in TrueType format are embedded in the PDF file and can thus be made available to the printer.
  • a PDF file is generated which contains the image motif uploaded by the customer and which is positioned according to certain rules. If an image is not uploaded in a specific color space, it can be converted into the required color space. Since the CMYK color space is preferred for printing postcards, an image uploaded in the RGB color space is converted into the CMYK color space for the production PDF. For the generated preview image (JPG) the RGB The color space is retained, or the image is converted to the RGB color space if CMYK was uploaded.
  • JPG generated preview image
  • the backend services analyze the image uploaded by the user and generate a PDF file for production and a JPG image for preview in the front end.
  • the scaling / positioning is not carried out by the backend service, but is integrated into the PDF file with appropriate parameters (width, height, position).
  • the image can thus be optimally calculated by a RIP (Raster Image Processor).
  • the image for production is converted to the CMYK color model before being placed in the PDF file in order to achieve an optimal print result.
  • a JPG image with defined dimensions is created for the preview in the front end.
  • This image has a white background and corresponds to the layout of the resulting PDF file.
  • the processing component 70 transfers the print jobs generated by the back-end services to a print production 50 which executes the print jobs.
  • This print production component is preferably designed in such a way that it can produce different postal products. For example, she can print postcards or letters.
  • print production can generate a specific postal product.
  • the print productions can be system-specific components or connected print service providers, which accept print jobs and follow them up
  • these motifs are stored as pre-ripped PostScript files with crop marks on a local data storage device of the printer.
  • the PostScript files have the format: 151.5 x 108 mm.
  • the crop marks are designed to match the format
  • print production 50 requires a reference to the file locally held on the printing press.
  • PostScript files on the collator for all text pages. These files include, for example, the payer logo, the indicium and the vertical line in the middle. All other texts (copyright, text field, address field) are in a PDF file created by the backend services.
  • SDL Service Data
  • Line is a unique numbering for reprints and is generated during production.
  • a PDF file is required for the production, on which the image is located. This PDF file was created by a backend service. Print production 50 inserts crop marks during production. The creation of the text page corresponds to the previously described creation of this page when a user selects predetermined motifs.
  • the method according to the invention and the associated system for carrying out the method have various advantages. First, it allows users of the system to
  • Frontend interface 40 Postal product 50 Print production 60 Payer

Landscapes

  • Business, Economics & Management (AREA)
  • Economics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Transfer Between Computers (AREA)

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 Druckleistung und die postalische Leistung über eine Rechnungskomponente (91) abgerechnet. Die Erfindung betrifft ferner ein System zur Durchführung des Verfahrens.

Description

Verfahren und System zur Beauftragung und Durchführung von Druckdienstleistungen und postalischen Leistungen
Beschreibung:
Die Erfindung betrifft ein Verfahren zur automatisierten Beauftragung und Durchführung von Druckdienstleistungen und postalischen Leistungen innerhalb eines Versanddienst-Sys- tems, 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 Kom- bination 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 -veranstal- tungen 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 Mailing- Systems 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 Dienst- leistung 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ög- ' lieh. 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üh- rung 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 Aufberei- tungskomponente,
- Ü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 versenden- den 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 Er- zeugen 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 ste- hende 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 Rechnungs- komponente zur Abrechnung erbrachter Druckleistungen und pos- talischer 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 ange- schlössen 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-Sys- tem 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 Post- karte 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-Sys- tem, 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 Zustellinfor- mationen 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 gleich- falls 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 Durch- fü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
Fig. 1 eine Darstellung eines besonders bevorzugten
Ausführungsbeispiels des erfindungsgemäßen Versanddienst-Systems;
Fig. 2 eine Darstellung einer zweiseitigen Druckversion einer mit dem erfindungsgemäßen Verfahren und System erzeugten Postkarte; und
Fig. 3 den Verfahrensablauf bei der Generierung eines Auftrags für eine Postkarte über Applikationen einer Website.
Fig. 1 zeigt ein besonders bevorzugtes Ausführungsbeispiel des erfindungsgemäßen Systems zur Beauftragung von Druck- dienstleistungen 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 Datenretrie- val 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 Auf- bereitungskomponente 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 Fig. 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 wer- den. 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 Druck- Produktion 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 Auftrags- komponente 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 Ausfuhrungsbeispiel 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 Postkar- ten 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 ande- ren 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 :
Figure imgf000016_0001
Für den Zugriff auf eine derartige Tabelle hat sich eine Standard-API (Application Programming Interface: Schnittstelle für Anwendungsprogramme) als besonders zweckmäßig er- wiesen, 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-Da- tei, in CMYK-Farben, mit einer Auflösung von mindestens 350 dpi (Pixel/lnch) und einem Endmaß von 15,25 cm x 10,90 cm (eigentliches Postkartenformat 14,85 cm x 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 Zah- lers 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 Daten- bank. 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 Be- nutzers 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 Brow- ser 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 ver- hindern, 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 mittei- len. 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 ge- schehen. 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 serversei- tig 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 ser- verseitig 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 Fig. 3 ist beispielhaft der Verfahrensablauf beim Generie- ren 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 Layout- vorläge erstellt wurde. Die Layoutvorlage für die Startseite und weitere Seiten können vom Versanddienst-System 10 festge- legt 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, wel- eher den Benutzer zu dem Zweig der Anwendung führt, in welcher er ein eigenes Motiv hochladen kann. Die daraufhin erscheinende Seite ist in Fig. 3 mit "Upload" bezeichnet. An dieser Stelle hat sich eine Motiv-API zum Auslesen der Kate- gorieinformationen 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 eben- falls 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 "Mo- tifView" . 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 Motives 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 zweck- mäßigerweise eine Fehlermeldung zurückgeliefert.
Wurden die Daten entgegengenommen und keine Fehler detek- tiert, 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 (caseinsensi- tiv) .
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 Pre- viewBild, 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ül- lenden 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 Be- nutzers 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) Interakti- onssseite 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öff- net.
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 Adress- daten ü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 Fig. 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 Be- zahlVorgang 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 be- schrieben. Es hat sich dabei als zweckmäßig erwiesen, dass der Text für eine zu erzeugende Postkarte in drei Formaten eingeliefert werden kann: Piain-Text (einfacher Text) , RTF (Rieh 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 Piain-Text wird daher innerhalb der Aufbereitungs- komponente 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 Piain 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 -groß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 ge- eigneten 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 Fig. 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 verschie- dene 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-Da- tei 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 heraufgeladene 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 hochgela- denes 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-Farb- raum 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 Druckproduktionskom- ponente 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 Druckpro- duktionskomponenten 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 x 108 mm. Die Schnittmarken sind so ausgelegt, dass auf das Format
148,5 x 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.
Bezugszeichenliste :
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

Patentansprüche:
1. Verfahren zur automatisierten Beauftragung und Durch- fü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 Auftrags- komponente, 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 Druckproduk- tion (50) ,
- Erstellung einer Postsendung (40) in der Druckproduktion (50) ,
- Übergabe der Postsendung (40) an ein Distributions- system (90) , und
- Abrechnung der Druckleistung und der postalischen Leistung über eine Rechnungskomponente (91) .
2 . Verfahren nach Anspruch 1 , dadurcli 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.
3. Verfahren nach einem oder beiden der Ansprüche 1 und 2, dadurcli 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 .
4. Verfahren nach einem oder mehreren der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass es sich bei der zu druckenden und zu versenden- den Postsendung (40) um eine Postkarte, Grußkarte und/oder Klappkarte handelt.
5. 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 .
6. 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.
7. 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 .
8. 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 Web- site in Verbindung mit einem zugehörigen Server generiert wird, und die Auftragsdaten über eine Schnittstelle (30) einer Datenbank (31) übermittelt werden.
9 . Verfahren nach Anspruch 8 , dadurch gekennz eichne t , 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.
10. 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.
11 . Verfahren nach Anspruch 10 , dadurch gekennz eichnet, 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.
12 . Verfahren nach Anspruch 11 , dadurch gekennz eichnet, 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.
13. 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.
14. 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.
15. 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.
16. Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass die Daten für einen Auftrag der Schnittstelle (30) über eine zweite Schnittstelle (81) übermittelt werden.
17. Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass die zweite Schnittstelle (81) die Daten in ein
Format konvertiert, welches von der Schnittstelle (30) verarbeitbar ist.
18. 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.
19. System zur automatisierten Beauftragung und Durchführung von Druckdienstleistungen und postalischen Leistungen, bei dem an einer Auftragskomponente ein Auf- trag 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.
20 . System nach Anspruch 19 , dadurch gekennzeichnet, dass die Auftragskomponente durch eine Website und einen zugehörigen Server gebildet wird.
21 . System nach Anspruch 20 , dadurch gekennzeichnet, dass die Auftragskomponente durch ein mobiles Endgerät (80) gebildet wird.
22. 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.
23. 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.
PCT/DE2004/000893 2003-05-28 2004-04-29 Verfahren und system zur beauftragung und durchführung von druckdienstleistungen und postalischen leistungen Ceased WO2004108429A2 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
AU2004245156A AU2004245156A1 (en) 2003-05-28 2004-04-29 Method and system for ordering and performing printing services and postal services
EP04730195A EP1634229A2 (de) 2003-05-28 2004-04-29 Verfahren und system zur beauftragung und durchf hrung von d ruckdienstleistungen und postalischen leistungen
US10/559,488 US20070061224A1 (en) 2003-05-28 2004-04-29 Method and system for ordering and performing printing services and postal services

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10324539.1 2003-05-28
DE10324539A DE10324539A1 (de) 2003-05-28 2003-05-28 Verfahren und System zur Beauftragung und Durchführung von Druckdienstleistungen und postalischen Leistungen

Publications (2)

Publication Number Publication Date
WO2004108429A2 true WO2004108429A2 (de) 2004-12-16
WO2004108429A3 WO2004108429A3 (de) 2005-01-27

Family

ID=33482297

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2004/000893 Ceased WO2004108429A2 (de) 2003-05-28 2004-04-29 Verfahren und system zur beauftragung und durchführung von druckdienstleistungen und postalischen leistungen

Country Status (7)

Country Link
US (1) US20070061224A1 (de)
EP (1) EP1634229A2 (de)
CN (1) CN1795460A (de)
AU (1) AU2004245156A1 (de)
DE (1) DE10324539A1 (de)
RU (1) RU2005137401A (de)
WO (1) WO2004108429A2 (de)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005276161A (ja) * 2004-02-26 2005-10-06 Seiko Epson Corp レイアウトシステム、レイアウト装置、レイアウトプログラム、テンプレート選択プログラム、レイアウトプログラムを記憶した記憶媒体およびテンプレート選択プログラムを記憶した記憶媒体、並びにレイアウト方法
US7602521B2 (en) * 2006-01-31 2009-10-13 Pitney Bowes Inc. Document format and print stream modification for fabricating mailpieces
US8285645B2 (en) * 2007-02-21 2012-10-09 Milstein Seth M Remote product ordering using mobile phones
US10127480B1 (en) 2007-03-09 2018-11-13 R. B. III Associates, Inc. System for automated decoration
US20110106596A1 (en) * 2009-10-29 2011-05-05 Rodger Cosgrove System and Method of Generating Postal Mailers for Free
WO2012112886A2 (en) * 2011-02-17 2012-08-23 Postcard On The Run Mobile phone application, system, and method for sending postcards and obtaining mailing addresses
US9100668B2 (en) * 2012-05-31 2015-08-04 Matthew Nathan Lehrer Graphics correction engine
CN107170027A (zh) * 2017-05-18 2017-09-15 中邮电子商务有限公司 一种基于主题邮局app的图像合成及拼接方法及系统
US10594634B1 (en) 2018-12-05 2020-03-17 Soo Chuan Teng Electronic mail generation device and method of use

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5552994A (en) * 1992-09-23 1996-09-03 Onkor, Ltd. System for printing social expression cards in response to electronically transmitted orders
US5555496A (en) * 1994-05-06 1996-09-10 Mary T. Tackbary Method and apparatus for communicating with a card distribution center for management, selection, and delivery of social expression cards
US5805810A (en) * 1995-04-27 1998-09-08 Maxwell; Robert L. Apparatus and methods for converting an electronic mail to a postal mail at the receiving station
CA2177447C (en) * 1995-05-30 2007-01-23 James L. Harman System having multiple user input stations and multiple mail preparation apparatus for preparing and franking a mail piece
US5983200A (en) * 1996-10-09 1999-11-09 Slotznick; Benjamin Intelligent agent for executing delegated tasks
EP0977141A3 (de) * 1998-07-31 2003-04-23 Sony Corporation Informationsverarbeitungsgerät und -Verfahren
AU3893800A (en) * 1999-03-19 2000-10-09 Zairmail, Inc. Distributed system for conducting physical delivery mail service over the internet
US6529214B1 (en) * 1999-05-14 2003-03-04 Checkerboard Ltd. Interactive print job display system and method
US6507865B1 (en) * 1999-08-30 2003-01-14 Zaplet, Inc. Method and system for group content collaboration
WO2001075717A1 (en) * 2000-03-31 2001-10-11 Sanyo Electric Co., Ltd. Server computer, card providing control method, and card distributing control method
JP2002044355A (ja) * 2000-07-25 2002-02-08 Omron Corp 写真入りカード発送方法および写真入りカード発送システム
CA2376918C (en) * 2001-03-14 2007-10-23 Research In Motion Limited Scalable and secure messaging system for a wireless network

Also Published As

Publication number Publication date
EP1634229A2 (de) 2006-03-15
WO2004108429A3 (de) 2005-01-27
RU2005137401A (ru) 2006-06-27
AU2004245156A1 (en) 2004-12-16
DE10324539A1 (de) 2004-12-23
CN1795460A (zh) 2006-06-28
US20070061224A1 (en) 2007-03-15

Similar Documents

Publication Publication Date Title
EP1573611B1 (de) System und verfahren zur herstellung eines kundenindividuellen druckerzeugnisses
US6732152B2 (en) Methods and apparatus for generation and distribution of surface mail objects
DE69937097T2 (de) Postproduktionssystem mit Hilfe zum Drucken von Drittanbieternachrichten auf Poststücken
DE60210201T2 (de) VRFAHREN ZUM AUSWÄHLEN EINES BILDTRAGENDEN PRODUKTS, DAS EIN VON EINEM DIGITALEN BILD MIT BESONDERER AUFLÖSUNG UMGEWANDELTES BILD BESONDERER GRÖSSE ERFORDERT d
EP2067101A1 (de) Druckprodukt und verfahren zu seiner herstellung
EP1634229A2 (de) Verfahren und system zur beauftragung und durchf hrung von d ruckdienstleistungen und postalischen leistungen
DE60019345T2 (de) Elektronische glückwunschkarte
DE10324538B4 (de) Verfahren und System zur Beauftragung und Durchführung von Druckdienstleistungen und postalischen Leistungen
EP1221675A2 (de) Verfahren zum Vermitteln von Versandaufträgen für Poststücke und System zur Durchführung des Verfahrens
DE60002546T2 (de) System und verfahren zur automatischen feststellung der medienart im papierfach eines druckers
WO2002039329A2 (de) Verfahren und computersystem zur erlangung übermittlung und erstellung von individualisierungsauftragsdaten
EP1320965B1 (de) Verfahren und vorrichtung zum austausch von informationen
DE10055145A1 (de) Verfahren zum Versehen von Postsendungen mit Frankierungsvermerken
DE102004003004B4 (de) Verfahren und Vorrichtung zur Frankierung von Postsendungen
WO2007042136A1 (de) Warenauslieferungssystem, verfahren zur auslieferung von waren, versandkomponente und ausgabestelle für waren
WO2007137778A1 (de) Speichersystem und verfahren zum speichern von informationen auf einem speichermedium
DE10147902A1 (de) Kommunikationssystem und mobiles Kommunikationsendgert für den Einsatz in einem solchen Kommunikati onssystem
EP1691308A1 (de) Verfahren und Vorrichtung zur kundenspezifischen Erstellung von Einträgen in einem Telefonbuch od. dgl.
DE69935406T2 (de) System und Verfahren zum subventionierten Drucken von Drittenanbietergutscheinen zur Einführung in ein bestimmtes Poststück
DE102020126703A1 (de) Verfahren zur computergestützten Endgerätsuche
WO2004109568A1 (de) System und verfahren zur verarbeitung von adressierten sendungen
WO2010015320A2 (de) Gerät für die automatische produktion von individuellen karten mit bild
DE202004005436U1 (de) Einrichten zum Versenden von Dokumenten einer elektronischen Datenverarbeitungsanlage
DE102007015296A1 (de) Verfahren zur Online-Vermittlung von Kontakten für die Verteilung von Werbemitteln
AT8025U1 (de) Einrichtung zum versenden von dokumenten einer elektronischen datenverarbeitungsanlage

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 20048140374

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2004245156

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 2004730195

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2004245156

Country of ref document: AU

Date of ref document: 20040429

Kind code of ref document: A

WWP Wipo information: published in national office

Ref document number: 2004245156

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 1408/MUMNP/2005

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2005137401

Country of ref document: RU

WWP Wipo information: published in national office

Ref document number: 2004730195

Country of ref document: EP

DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2007061224

Country of ref document: US

Ref document number: 10559488

Country of ref document: US

WWW Wipo information: withdrawn in national office

Ref document number: 2004730195

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 10559488

Country of ref document: US