WO2008049579A1 - Verfahren zum erzeugen eines labels, computerprogrammprodukt, netzwerkknoten und system zur durchführung des verfahrens - Google Patents

Verfahren zum erzeugen eines labels, computerprogrammprodukt, netzwerkknoten und system zur durchführung des verfahrens Download PDF

Info

Publication number
WO2008049579A1
WO2008049579A1 PCT/EP2007/009183 EP2007009183W WO2008049579A1 WO 2008049579 A1 WO2008049579 A1 WO 2008049579A1 EP 2007009183 W EP2007009183 W EP 2007009183W WO 2008049579 A1 WO2008049579 A1 WO 2008049579A1
Authority
WO
WIPO (PCT)
Prior art keywords
label
server
document
user
program
Prior art date
Application number
PCT/EP2007/009183
Other languages
English (en)
French (fr)
Inventor
Henning Endruscheit
Volker Klös
Thomas Ogilvie
Boris Mayer
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 US12/447,264 priority Critical patent/US8477345B2/en
Publication of WO2008049579A1 publication Critical patent/WO2008049579A1/de

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00459—Details relating to mailpieces in a franking system
    • G07B17/00508—Printing or attaching on mailpieces
    • 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/00048—Software architecture
    • G07B2017/00056—Client-server
    • 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/00048—Software architecture
    • G07B2017/00056—Client-server
    • G07B2017/00064—Virtual meter, online stamp; PSD functions or indicia creation not at user's location
    • 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/0008—Communication details outside or between apparatus
    • G07B2017/00145—Communication details outside or between apparatus via the Internet
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00185—Details internally of apparatus in a franking system, e.g. franking machine at customer or apparatus at post office
    • G07B17/00435—Details specific to central, non-customer apparatus, e.g. servers at post office or vendor
    • G07B2017/00443—Verification of mailpieces, e.g. by checking databases
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00459—Details relating to mailpieces in a franking system
    • G07B17/00508—Printing or attaching on mailpieces
    • G07B2017/00572—Details of printed item
    • G07B2017/0058—Printing of code
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00459—Details relating to mailpieces in a franking system
    • G07B17/00508—Printing or attaching on mailpieces
    • G07B2017/00612—Attaching item on mailpiece
    • G07B2017/0062—Label

Definitions

  • the invention relates to a method for producing a label that can be applied to a mailpiece.
  • the invention further relates to a computer program product, a network node and a device for carrying out the method.
  • Such labels are generated for example by a suitable data processing unit - for example a personal computer.
  • this object is achieved by a method having the features of patent claim 1, a computer program product according to claim 14, a network node according to claim 15 and by a system according to claim 16.
  • a method for generating a label is performed such that a network node provides a data service that is executed in at least one provider server of a service provider, wherein data for insertion into the label is generated.
  • a development of the method, the computer program product, the network node and the system is characterized by the fact that the data service is an Internet service.
  • Return labels are labels that allow a user of the computer system to return mail received from him to a sender.
  • a further development of the method, of the computer program product, of the network node and of the system is characterized in that a checking step is carried out to check a voucher and, depending on the result of the checking step, the generation of the label is influenced.
  • a development of the method, the computer program product, the Net zwerkknotens and the system is characterized in that in a preceding the examination step Process step, the coupon is transmitted to a user.
  • a further development of the method, of the computer program product, of the network node and of the system is characterized in that a program module is introduced into the intelligent document which is designed to provide a displayable indication of a result of the checking step or of a further checking step for checking the presence the prerequisite within the intelligent document.
  • a development of the method, the computer program product, the network node and the system is characterized in that at least one of the test steps is performed by means of the program module.
  • a further development of the method, of the computer program product, of the network node and of the system is characterized in that in the checking step it is checked whether the program execution environment is available.
  • a development of the method, the computer program product, the network node and the system is characterized in that a program controls a one-time printing of the label and that an intelligent document is transmitted from a server to a client via a network.
  • a further development of the method, of the computer program product, of the network node and of the system is characterized in that a message is transmitted from the user client to the server during a first printing of the label and that the print is logged in the server due to the message. is liert.
  • a refinement of the method, of the computer program product, of the network node and of the system is characterized in that the program for controlling the printing of the label can only be executed if there is a network connection between the client and the server and if it is queried by the user Server has been determined that the label has not yet been printed.
  • a further development of the method, of the computer program product, of the network node and of the system is characterized in that it is checked in at least one of the checking steps whether there is access to the network.
  • a refinement of the method, of the computer program product, of the network node and of the system is characterized in that in at least one of the checking steps a query of the server is made, in which it is checked whether contents of the intelligent document have already been printed once.
  • a further development of the invention includes a system that enables customers to request and print labels via an online interface via a PC, which is referred to below as a user client.
  • the interface is provided by a server, hereafter referred to as POP server (POP: Parcel Online Postage).
  • the customer first generates one or more entries for mailpieces to be sent in a shopping cart on a first page provided by the POP server (referred to below as NOW 1). Contains this the website NOW 1 a button through which the user can access another website (hereinafter referred to as NOW2, the shipment details represents) on the data of a broadcast can be detected and manipulated.
  • NOW 1 a button through which the user can access another website (hereinafter referred to as NOW2, the shipment details represents) on the data of a broadcast can be detected and manipulated.
  • the data include, for example, the sender address, the recipient address and a selection of the products and services as well as the destination countries, from which in particular the postage value for the shipment results.
  • the user can specify one or more additional services for the shipments. These include, for example, a roll service for round packaging or a specific bulky goods service, whereby these forms are only examples of additional services.
  • the shopping cart contains at least one entry, another button is active on the website NOW 1, via which the customer can initiate a payment process.
  • NOW 3 a website which contains links to PDF documents which enable the printing of the purchased franking label. Furthermore, after the payment has been made, an e-mail will be sent to the customer which contains a link to the website NOW 3, which will allow the website to be called up again at a later date. The e-mail will be sent to an address previously entered by the customer on the NOW 1 website. If the value of the shopping cart exceeds a certain amount, the access to the website NOW 3 becomes over The link contained in the e-mail is secured by a PIN, which is presented to the user on the NOW 3 page but not transmitted by e-mail.
  • a further development of the invention includes a voucher functionality that allows a customer to purchase vouchers and use them for the payment of postage indicia.
  • the vouchers can be added to the shopping cart on the website NOW 1. Via a corresponding button on this website, the user can access another website (NOW 2 - Voucher Details) where voucher sets for a basic product also selected on this page can be added to the shopping cart. After payment of the shopping cart, the user is offered a possibility on the website NOW 3 to display or save the purchased coupon codes. For the later redemption of the voucher the voucher code is entered by the customer when generating the shopping cart on the website NOW 1.
  • the invention is suitable for creating different labels, in particular for producing labellas for controlling logistical functions of the mailpieces, in particular their transport, sorting and / or forwarding.
  • the labels contain, for example, monetary information as proof of payment, so that it is an example of franking labels.
  • the labels may contain further information for handling the mailpieces-for example a sender address, a recipient address, a mailing identification code or other data describing the mailing (eg weight or dimensions). This is a use of the label to monitor the shipment history (Tracking) or to a proof of the shipment history (tracing) possible.
  • the labels contain, in addition to the address of the recipient and the sender, a routing code assigned to the recipient address, which is used in the production of the mailpieces in a parcel or letter center of a mailing service provider.
  • the label includes a unique label identification code.
  • abuse cases can be determined in which a franking label is used several times for the franking of mail.
  • the label codes of the issued franking labels are stored in a payment assurance system.
  • the label identification code is marked as used in the pay-as-you-go system. Furthermore, it is checked for each produced broadcast whether the label identification code is marked as invalid. If this is the case, a case of abuse will be detected.
  • Guide code and label identification code are inserted into the label both in plain text and in the form of a bar code.
  • the franking labels are provided to the customer on the basis of intelligent PDF documents.
  • the invention includes various embodiments for generating the label and for its expression. Particularly preferred embodiments are mentioned below:
  • the POP server receives notification of the payment transaction from the payment provider.
  • a Document database generates a record for the purchased by the customer franking label.
  • the record contains a unique document identification code for the intelligent PDF document, an indication of whether the label has already been printed with valid codes, and form data.
  • the form data includes the sender and recipient address of the mail to be franked, the routing code.
  • the form data includes the label identification code, which is taken after payment from a pool of previously generated codes. This code will also be transferred to the pay-as-you-go system. It also generates an intelligent PDF document, which is an empty form with form fields for the form data mentioned above.
  • the designation of the PDF document is the document identification code.
  • the label is printed as part of the iPDF mechanism by means of a communication between the user client and the POP server or a license server connected to the POP server, which can access the document database.
  • the SOAP interface of the Acrobat Reader is used for communication between the user client. After opening the PDF document, it is first checked successively whether an Internet connection is available, whether the document identification code is valid and whether the label has not already been printed. To perform the last two test steps, a service of the POP server is called via the SOAP interface of the Acrobat Reader, which, after a corresponding query to the database, confirms whether a data record for the document identification code is present in the document database and if the postage indicium already marked as printed.
  • the form data stored in the database with the exception of the valid codes are loaded via the interface of the Acrobat Reader from the POP server and inserted into the form fields of the PDF document.
  • the PDF document initially only contains dummy codes to prevent the user from making a copy of a valid label.
  • the content of the document is first clearly marked as a pattern.
  • the PDF document provides its own functionality, in which test prints as well as printing of a valid label - referred to as postage printing in the following - can be carried out via corresponding buttons within the document.
  • the pattern of the label initially contained in the PDF document is printed with the dummy codes.
  • the valid label is printed, with the valid barcodes being retrieved from the POP server after pressing the appropriate button. Further, by pressing the button for the postage printing in the document database of the POP server is registered that a print of the valid label has been made and the button is hidden or disabled.
  • the label can have different shapes. It is preferably designed so that it allows identification and / or control of mail and possibly also the coordination of a storage space. Appropriately, the label scratch and impact resistant and temperature resistant.
  • Coded information is incorporated into the labels as control instruments for the parcel logistics.
  • the labels may contain a consecutive numbering - optionally with sketchZiffer -, other numbering and address information or other information that classify the shipment or serve, for example, for advertising purposes.
  • RFID identification systems - "smart labels" - make it possible to optimize logistics processes. They are thus a suitable means of influencing - including controlling flexible distribution systems for the route-optimized provision of the mailpieces.
  • a transmission of the label to the operating unit preferably takes place in the form of an intelligent document.
  • an intelligent document which comprises a program which, if a prerequisite is present, can be executed by means of a program execution environment and which contains content that can be displayed by means of a presentation program.
  • the intelligent document is characterized by comprising a program module adapted to generate a displayable indication of a result of the checking step for checking the existence of the prerequisite within the intelligent document.
  • a further embodiment of the method, the intelligent document and the device includes that the program execution environment is part of the presentation program.
  • a label can also be generated independently of a business transaction described above, which for example serves for private shipping purposes or has the goal of generating a postage indicium with the aim of using it for the return of one or more articles to a sender.
  • the shipping and / or franking relevant data from the shipping information system or the listing tools are automated - ie without further action by the seller - passed over an interface to a means for creating a label (Labelerstelldienst).
  • a label is preferably a graphical representation - for example, an expression or a screen display of an intelligent document.
  • a further development of the invention includes a method for generating a smart document which comprises a program which, if a prerequisite is present, can be executed by means of a program execution environment and contains contents that can be displayed by means of a presentation program.
  • a preferred embodiment of the invention is characterized in that the displayable contents consist of static content and dynamic content, wherein an introduction of the dynamic content into the intelligent document takes place separately from an introduction of the static content.
  • address data and / or franking-relevant data are examples of dynamic contents in the sense of preferred developments of the invention.
  • a further development of the invention is also suitable for using other dynamic information and in other technical contexts, for example for automation of other logistics processes, of production processes and of the generation and processing of information. Fields of application in which dynamic information is reproduced and / or edited in a static frame are particularly advantageous.
  • Static information is information that, in particular, allows data to be embedded.
  • the frames can also be so-called
  • a frame is a subarea of a graphical representation, in particular a screen page, for example a graphical user interface.
  • a single segment is referred to as a frame (English term for frame), the definition of all frames as a frameset.
  • the use of frames enables the parallel display of several individual documents, which can be moved independently of each other if necessary.
  • the frames can be used to combine content from different sources or from different data sources.
  • inline frames can be used. They allow a particularly simple data integration into a displayed screen page.
  • a method of the type mentioned at the outset is created in which the intelligent document converts a program. which, if a prerequisite is present, can be executed by means of a program execution environment and contains the content that can be displayed by means of a presentation program.
  • the method is performed such that two different types of content are introduced into the intelligent document, which may originate from one or more sources.
  • a first type of content is static content.
  • Static content preferably matches multiple documents.
  • the static contents are preferably those contents that are suitable for generating multiple documents. Generating multiple documents is very beneficial, but not necessary.
  • the static contents are, for example, frame information for the generation of documents or other information whose update occurs less frequently than in the case of the dynamic contents, preferably only at the end of a predefinable time interval or when an event is reached. Alternatively, it is possible to leave the static data completely unchanged.
  • an intelligent document which comprises a program which, if a prerequisite is available, can be executed by means of a program execution environment and which contains contents which can be displayed by means of a presentation program.
  • the intelligent document is characterized by the fact that a program module is included, which is designed to is to produce a presentable indication of a result of the checking step for checking the existence of the prerequisite within the intelligent document.
  • An embodiment of the invention provides that the program module is a component of the static content.
  • a development of the invention is characterized in that the program module is a component of the dynamic content.
  • a particularly preferred embodiment of the invention provides that the program module is either part of the dynamic content or the static content.
  • a device for generating a smart document which comprises a program which, if a prerequisite is feasible, can be executed by means of a program execution environment and which contains displayable content by means of a presentation program.
  • the apparatus is arranged to introduce a program module into the intelligent document, which is designed to generate a displayable indication of a result of the checking step for checking the existence of the prerequisite within the intelligent document.
  • a development of the method, the intelligent document, the computer program product and the device provides that a program module is included in the intelligent document itself with which an indication of the result of a checking step can be generated. This allows the intelligent document itself to indicate the result of a test. step, so that the result of the checking step is displayed independently of the configuration of the presentation program.
  • an indication that can be displayed within an intelligent document is an indication that can be displayed by means of the presentation program, for example, on a screen.
  • intelligent documents may contain further contents, such as program codes, for example, which are not displayed by means of a presentation program, at least in a normal presentation mode.
  • the method according to the invention for generating an intelligent document which comprises a program which, if a prerequisite is present, can be executed by means of a program execution environment which contains displayable content by means of a presentation program, can be developed in various ways.
  • the intelligent document and the device provides that the static contents are transmitted from a server to a client via a network.
  • An embodiment of the method, the intelligent document and the device provides that the dynamic contents are transmitted from a server to the client via a network.
  • a transmission of the dynamic contents independent of a transmission or non-transmission of the static contents, has the advantage that the data transmission expenditure for the generation of a smart document is reduced.
  • a development of the method, the intelligent document, the computer program product and the device provides that the static contents and the dynamic contents are transmitted separately from each other.
  • a further development of the method, the intelligent document, the computer program product and the device provides that the transmission takes place separately in time.
  • An embodiment of the method, the intelligent document, the computer program product and the device is characterized in that the transmission takes place on different transmission paths.
  • a further development of the method, the intelligent document, the computer program product and the device provides that the static contents are provided by a different data source than the dynamic contents.
  • An embodiment of the method, the intelligent document, the computer program product and the device is characterized in that the static contents are transmitted by a first server and that the dynamic contents are transmitted by another server.
  • a further development of the method, the intelligent document, the computer program product and the device provides that the static data is stored in an area of a client.
  • the documents are used in particular by a client.
  • the client is advantageously available to a user of the system and is therefore also referred to as a user client in the present application.
  • the client is preferably equipped to recognize whether the document transmitted is an intelligent document. This is done in a development of the invention in that the presence of a confirmation information is checked.
  • the confirmation information is a signature.
  • One embodiment of the method, the intelligent document, the computer program product, and the device provides that the client, upon opening a document, checks to see if it has been signed.
  • the static content is preferably transmitted separately from the dynamic content.
  • the static contents are, for example, layout information for the design of the document.
  • the static contents of the dynamic content differ by the time of each generation.
  • the static content and the dynamic content can also differ from one another by the event that triggers them each time.
  • a development of the method, the intelligent document, the computer program product and the device provides that the static contents are transmitted in the presence of a first event.
  • An embodiment of the method, the intelligent document, the computer program product and the device is characterized in that the static information is transmitted in the presence of an event of a first type of event.
  • a development of the method, the intelligent document, the computer program product and the device provides that the dynamic contents are transmitted in the presence of a second event.
  • An embodiment of the method, the intelligent document, the computer program product and the device is characterized in that the dynamic information is transmitted in the event of an event of a second type of event.
  • a development of the method, the intelligent document, the computer program product and the device provides that a presence of the second event is determined taking into account a checking step.
  • An embodiment of the method, the intelligent document, the computer program product and the device is characterized in that the first event differs from the second event.
  • an intelligent document which comprises a program which, if a prerequisite is available, can be executed by means of a program execution environment and which contains displayable content by means of a presentation program.
  • the intelligent document is characterized in that it includes a program module adapted to generate a displayable indication of a result of the checking step for checking the existence of the prerequisite within the intelligent document.
  • a device for generating a smart document which comprises a program which, if a prerequisite is feasible, can be executed by means of a program execution environment and which contains displayable content by means of a presentation program.
  • the apparatus is arranged to introduce a program module into the intelligent document, which is designed to generate a displayable indication of a result of the checking step for checking the existence of the prerequisite within the intelligent document.
  • a further development of the invention of the invention is that in the intelligent document itself a program module is included, with which an indication of the result of a test step can be generated.
  • the intelligent document itself is capable of indicating the result of a checking step, so that the result of the checking step is displayed independently of the configuration of the presentation program.
  • a representable indication within a smart document is understood in the context of the invention to be an indication which can be displayed by means of the presentation program, for example on a screen.
  • intelligent documents may contain other contents, such as program code, which are not displayed by means of a presentation program, at least in a normal presentation mode.
  • the intelligent document and the device it is provided that the checking step is carried out by means of the program module.
  • the program module in this embodiment is also designed to carry out the checking step, so that the intelligent document can check itself independently of the specific configuration of the presentation program.
  • a development of the method, of the intelligent document and of the device is characterized in that it is checked in the checking step whether the program execution environment is available.
  • This development has the advantage that it is checked whether the program execution environment is available, so that the user can be informed if necessary that the program execution environment is not present and therefore certain functions of the intelligent document are not available.
  • the verification step can not be performed directly by executing a program.
  • the indication of a negative result of the checking step can not be introduced into the intelligent document by means of the program module.
  • An embodiment of the method therefore comprises inserting into the intelligent document a displayable indication of a negative result of the checking step, and in that the program module is configured to convert the indication of the negative result of the checking step into a displayable indication of a positive result of the checking step ,
  • an embodiment of the intelligent document provides that the intelligent document contains a displayable indication of a negative result of the checking step, which can be converted by means of the program module into a displayable indication of a positive result of the checking step.
  • an embodiment of the device is characterized in that the device is designed to introduce a representable indication of a negative result of the checking step in the intelligent document, and that the program module is arranged to convert the presentable indication of the negative result of the checking step into an indication of a positive result of the checking step.
  • the test of whether the program execution environment is present can advantageously be made implicitly by means of the program module generating the indication of the result of the verification step within the smart document. This is achieved by virtue of the fact that, due to the execution of the program module, which can only take place when the program execution environment is available, an indication of a positive result of the checking step is produced by a conversion of an indication of a negative result of the checking step already present in the intelligent document. If the program execution environment is not available, the program module can not be executed and the indication of the negative result of the verification step is retained.
  • the program controls the one-time printing of a postage indicium and that the intelligent document is transmitted from a server to a client via a network.
  • An embodiment of the method, of the intelligent document and of the device is further characterized in that a message from the client is transmitted to the server at a first print of the postage indicium and that the print is logged in the server on the basis of the message. Further, it is provided in one embodiment of the method, the intelligent document and the device that the program for controlling the printing of the postage indicium is executable only if there is a network connection between the client and the server and if it is determined by means of a query of the server in that the franking mark has not yet been printed.
  • An embodiment of the method, the intelligent document and the device is characterized in that it is checked in the checking step, whether an access to the network exists.
  • the intelligent document and of the device includes that in the checking step a query of the server is made, in which it is checked whether contents of the intelligent document have already been printed once.
  • a further embodiment of the method, the intelligent document and the device includes that the program execution environment is part of the presentation program.
  • a computer program product which includes a computer program for carrying out a method of the kind described above.
  • FIG. 1 is a schematic representation of a user client connected to a server, from which intelligent documents can be transmitted to the user client;
  • FIG. 3 shows a schematic representation of an integration of a document generation into a system according to the invention
  • Fig. 4 is a flowchart of a preferred integration of payment transactions
  • Fig. 5 is an inventively produced label.
  • the invention includes various possibilities for generating a label that can be applied to a mailpiece.
  • the method for generating a label that can be applied to a mailpiece is developed further into a method for producing a mailpiece. If data contained in the label contains information relevant to the shipment, for example for payment assurance, shipment tracking or forwarding, the invention is also a method and a system for transporting mailpieces.
  • the static contents relate, for example, to frame information.
  • This frame information preferably forms a graphically displayable frame.
  • Dynamic content can be included in this framework.
  • FIG. 1 schematically shows a server.
  • the server is connected to a user client (user system) via a network.
  • the network is, for example, the Internet or an intranet.
  • Smart documents are sent from the server to a user client over the network. For this the
  • the server is a server that provides smart documents for label printing.
  • the server comprises a database with one entry for each label generated and sent to a user client.
  • the illustrated server is connected to a client via a network.
  • the network is, for example, the Internet or an intranet.
  • the client is a PC (personal computer).
  • a personal computer is only to be understood as an example. By this is meant any computing device that can perform processing operations. In particular, this includes systems that are different operating systems can work. For example, it is possible to use Windows, Mac or Linux operating systems.
  • the client (user client) is a computer that is connected via the Internet.
  • the connection to the server is made to increase data security in particular via https "hyper text transfer protocol” with encrypted transmission. This complicates "man in the middle” attacks.
  • the information is data that is created using the XML "Extended Markup Language”.
  • the data is transferred to the client via download.
  • the client installs an Adobe Reader version 6.0.2, a later version of this program, or Adobe Professional Software.
  • Content is opened via PDFs, via Adobe Reader, and then the dynamic contents (especially user-specific data) are loaded by soap call into the main memory of the Adobe Reader application and then sent to a printer together with the static data by a print job.
  • the client is equipped so that it has a display device and at least one input device and a memory and a processor.
  • stored in the memory is a presentation program that is executable within the client and capable of opening conventional documents of a particular format, such as PDF documents, and displaying their contents on the display device.
  • the presentation program allows the processing of intelligent documents, that is, it is designed to display displayable contents of intelligent documents on the display device and to execute programs contained in the intelligent document.
  • the presentation program provides a program execution environment that can be used to interpret and execute program instructions contained in programs.
  • the client is interfaced to a printing device and has a network interface for connection to the network.
  • the server has a device designed for example as a software program for generating intelligent documents.
  • the server is configured as a server providing intelligent documents for the printing of postage indicia.
  • the server comprises a database with one entry for each generated and sent to a client franking mark.
  • the intelligent documents include content which can be displayed by the presentation program on the display device and consist of text and / or graphic elements.
  • embedded in the intelligent documents are programs executable by the program execution environment of the presentation program.
  • the programs are scripts that contain the program code that can be interpreted by the program execution environment.
  • displayable contents of the intelligent documents can be changed.
  • the programs allow the execution of further processes, such as the control of the printing device for the printing of contents of the intelligent document or accesses to the network interface.
  • the program code is not displayed on the display device in the normal presentation mode of the presentation program. In principle, however, the presentation program can have a special presentation mode in which the program code can also be displayed.
  • an intelligent document provided by the server also contains status information for indicating the result of one or more checking steps.
  • Representable information of the test results are generated by means of one or more program modules, which are also included in the intelligent document.
  • the program modules may be self-contained programs or part of a program intended to carry out the main functionality of the intelligent document.
  • it is determined whether certain conditions exist for the use of the main functionalities of the intelligent document. In this way, in the case of unusable functionality, the user acquires particular knowledge of a possibly unfulfilled condition. He can use this knowledge to create the prerequisite for using the functionalities of the intelligent document.
  • a prerequisite for using the functionality of a smart document is the availability of the program execution environment.
  • not all presentation programs for presenting documents in the format of the intelligent document contain an appropriate program execution environment.
  • the program execution environment may not be present in older versions of the presentation program.
  • it is checked, in particular, whether the client's presentation program has a program execution environment suitable for executing the program contained in the intelligent document.
  • a displayable indication of a negative result of the checking step is already introduced in the document when the intelligent document is created.
  • a program module will be inserted in the intelligent document stating the negative result of the verification step in the
  • the intelligent document is preferably configured in such a way that the program module is automatically started when the intelligent document is opened in the presentation program while the program execution environment is present.
  • test of whether the program execution environment is available is preferably performed implicitly and gives a positive or negative result, depending on whether the program module can be executed or not.
  • this checking step in which a decision is made about the existence of the program execution environment, other checking steps can also be performed by means of a program contained in the intelligent document. The results of these test steps can then be presented in the same way by using a program module to convert the indication of a negative result into the statement of a positive result.
  • the conversion of the indication of the negative result of the checking step into the presentation of a positive result of the checking step can be done by changing the indication. For example, one or more characters may be added to the negative indication to produce an indication of a positive result of the verification step. Furthermore, the status indication may be colored, for example.
  • the conversion of the indication of the negative result of the checking step into an indication of a positive result can be effected here by a color change which is carried out by means of the program.
  • characters or symbols indicating the negative result of the test result are at least partially replaced by characters or symbols by means of which a positive result of the test step is displayed.
  • the presentation of the test results can be made visible or invisible to the user.
  • the intelligent documents comprise content which can be displayed on a display device by means of the presentation program and consists of text and / or graphic elements. Furthermore, programs are embedded in the intelligent documents. which are executable by the program execution environment of the presentation program.
  • the programs are scripts that include the program code that can be interpreted by the program execution environment.
  • displayable contents of the intelligent documents can be changed.
  • the programs allow the execution of further processes, such as the control of a printing device for the printing of contents of the intelligent document or accesses to the network interface.
  • the program code is not displayed on the display device in the normal presentation mode of the presentation program. In principle, however, the presentation program can present a special presentation mode in which the program code can also be displayed.
  • an intelligent document provided by the server also contains status information for indicating the result of one or more checking steps.
  • Representable information of the test results are generated by means of one or more program modules, which are also included in the intelligent document.
  • the program modules may be self-contained programs or part of a program intended to carry out the main functionality of the intelligent document.
  • it is determined whether certain conditions exist for the use of the main functionalities of the intelligent document. In this way, in the case of unusable functionality, the user acquires, in particular, knowledge of a possibly unfulfilled condition. He may use this knowledge to Creation and thus to use the functionalities of the intelligent document.
  • a prerequisite for using the functionality of a smart document is the availability of the program execution environment.
  • not all presentation programs for presenting documents in the smart document format contain an appropriate program execution environment.
  • the program execution environment may not be present in older versions of the presentation program.
  • it is checked in particular whether the presentation program of the user client has a program execution environment which is suitable for executing the program contained in the intelligent document.
  • a displayable indication of a negative result of the checking step is already introduced in the document when the intelligent document is created.
  • a program module is incorporated in the smart document that converts the indication of the negative result of the verification step into the indication of a successful execution of the verification step when it is executed.
  • the intelligent document is preferably configured in such a way that the program module is automatically started when the intelligent document is opened in the presentation program while the program execution environment is present.
  • test of whether the program execution environment is available is preferably performed implicitly and gives a positive or negative result, depending on whether the program module can be executed or not.
  • this checking step in which a decision is made about the existence of the program execution environment, other checking steps can also be performed by means of a program contained in the intelligent document. The results of these test steps can then be represented in the same way by using a program module to convert the indication of a negative result into the statement of a positive result.
  • the conversion of the indication of the negative result of the checking step into the presentation of a positive result of the checking step can be done by changing the indication. For example, one or more characters may be added to the negative indication to produce an indication of a positive result of the verification step. Furthermore, the status indication may be colored or remain invisible to the user, for example, except in the event that the test result is negative in order to inform the user about the negative test result.
  • the conversion of the indication of the negative result of the checking step into an indication of a positive result can be effected here by a color change which is carried out by means of the program.
  • characters or symbols indicating the negative result of the test result are at least partially replaced by characters or symbols by means of which a positive result of the test step is displayed.
  • This system includes a provider server and a network node (hereafter called Maptos).
  • Maptos stands for an external entry point into the POP application, and further access to the individual web pages of the POP application may be transparently channeled through Maptos.
  • Maptos refers to a network node for providing at least one Internet service that is executed in at least one provider server of a service provider.
  • a development of the network node Maptos comprises at least one external connector for receiving a service request whose generation can be initiated in a user computer of an internet marketplace user and for transmitting a processing result determined in the provider server to the user computer, wherein the external connector is capable of to make a format change of the service request and the processing result adapted to the Internet marketplace.
  • the network node such that it has a transformation unit connected to the outer connector for determining at least one provider server for executing the service on the basis of information contained in the service request and for addressing the service request to the determined provider server having.
  • a development of the network node comprises at least one inner connector connected to the transformation unit for transmitting the service request to the provider provider. ver and for receiving the determined in the provider server processing result from the provider server.
  • internet marketplace is to be understood in the context of the invention fertil in its broadest meaning and includes in particular web portals, such as auction portals sharing exchanges or discussion forums on the Internet and websites that are provided for example by online stores.
  • the network node makes it possible to provide Internet services provided by a service provider on an Internet marketplace without requiring adjustments of the provider servers that perform the Internet services to the Internet marketplace.
  • the interpretation of the service request, i. in particular, the required format changes, the determination of the provider server necessary for the execution of the service and the addressing of the service request to the provider server takes place in the network node, so that the information required to execute the internet service can be recorded in a marketplace-specific manner and incorporated into the service request, without the internet marketplace having to adapt to the requirements of the provider server.
  • the interface between the network node and the Internet marketplace is decoupled from the interface between the network node and the provider server, whereby a particularly great flexibility in the adaptation of the transformation node is achieved.
  • the POP server runs on multiple instances, e.g. within a BEA 9.x cluster.
  • An upstream web server is not required in a preferred embodiment of the invention if the application dynamically generates all data (HTML, PDF).
  • Sticky sessions are used to distribute HTTP regimes to each instance within the BEA cluster. Sticky sessions ensure that a single session of a user is always handled by the same cluster node.
  • the POP application uses a common database for all instances, such as Oracle 9.x or 10.x.
  • CronJob is a Java process that accesses the database of the POP server. This process can optionally also periodically delete old logging data.
  • Another batch job uses the data previously written by the POP server into the database for reporting specific data (called PAN data in the following) to third party systems (hereafter referred to as ECICC).
  • PAN data in the following
  • ECICC third party systems
  • Storage of POP server data outside of the database in a file system is possible but not required. It is advantageous that the EDICC module creates temporary files (/ tmp) for the sFTP protocol.
  • Batch jobs are written before a parallel, i. Protected against multiple starts, to prevent unwanted side effects.
  • FIG. 2 shows an overview of particularly advantageous interfaces.
  • the interfaces serve for a connection between a provider server according to the invention with a provider server
  • the invention advantageously takes place via the Internet.
  • the provider server can be connected to a client (user system).
  • the client is a user system that is equipped to receive data from the server and / or to communicate data to the server.
  • the client is a personal computer, a corporate network, or a mobile user terminal, such as a mobile phone.
  • the client is designed to include browser functionality.
  • this is a web browser
  • the list of mentioned browsers can be extended at any time to take account of developments.
  • HTTPS (POST, GET, XML)
  • HTTP can be used instead of HTTPS.
  • emails sent directly no codes, passwords or the like are sent, but only a link with an ID (preferably different from the transaction ID) embedded, which branches to an HTML page (N0W3).
  • the numbers generated by the application - vouchers, documents, shopping cart, PIN - are generated in such a way that they can not be guessed by the user.
  • these numbers are stored in the database and so their "consumption" controlled.
  • Access data required for the use of the external interfaces are stored in the database via a symmetric encryption method (contained in the web application). H. These can also not be viewed by a database administrator.
  • the standard mechanisms for securing the communication between the application and the payment platform are used.
  • the provider server contains only the data that is useful for carrying out the method. These are for example:
  • Data is not deleted in the database, but only in accordance with z. For example, an attribute is highlighted.
  • the subsequent access of a user to his shopping cart is made from a certain price volume via the additional input of a PIN or PIN2.
  • the configuration management with the time-dependent data (eg prices, vouchers) and the static resources is designed in such a way that once created and already productively switched configurations can no longer be removed from the database. Furthermore, the configuration data valid at that time can be reconstructed for each point in time in the past.
  • the user-visible interface of the application is essentially divided into the following websites:
  • This page shows the shopping cart and included items in an overview. The user can create or manipulate entries in the shopping cart and ultimately initiate payment.
  • NOWl Reload (for example, show error messages, redeem voucher)
  • the display of a single consignment of the basket consists of the following elements:
  • Recipient address consisting of the lines Namel, Name2, Street, House number, Postcode, City and Country (Country only, if not Germany).
  • Price cell o A total price including currency for the complete shipment. If no price can be determined, no price will be displayed. o If a voucher has already been redeemed for this shipment, the static text "voucher redeemed” appears. o Alternatively: Action: “Redeem voucher” (button “Ok”) with input field for the voucher number.
  • This entry appears after all consignment and voucher set items and only if a pickup for the shopping cart is booked. The displayed price will be recalculated every time the basket is changed.
  • the ad consists of the following elements:
  • the ad consists of the following elements:
  • the "Product” cell shows the static text "Discount” and the name of the corresponding discount definition.
  • the user can post individual services to a shipment item.
  • the change becomes active immediately after the selection, i. H. , the website will be reloaded after each action. If no corresponding product exists for the selected combination, an error message is displayed. In a particularly preferred embodiment, it can also be achieved by technical methods that no complete reload of a page is required to reconfigure a price.
  • the default address for the sender address is the address of the first program, if available.
  • the entry is a coupon number.
  • the voucher is assigned to the consignment in whose line the number was entered. If the code is incorrect, an error text such as "Invalid coupon code", "Coupon code expired” or "Coupon does not match the shipment” will be displayed at the defined location. If no product has been selected for the shipment, it will be set using the coupon code.
  • TAS collection If a TAS collection is included in the voucher, it will be automatically booked for the whole shopping cart.
  • the fetch address is not TAS-leitcodierbar.
  • NOWl is displayed again and a textual error message is displayed at the defined position. If successful, the application jumps to NOW3.
  • the user Via the pop-up window that appears, the user enters the collection date and the collection address. The costs for the TAS pickup will then be displayed in a separate shopping cart position.
  • the dynamic module NOWl is shown on the bottom left.
  • an input mask pop-up window
  • the user can use a drop-down list to enter a pickup date and a pickup address.
  • the date list contains n consecutive days in chronological, ascending order. The first day is preselected. Sundays are not offered in the list. Whether the next day is still displayed in the list is decided with the aid of a configurable time specification: If the current system time is still before this time, the next day is offered; otherwise at the earliest the next but one. The total number of entries in the list can also be configured.
  • the sender address of the first shipment is used as the initial default for the pickup address.
  • the window can only be exited with "Confirm" if the fetch address is coded in. In the event of an error, a message appears as shown in the screenshot.
  • the pickup address can not be coded.
  • the data of a shipment such as addresses and product can be captured and manipulated. If the product is not set, the product matching the recipient country (highest sorting key value) is preselected.
  • the sender and recipient address are recorded in the upper part of the page.
  • a drop-down list is offered for the sender and receiver country from which the user can select the country.
  • a free input is not possible, but generally conceivable. If there is no explicit indication for the country, "Germany" will be used as default.
  • the country list is stored in the system.
  • the possible basic products are displayed (usually always “parcel”, “parcel 10kg”, “parcel 20kg”, which are just examples of basic products), from which the user must select exactly one. If no product has been stored for the shipment, the first entry is automatically selected. When selecting a product, the page is updated and the product price valid for the selected product and the current combination of services is displayed.
  • the services available for the combination of recipient country and basic product are offered for selection.
  • the page is updated and the current price for the selected services is displayed.
  • the consignment will be updated and the shopping cart page NOWl will be displayed again.
  • This page contains user-acquired trademarks in the form of links to the PDF documents and, if applicable, a list of purchased coupon codes. It will be displayed after successful payment of the basket. Alternatively, the user can return to this page via a link in his confirmation e-mail.
  • the text display of the PDF links on the page is compiled in the following way: - Text "Label”, Recipient name, Recipient name2,
  • the user can also later access the NOW3 page via a link contained in the e-mail. If the shopping cart exceeds a certain minimum value, this access is secured by entering a PIN or PIN2 in the NOW3 login screen
  • a block describes a rectangular area of a website.
  • the content of the building block is static.
  • the building blocks can also be described in their nature only by data conventions, so that the design of the building blocks themselves can take place completely through a marketplace.
  • a building block can be dynamically loaded by the POP application and embedded in its own pages.
  • this module may contain a simple link to the shopping cart page (NOWI), via which a marketplace customer can access the POP application.
  • This module is displayed on the NOWl page bottom left.
  • a FAQ block Clicking on a question in the module opens a popup window with the FAQ text.
  • This e-mail consists of the following components:
  • the POP application can be addressed via Maptos, whereby initially the NOWl page is displayed. Alternatively, direct access to the NOW3 page - possibly with additional login via PIN or PIN2 - is possible via the link in the confirmation e-mail.
  • the service "pickup TAS" can only be selected completely for the entire shopping cart. Here an indication of a collection date is mandatory. In a further development, a time window for picking up a mail item can also be selected during pickup.
  • a single service is preferably defined using the following attributes.
  • Products can be administered country-specific.
  • a special identifier "EU” is introduced.
  • EU identifier
  • products can then be assigned to several countries at the same time.
  • the assignment "EU” is used only as long as no product is assigned to a "real" country.
  • Maptos do not contain a separate field for the house number. This is split off from the combined street number field analogously to the Leitcode library of Online Label Druck.
  • new marketplaces can be defined via the admin web.
  • the marketplaces are, for example, the provider shown.
  • the positive list contains all products available in the system. Each line describes a single product.
  • the "left" side product number, product name, baseline product, country) can occur multiple times, and the right-hand side of the table lines will indicate all valid combinations of services that can be assigned to this "left-hand side".
  • Each line always includes the base product itself.
  • the list it is useful to design the list so that it applies to all marketplaces.
  • the list and the system are matched to each other such that combinations not contained are invalid.
  • each line one or more countries can be referenced via a list of iso-codes (3-digit analog Maptos).
  • the special abbreviation "EU” stands for all EU countries (these are in a list).
  • each row of the positive list is assigned further attributes:
  • Product code (part of the guide code, 2 digits), process number (ESI and label printing),
  • Feature string label (required for label printing), sort key; determines the order of the display or which product is used as default.
  • the products can be selected depending on the recipient country: only the products that are assigned to this country are offered.
  • Objects that support this approach have an MZF (Marketplace TimeWindow) header that includes the following attributes:
  • the total price of a product line then results first from the sum of the individual prices.
  • the default price list (marketplace-independent) can look like this:
  • each base product and service with the exception of the TAS Pickup, must be priced as a "landless" entry. All other entries are optional. For example, if no price were defined for (package, DEU), the price of (package, *) would be used as default.
  • a suitable search order can be used to calculate a clear price for each line in the positive list (and, if applicable, depending on the marketplace and a point in time). This is simply the sum of the price for the base product + land and the associated services + land.
  • a special price for a packet DEU is defined (start and end of the period can be specified to the minute):
  • the current time (the server time is relevant here) is in the KW 49, i. outside the period for which Table III applies.
  • the destination country of the exemplary broadcast is Germany [DEU].
  • Example Results I (the Roman numerals behind the prices indicate the price table used).
  • the search criteria will be as above, but the current server time will be chosen as an adjustable time slot, for example a day, a week or a month.
  • Example Results II (the Roman numerals behind the prices indicate the price table used).
  • VAT liable yes / no (internal storage: ZERO or eg VAT-D)
  • Phase II an optional reference to a single positive list product; in this case, the line of the positive list to which the price belongs would be described; the base product / service attribute then describes the column within this row.
  • a pick-up takes place for parts of the basket or, what is particularly preferred, for the entire cart.
  • the collection of the pickup is done explicitly on the NOWl page or implicitly by entering a coupon code that includes a TAS pickup.
  • the invention is developed into a method for handling returns.
  • the prices for the collection are staggered (maximum 5 entries), for example as in the following table:
  • the number of all collectable shipments (based on positive list) in the shopping cart is used to find the price in the table. For more than 5 shipments, the last price of the table is used (according to the example table, a pickup from 5 shipments is always free of charge - which is an exemplary representation).
  • the price scale for the pickup can be specified hierarchically in the same way as the other prices.
  • Building blocks represent a rectangular area on a web page and can be configured hierarchically. They contain an HTML fragment, which in turn may be individual Images, css files, etc. can reference. Blocks are addressed by a logical name.
  • vouchers or their codes By selling vouchers on the web platform in packages, the customer should be able to enjoy price advantages. Furthermore, special marketing campaigns should be possible in which vouchers or their codes, for example, be distributed via print media.
  • vouchers Before vouchers can be purchased by the user or distributed as part of marketing campaigns, vouchers must be defined at the administrative level.
  • the coupon definition When the coupon definition is created, it is determined whether it is a promotional coupon or a coupon (code) to be purchased by the user.
  • a voucher can either represent an absolute amount of money ("value 10 Euro”) or be redeemable exactly for the product for which it is deposited ⁇ 100% voucher).
  • the 100% voucher covers the product "package including TAS pick-up", for the consignment in the shopping cart the product "package with TAS pick-up and roll” is selected by the user. As a result, the user only has to pay for the "role” service.
  • the "value" of a voucher can be exhausted incompletely, for example, if a voucher price is above the current price for "covered” products; the residual value of the voucher expires in this case.
  • the user can buy coupons in packages.
  • a denomination with up to 5 different denominations can be defined (eg "5s, 10s, 20s, 50s, 100s").
  • a separate absolute price is defined, including value added tax.
  • One of the denominations is defined as the default value.
  • a time window defines the period during which the coupon is offered for sale to the user.
  • the end of the time window can be limited or unlimited.
  • Purchasable coupons can only be redeemed after purchase, that is, only after they have been paid and are available to the user in the form of coupon codes.
  • a time window is used to set the period in which a single coupon code can be redeemed. Either this is a relative indication in days ("maximum 30 days after purchase redeem") or an absolute date ("until 31.12.2007”).
  • Purchase vouchers can only ever be used once. For promotional vouchers, you can alternatively specify whether the codes can be used any number of times. These are then redeemable for one or more shipments within a single basket of goods.
  • vouchers can be generated for print actions that can be used as often as desired.
  • promotion vouchers can also be generated for e-mail promotions, which can only be used once, just like purchase vouchers.
  • a coupon type can be assigned to a single marketplace.
  • the vouchers will then be offered for sale only on this marketplace.
  • the purchased coupon codes are redeemable exclusively on this one marketplace.
  • Each voucher is assigned a numerical sorting number, which can be used to determine the display order.
  • Voucher codes are generated either when purchasing a voucher or when generating promotion codes via the admin web.
  • a single coupon is defined by this unique alphanumeric identifier (coupon code), which should not be easily guessed.
  • the code is stored with associated data in the system.
  • Each newly created shopping cart is associated with the generation of a unique numeric shopping cart ID. This will be displayed to the customer on page NOW3. It also appears on the account statement of the user on successful booking. With this ID, users can refer to their shopping cart, for example, during telephone support inquiries.
  • Each shipment is checked to see if it is free of errors; This is possibly optimized via status information in the shipment position.
  • the information and error messages displayed per shipment are updated.
  • TAS pickup If the TAS pickup is booked, it is checked whether the pickup time is still valid and the pickup address is TAS-code, if this has not yet been checked. In the event of an error, the user is shown a shopping basket-related error message on NOWl.
  • a voucher code is redeemed for a consignment, it is checked on the basis of the data stored in the database whether it is valid: Is the code even a valid code, ie exists in the database?
  • Validation of the recipient addresses can be done in a call for n addresses).
  • the preliminary tests have shown that the data of the shopping basket are valid and the payment process can be prepared.
  • a link is embedded with an attached key, through which he can later open the page NOW3. If the shopping cart exceeds a certain value, this access is additionally secured by a PIN or PIN2 (four-digit numerical values).
  • the PIN is displayed by the user immediately after purchasing the shopping basket on page NOW3 - provided with a corresponding note text. Alternatively, he can also enter the PIN2 that he can find on his bank statement.
  • PDF Label generates PDFs with Labein, which are created by the
  • the PDF has the following components:
  • the actual postage label Label o as sample print and o as postage printing. - Consignment note.
  • a suitable PDF template for the generation of the label can - but does not have to - be stored in the application.
  • the product / logo block contains a logo of a company and the product name of the basic product.
  • the product name is determined from the product configuration.
  • product-specific characters can be printed.
  • the content of the impression is configured per product.
  • the following information is printed in the shipment information block:
  • the customer information block is not used by the application. It is advantageous to create a posting document.
  • This delivery document has a standard paper format (for example DIN A 6 to DIN A 4).
  • Preferred dates of the delivery receipt are:
  • the label to be printed is provided with a PDF envelope.
  • this envelope in communication with a license service, the printing of the document contained in the PDF envelope is controlled.
  • these documents are referred to in the present application as iPDF.
  • POP application During the generation (or possibly also in advance) of the PDF, every PDF is linked to a unique document ID that can not be guessed by the user through trial and error. On the one hand this document ID is 'embedded' in the iPDF, on the other hand it is also inserted in a database table of the POP application.
  • Fig. 3 shows a schematic representation of an integration of a document production in a system according to the invention.
  • the illustrated system includes a server that allows transfer of displayable content.
  • the content that can be displayed consists of static content and dynamic content.
  • the static contents are incorporated as PDF templates in a document to be generated.
  • Dynamic content is introduced from a suitable server, preferably a POP web server 302, into a document record 303. These dynamic contents may be supplemented by further contents. Other content may be static content or dynamic content, depending on the intended use. Addition of dynamic content is preferred as it allows to create identifiable documents in a particularly simple and convenient manner.
  • this is done by linking the dynamic contents to licensing information 304.
  • the invention will be explained below using the example of the production of labein.
  • the labein is, for example, address label and / or franking label.
  • Such labels are particularly suitable for controlling logistical processes, for example tracking and tracing, and for controlling logistical processes, for example for sorting mailpieces.
  • the labels are preferably made machine-readable.
  • the label to be printed is provided with a PDF envelope. Within this envelope, communication of the licensing information 304 is allowed in communication with the server.
  • a license service for printing the PDF envelope is thus provided.
  • the license service controls the printing of the document contained in the PDF envelope.
  • each PDF is linked to a unique, not to be guessed by the user by trying out the document ID.
  • This document ID is embedded on the one hand in the iPDF 'embedded 1 , on the other hand also in a database table of the POP application.
  • mechanisms are installed within the PDF delivered to the user, which check before every print whether the document has already been printed once.
  • Acrobat Reader must connect to a service provided by the POP application that will perform this check.
  • the server application generates a record for each PDF to be generated from the shopping cart, in which all the information required for the generation is already completely resolved.
  • FormularData keeps in a structured form (XML) all already resolved data regarding the data to be printed. So z. For example, the already generated packet identifiers, routing codes and evt. Further information (including prices, even if this is not currently provided) is already provided as numbers or strings. A subsequent calculation of such data is not provided, as this could possibly lead to different results.
  • XML structured form
  • the document record has, for example, the previously described field contents.
  • a PDF can be generated directly.
  • the servlet that delivers the PDF now only has to rename the file name for the PDF so that the document ID is in the file name.
  • the templates are signed offline during the development or preparation phase for a new product by the Acrobat Reader Extension Server.
  • the document signed by ARES 306 is then imported into the configuration repository in the application.
  • the envelope of the PDF is displayed on the first page.
  • a service provided by the application is called via the SOAP interface of the Acrobat Reader, which returns whether the submitted document ID exists and / or has already been marked as printed in the database.
  • the document ID then uses the SOAP interface to load the form fields from the POP server and fill them in the form fields.
  • the document ID could not be determined - e.g. since the user renamed the PDF document, he is prompted to enter the document ID via an Acrobat form field.
  • the document IDs will be sent to the user in the sent
  • E-mail additionally communicated.
  • the PDFs actually to be printed are stored as annotation form fields (originally intended for visual feedback - for example when a button is pressed - intended to distinguish between pressed and unpressed states) and only switched to "visible" immediately before printing.
  • Barcode fields Acrobat Reader supports form fields that display a corresponding barcode for a value (numerical value).
  • the barcode can be loaded as a bitmap image via an external URL.
  • a servlet service would have to be implemented in the application, which generates and makes available the corresponding bitmap.
  • the functionalities shown have several advantages: Since the user does not download individualized PDF, the PDFs only have to be signed per template / product via the ARES server.
  • the ARES 306 it is useful to use the ARES 306 to introduce new types of documents, especially when launching new service provider products, in order to sign the PDF once. Within the application, the signed document is then introduced as a resource. This installation of the ARES 306 can be done on any computer.
  • the interface for signing a document template can be simple.
  • Downloading PDFs is a simple - quasi-static - delivery of a file through the Pop application. Eventually performance-relevant processes for the impression are eliminated.
  • the PDFs can be created using standard tools provided by, for example, the Adobe company (Acrobat-Professional allows you to define the position of the form fields). Filling the PDF form fields within the Acrobat Reader is a standard feature.
  • Documents in the sense of the present invention are preferably graphically representable. Depending on the application, they can be detected manually or by machine. Depending on the field of use, it is also expedient to provide encryption.
  • the invention also includes documents that are not graphically representable. Documents within the meaning of the invention are in particular smart labels. Smart labels are RFID identification means (transponders). These are suitable for use of control processes in the processing or transport of physical objects, in particular postal items or other goods to be transported.
  • the servlet that delivers the PDF now just needs to rename the filename for the PDF so that the document ID is included in the filename.
  • the templates are signed offline during the development or preparation phase for a new product by the Acrobat Reader Extension Server.
  • ARES itself does not have to be installed in the product environment but must be installed externally on a simple PC with Linux.
  • a command line tool is used, with which one can provide any PDF documents with the necessary rights via the ARES.
  • the document signed by ARES is then imported into the configuration repository in the application.
  • the envelope of the PDF is displayed on the first page. The following checks are performed when loading the PDF in Acrobat Reader.
  • Acrobat Reader interface invokes a service provided by the application, which returns whether the submitted document ID exists and / or has already been marked as printed in the database.
  • the document ID then uses the SOAP interface to load the form fields from the POP server and fill them in the form fields.
  • the document ID could not be determined - e.g. since the user renamed the PDF document, he is prompted to enter the document ID via an Acrobat form field.
  • the document IDs are also communicated to the user in the e-mail sent to him.
  • the codes can be used for example as Leitcodmaschine. LeitCodmaschinen
  • the "Webbooking - Guidance Code Check (eShop, FBE) interface” interface is used to check the codecability of the pickup and recipient addresses.
  • eShop, FBE Guidance Code Check
  • For the generation of control codes for recipient addresses - which are also printed on the PDF label as a routing code or routing code as a barcode
  • the existing implementation of the Online Label Printing application is used in the current version.
  • the leading code module of the Online Label Printing application is used for the lead coding of the recipient addresses.
  • the pickup address and the recipient addresses are checked for Leitcodierles.
  • the interface does not return a routing code.
  • Non-Leitcodiersteade addresses are marked as such in the GUI.
  • an ID for the search address is defined.
  • the address with the same ID must be selected in the XML node ⁇ CheckedAddresses>. If the check status of this address is "OK", the address is code-codable. If one of the addresses can not be coded, the service is not available. error handling
  • NOWl there is a button Giropay and an input field for the bank code. This button does not branch directly to the Giropay page, but opens a popup asking the user to recheck his e-mail. If the user the correctness of his e-mail address confirmed, the NOWl page is reloaded. In this request cycle, the application checks the shopping cart again for possible price changes or other inconsistencies (missing information).
  • the cart persisted in the DB contains only the data that is necessary for the verification of the transaction and further steps after the payment (show NOW3, creation of the e-mail, etc.).
  • the following mandatory parameters are transmitted in a point-to-point connection via HTTPS with authentication.
  • the Giropay server responds with suitable parameters.
  • a BLZ was transferred, which does not participate in the giropay procedure.
  • the user receives the message "The bank does not participate in the giropay procedure" on the NOWl page.
  • the Pay-Solution server sends a confirmation of the payment to the UrI deposited in the Controlcenter (application of the payment provider). This could be defined as follows:
  • the application can now load the shopping cart (possibly HTTP session) from the database.
  • the application then checks to see if the amounts and currency specified match those in the shopping cart. Furthermore, a check is carried out via the Message Authentication Code (MAC), which is supplied in response.
  • MAC Message Authentication Code
  • NOW3 displays an error message and of course a corresponding message is logged.
  • POP In response to the feedback from the payment process, POP sends the PaySolution server the UrI for the return.
  • the PaySolution server makes a redirect in the user's browser to the sent UrI.
  • the return address looks like this, for example:
  • Another preferred payment system is the PayPal payment system.
  • the billing of a transaction is done with the PayPal option: "Buy Now and Donations".
  • the total amount incl. Tax is communicated to the PayPal system and billed.
  • the PayPal interface provides two methods for checking the status and correctness of the payment transaction.
  • PayPal addresses a fixed URL of the application defined in the merchant account configuration at PayPal. Parameters are used to transmit the status and data of the payment transaction to the application.
  • IPN is asynchronous to the payment process.
  • the time when an IPN is generated can not be guaranteed by PayPal.
  • the IPN is also processed by the application after the end of the user session.
  • an IPN is triggered immediately after the payment is confirmed on the PayPal pages.
  • step 5 a parameter set is transmitted via HTTPS in a point-to-point connection with the following parameters:
  • the return parameters in the PDT procedure are provided by PayPal as key-value pairs in the body of the response. Deviating from the IPN, a string is additionally transmitted in the PDT in the first line, which indicates with the value "SUCCESS" that the PDT request was technically successful.
  • the user is forwarded to PayPal through a POP post form.
  • PayPal optionally sends an IPN (Instant Payment Notification) to the application after the payment has been made, even before the user has been redirected back to the POP application. If the transaction is reported as Paid within the IPN, the actions for the delivery of the PDFs are made (EDICC, shipping e-mail, etc). This ensures that the user receives an e-mail even if he closes the browser immediately after paying at PayPal and the application no longer receives the redirect from PayPal to a POP site.
  • IPN Instant Payment Notification
  • PayPal directs the user via a post or redirect the user back to a page of the POP application.
  • the asynchronous incoming IPN and PDT must be synchronized via the database.
  • the application checks the shopping cart for possible price changes or other inconsistencies (missing information).
  • the persistent basket in the DB contains only the data necessary for the verification of the transaction and further steps after the payment (display N0W3, creation of the e-mail).
  • PayPal -Buy-Now HTML form is now deposited.
  • the destination URL of this form now points to the PayPal platform. This form is executed immediately via JavaScript, so that the browser immediately jumps to PayPal.
  • the session of the application is appended to the URL.
  • the application checks the payment transaction data. For this, the relation to the corresponding shopping cart in the database of the application is created via the parameter custom, which contains the Shopping BasketID.
  • the value of the mc_gross parameter is compared to the amount in the database.
  • the value of the parameter mc_currency is compared with the currency in the database.
  • the user can now download the PDF documents on N0W3.
  • the HTTP session If the user has canceled the payment process and the HTTP session is still valid, it will be redirected to NOWl with his shopping cart. If the user has aborted the payment process, but the session could not be continued due to a timeout within the application, the user will be notified N0W3 with a corresponding error message.
  • the administration system is an administration web.
  • the administration web is part of the POP web application.
  • the user administration of the administration web is controlled by a simple configuration file, which is managed versioned via the configuration repository.
  • Each user is assigned a list of roles. These roles correspond to the rights to use the individual components (ie masks) of the administration web.
  • the illustrated system makes it possible to carry out a method for producing a label that can be applied to a mail item in various convenient ways.
  • the method is performed such that a network node (Maptos) provides a data service that is executed in at least one provider server of a service provider, generating data for insertion into the label.
  • Maptos network node
  • the data service is an Internet service.
  • the generation of the label is controlled in such a way that printing of the label is only enabled when a test step has been carried out.
  • the test step serves, for example, to check the validity of a voucher or to check whether a requested franking label has been paid.
  • a program module is introduced into the intelligent document that is designed for this purpose is to produce a presentable indication of a result of the verification step or a further verification step for checking the existence of the prerequisite within the intelligent document.
  • One or more further testing steps may be performed in the provider server, the network node, or another server-based computing unit.
  • the checking step it is checked whether the program execution environment is available.
  • Server is sent over a network to a client.
  • the method is performed so that at a first pressure of the label, a message from the user client is transmitted to the server and that the pressure is logged due to the message in the server.
  • Label-based program so that it can only be executed if there is a network connection between the client and the server and if It was ascertained that the label has not yet been printed.
  • a refinement provides that in at least one of the checking steps, a query of the server is made, in which it is checked whether contents of the intelligent document have already been printed once.
  • the vouchers may be, for example, pre-paid postage amounts or credits for making order or delivery transactions.
  • the vouchers preferably contain valid information. In developments of the invention, they can also be used for payment processes.
  • the recipients of the consignments can create labels as users of the system. It is thus possible, in the manner according to the invention, to use labels as return labels for the return of postal items to a source label. sender, in particular a shipping company.
  • a coupon is transmitted to a user on a first transmission path. Later, in particular if the user desires a return of a mail item or of a product contained in it, the coupon (code) is transmitted to a server by a control unit located in an area of influence of the user.
  • This development of the invention provides for a multi-step generation of a label.
  • This multi-step generation is characterized in that a coupon is transmitted to a user on a first transmission path, that the coupon is transmitted to a server by an operating unit located in an area of influence of the user, and that the server performs a verification step to check the coupon and depending on the result of the checking step influences the generation of the label.
  • the transmission of the voucher to the user can be done in various ways.
  • a development of the invention provides that the coupon or a part of the coupon is transmitted to different transmission paths to the user.
  • a transmission to the user takes place even if the coupon or a component is transmitted to an operating unit located in an area of influence of the user. This is the case, for example, in the case of a transmission to a computer or a mobile user terminal, such as a mobile telephone.
  • a development of the method, the computer program product and the device is characterized in that the coupon is attached to a mail addressed to the user.
  • An embodiment of the method, the computer program product and the device provides that the coupon is transmitted electronically to the user.
  • a development of the method, the computer program product and the device is characterized in that the coupon is transmitted to the user when an event occurs.
  • An embodiment of the method, the computer program product and the device provides that the coupon is transmitted upon the occurrence of a shipping event.
  • a development of the method, the computer program product and the device is characterized in that the coupon is transmitted to a request.
  • An embodiment of the method, the computer program product and the device provides that the operating unit is a computer.
  • a development of the method, the computer program product and the device is characterized in that the Check step includes a validity check of the voucher.
  • An embodiment of the method, the computer program product and the device provides that the checking step includes a validity check of the voucher.
  • a development of the method, the computer program product and the device is characterized in that, taking into account the voucher, a recipient address for the mail item is determined.
  • An embodiment of the method, the computer program product and the device provides that, taking into account the voucher, a sender address for the mail item is determined.
  • the invention also includes documents that are not graphically representable. Documents within the meaning of the invention are, in particular, also smart labels. Smart labels are RFID identifiers (transponders). These are suitable for use of control processes in the processing or transport of physical objects, in particular postal items or other goods to be transported.
  • identification data are preferably recognized by the fact that a signature is created for the respective dynamic content and that this signature is transmitted with the respective dynamic content.
  • the signature is expediently recreated in the destination of a respective communication (target system) and the Resulting value - in particular hash value - compared with the value resulting from the transmitted signature.
  • the invention also includes using other programs than those shown.
  • a selection of the software should be made so that a file can be generated with it, which has the following properties:
  • a print dialog should be controllable via the application logic.
  • the file should be transferable as read-only.
  • the file should be protected against modification of the application logic / before or during execution (especially during printing).
  • the documents are able to check which version or which implementation of a computer program and / or which operating system are installed on a client.
  • the invention is not limited to the illustrated applications.
  • these contain information for the identification, for the routes, for advance orders and for the extras associated with the mailing order.
  • the labels prefferably contain customer and / or billing information.
  • the illustrated labels serve as information carriers and allow, for example, an acceptance, payroll, sorting, loading, special treatment, delivery, issue, billing, research, postprocessing, operating data processing, tracking and tracing and archiving a shipment.
  • the intelligent documents - in particular the labels for application to the mailpieces - have information blocks in further developments of the invention.
  • Examples of dynamic content introduced into the static framework are the recipient address and indications that allow for shipment identification, for example, a shipment identification number.
  • the transmitted frame information serves for a clear, structured and formatted presentation of the dynamic contents.
  • FIG. 5 shows a graphical representation of intelligent documents produced according to the invention.
  • the graphic representations For example, they can be displayed on a screen of a client or printed out and optionally printed out for use as a shipping label for a mailing.
  • static content is transmitted separately from the dynamic content.
  • the static contents are, for example, the frames shown in the figures and company details such as "DHL".
  • Dynamic contents that are introduced into the mailings are, for example, sender information, recipient information, invoice number, size information, shipment identification number and / or possibly also a product name.
  • 5 shows the label content by way of example in a DIN A 4 horizontal format, lying next to one another.
  • the dynamic contents are transmitted in a continuation of the invention by a client of a shipping process (shipper) in electronic form.
  • Transmission of the shipment data may take place before, during and after physical delivery of the shipments to a shipping company. Simultaneous electronic and physical transmission is, however, preferred for simplification of the logistical processes.
  • a suitable number range is preferably specified.
  • the label handling information for example, for employees of the shipping company, in particular a deliverer - included. It is possible and expedient to select a format deviating from other label contents for the graphical representation of individual handling functions.
  • the invention is not limited to the illustrated types of transmission, formats or test steps.
  • the person skilled in the art recognizes that within the scope of the invention, other types of transmission can also be selected and / or other formats used and / or other test steps can be carried out, the results of which are optionally presented in the document.
  • the invention can also be used in areas other than those shown. For example, it is possible to check the existence of the program execution environment on any intelligent document and present the result of the test.
  • the intelligent documents can, for example, be intelligent documents with animated graphics or forms.
  • the invention can be used with forms that are used in communication with authorities and executed as intelligent documents. On the basis of the test steps, the results of which are presented in the invention, it can be checked in particular whether certain mandatory fields of a form have been completed.
  • the invention can also be used in intelligent documents that are protected by the "intelligence" from unauthorized access.
  • texts may be mentioned which can only be displayed and / or printed if the user is authorized to do so, whereby the authorization of the user is checked by the intelligent document, for example by a server query taking place via a network.
  • Returns logistics processes are logistic processes for the handling of returns.
  • the invention includes both the development of a logistics system as a returns logistics system and the design of a logistics system with handling operations for handling returns.
  • the invention includes a logistics system for conveying a mail piece on a transport path within a postal distribution network, wherein the transport path contains a plurality of nodes of the postal distribution network, in particular a node that corresponds to a delivery point.
  • the transport path additionally contains one or more nodes, each corresponding to a sorting point.
  • logistics system is to be understood in the context of the invention in a broad meaning.
  • it comprises systems which contain the means and facilities for carrying out the transport of mailpieces from a point of departure to a delivery point on a transport path within a postal distribution network.
  • the point of departure is, for example, a storage location or place of delivery of the object to be transported.
  • the delivery point is preferably selected by the client of the transport. For a return, this is for example a warehouse of a dealer or manufacturer.
  • this is expediently achieved by transmitting a coupon to a user on a first transmission path, transmitting the coupon to a server by means of a control unit located in an area of influence of the user, and the server executing a check step for verifying the coupon and depending on the result of the test step affects the generation of the label.
  • the transmission of the voucher is expediently carried out upon the occurrence of a mailing event, for example when the mail item addressed to the user is delivered, during a transport or processing step of the mail item or when the item of mail is delivered to the user.
  • the invention includes various ways of transmitting the voucher and allows for integration of different transmission paths.
  • the verification step is carried out in such a way that it includes a validity check of the voucher.
  • a recipient address for the mail item is determined.
  • a sender address for the mail item is determined.
  • End user who uses the POP application to buy brands or coupons.
  • Block Rectangular static area in a web page that can be displayed in a time- and market-driven way.
  • EKP number A kind of customer number for the marketplace.
  • Remuneration insurance (means for determining abusive label.
  • Voucher An instance of a voucher type can have a unique
  • a class of a coupon A class of a coupon.
  • Product A combination of base product and services; is identified by a product key.
  • Product key Unique key for a basic product / service combination. Service Priced property of a product.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Erzeugen eines auf eine Postsendung aufbringbaren Labels. Dieses Verfahren zeichnet sich dadurch aus, dass ein Netzwerkknoten (Maptos) einen Datendienst bereitstellt, der in einem Anbieterserver eines Dienstanbieters ausgeführt wird, wobei Daten zum Einbringen in das Label erzeugt werden. Die Erfindung betrifft ferner ein Computerprogrammprodukt, einen Netzwerkknoten und ein System zum Erzeugen eines auf eine Postsendung aufbringbaren Labels.

Description

Verfahren zum Erzeugen eines Labels, Computerprogrammprodukt, Netzwerkknoten und System zur Durchführung des Verfahrens
Technisches Gebiet
Die Erfindung betrifft ein Verfahren zum Erzeugen eines auf eine Postsendung aufbringbaren Labels.
Die Erfindung betrifft ferner ein Computerprogrammprodukt, einen Netzwerkknoten und eine Vorrichtung zur Durchführung des Verfahrens .
Hintergrund und Stand der Technik
Es ist bekannt, Postsendungen mit Labein zu versehen. Derartige Label werden beispielsweise durch eine geeignete Datenverarbeitungseinheit - zum Beispiel einen Personalcomputer - erzeugt.
Darstellung der Erfindung
Es ist wünschenswert, in das Label möglichst automatisch für einen Versand der Postsendung relevante Informationen einzubringen.
Daher ist es eine Aufgabe der vorliegenden Erfindung, ein Verfahren zum Erzeugen eines auf eine Postsendung aufbringbaren Labels so durchzuführen beziehungsweise ein System zum Erzeugen eines auf eine Postsendung aufbringbaren Labels so auszugestalten, dass ein hoher Bedienkomfort für einen Benutzer mit einem hohen Schutz vor Manipulationen verbunden wird. Erfindungsgemäß wird diese Aufgabe durch ein Verfahren mit den Merkmalen des Patentanspruchs 1, ein Computerprogrammprodukt nach Anspruch 14, einen Netzwerkknoten nach Anspruch 15 sowie durch ein System nach Anspruch 16 gelöst.
Somit wird ein Verfahren zum Erzeugen eines Labels so durchgeführt, dass ein Netzwerkknoten einen Datendienst bereitstellt, der in wenigstens einem Anbieterserver eines Dienstanbieters ausgeführt wird, wobei Daten zum Einbringen in das Label erzeugt werden .
Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich da- durch aus, dass der Datendienst ein Internetdienst ist.
Es ist insbesondere zweckmäßig, das Verfahren, das Computerprogrammprodukt, den Netzwerkknoten und/oder das System für eine Erstellung von Rücksendelabeln einzusetzen.
Rücksendelabel sind Label, die es einem Benutzer des Computersystems ermöglichen, von ihm erhaltene Postsendungen an einen Absender zurückzusenden.
Eine Fortentwicklung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass ein Prüfungsschritt zur Überprüfung eines Gutscheins durchführt und in Abhängigkeit von dem Ergebnis des Prüfungsschritts das Erzeugen des Labels beeinflusst wird.
Eine Weiterbildung des Verfahrens , des Computerprogrammprodukts , des Net zwerkknotens und des Systems zeichnet sich dadurch aus , dass in einem dem Prüfungsschritt vorangehenden Verfahrensschritt der Gutschein an einen Benutzer übermittelt wird.
Eine Fortentwicklung des Verfahrens, des Computerprogrammpro- dukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass ein Programmmodul in das intelligente Dokument eingebracht wird, das dazu ausgebildet ist, eine darstellbare Angabe eines Ergebnisses des Prüfungsschrittes oder eines weiteren Prüfungsschritts zur Prüfung des Vorliegens der Voraus- setzung innerhalb des intelligenten Dokuments zu erzeugen.
Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass wenigstens einer der Prüfungsschritte mittels des Programmmoduls durchgeführt wird.
Eine Fortentwicklung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass in dem Prüfungsschritt überprüft wird, ob die Programmausführungsumgebung zur Verfügung steht.
Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass ein Programm einen einmaligen Druck des Labels steuert und dass ein intelligentes Dokument von einem Server über ein Netzwerk an einen Client übermittelt wird.
Eine Fortentwicklung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich da- durch aus, dass bei einem ersten Druck des Labels eine Nachricht von dem Nutzerclient an den Server übermittelt wird und dass der Druck aufgrund der Nachricht in dem Server protokol- liert wird.
Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich da- durch aus, dass das Programm zur Steuerung des Drucks des Labels nur dann ausführbar ist, wenn eine Netzwerkverbindung zwischen dem Client und dem Server besteht und wenn anhand einer Abfrage des Servers festgestellt worden ist, dass das Label noch nicht gedruckt worden ist.
Eine Fortentwicklung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass in wenigstens einem der Prüfungsschritte überprüft wird, ob ein Zugriff auf das Netzwerk besteht.
Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts, des Netzwerkknotens und des Systems zeichnet sich dadurch aus, dass in wenigstens einem der Prüfungsschritte eine Abfrage des Servers vorgenommen wird, bei der überprüft wird, ob Inhalte des intelligenten Dokuments bereits einmal gedruckt worden sind.
Eine Weiterbildung der Erfindung beinhaltet ein System, das Kunden ermöglicht, Label mittels eines PC, der im Folgenden als Nutzerclient bezeichnet wird, über eine Online-Schnittstelle anzufordern und zu drucken. Die Schnittstelle wird von einem Server bereitgestellt, der im Folgenden als POP-Server (POP: Parcel Online Postage) bezeichnet wird.
Zur Erzeugung der Label generiert der Kunde zunächst einen oder mehrere Einträge für zu versendende Postsendungen in einem Warenkorb auf einer ersten von dem POP-Server bereitgestellten Webseite (nachfolgend NOW 1 genannt) . Hierzu enthält die Webseite NOW 1 einen Button, über den der Nutzer auf eine weitere Internetseite ( nachfolgend NOW2 genannt, die Sendungs-Details darstellt) zugreifen kann, auf der Daten einer Sendung erfasst und manipuliert werden können.
Die Daten umfassen beispielsweise die Absenderadresse, die Empfängeradresse und eine Auswahl der Produkte und Services sowie der Zielländer, aus der sich insbesondere auch der Portowert für die Sendung ergibt. Ferner kann der Nutzer einen oder mehrere Zusatzservices für die Sendungen angeben. Hierunter fallen zum Beispiel ein Rollenservice für runde Verpackungen oder ein spezifischer Sperrgutservice, wobei diese Ausprägungen nur beispielhaft für weitere Zusatzservices stehen.
Wenn der Warenkorb wenigstens einen Eintrag enthält, ist auf der Webseite NOW 1 ein weiterer Button aktiv, über den der Kunde einen Bezahlvorgang einleiten kann. Dieser erfolgt anhand eines Online-Zahlungsverfahrens, wobei der Kunde insbesondere zwischen verschiedenen Online-Überweisungsformen wäh- len kann, worunter zum Beispiel der Bezahldienst PayPal oder eine Kreditkartenzahlung subsumiert werden kann, wobei diese Zahlverfahren nur beispielhaft erwähnt sind.
Nach erfolgter Bezahlung des Warenkorbs gelangt der Kunde auf eine Webseite (nachfolgend NOW 3 genannt) , die Links zu PDF- Dokumenten enthält, welche den Druck der erworbenen Frankierlabel ermöglichen. Ferner wird nach der Bezahlung eine E-Mail an Kunden gesendet, die einen Link auf die Webseite NOW 3 enthält, über den die Webseite auch zu einem späteren Zeitpunkt wieder aufgerufen werden kann. Die E-Mail wird an eine Adresse gesendet, die der Kunde zuvor auf der Webseite NOW 1 eingegeben hat. Überschreitet der Wert des Warenkorbs einen bestimmten Betrag, so wird der Zugriff auf die Webseite NOW 3 über den in der E-Mail enthaltenen Link durch eine PIN abgesichert, der dem Nutzer auf der Seite NOW 3 dargeboten, aber nicht per E-Mail übermittelt wird.
Eine Weiterbildung der Erfindung beinhaltet eine Gutscheinfunktionalität, die es einem Kunden ermöglicht, Gutscheine zu erwerben und für die Bezahlung von Frankiervermerken einzusetzen. Die Gutscheine können dem Warenkorb auf der Webseite NOW 1 hinzugefügt werden. Über einen entsprechenden Button auf dieser Webseite gelangt der Nutzer auf eine weitere Webseite (NOW 2 - Gutschein-Details) , auf der dem Warenkorb Gutschein- Sets für ein ebenfalls auf dieser Seite ausgewähltes Basisprodukt hinzugefügt werden können. Nach der Bezahlung des Warenkorbs wird dem Benutzer auf der Webseite NOW 3 eine Möglich- keit geboten, die erworbenen Gutscheincodes anzuzeigen oder zu speichern. Zur späteren Einlösung des Gutscheins wird der Gutscheincode von dem Kunden bei der Generierung des Warenkorbs auf der Webseite NOW 1 eingegeben.
Die Erfindung eignet sich für eine Erstellung unterschiedlicher Label, insbesondere zur Erzeugung von Labein zur Steuerung von logistischen Funktionen der Postsendungen, insbesondere ihrer Beförderung, Sortierung und/oder Weiterleitung. Die Label enthalten hierfür beispielsweise geldwerte Informationen als Zahlungsnachweis, so dass es sich beispielhaft um Frankierlabel handelt.
Es ist jedoch gleichfalls möglich, dass die Label weitere Informationen zur Handhabung der Postsendungen - beispielsweise eine Absenderadresse, eine Empfängeradresse, einen Sendungs- identifikationscode oder weitere die Sendung beschreibende Daten (z.B. Gewicht oder Abmaße) - beinhalten. Hierdurch ist ein Einsatz der Label zu einer Überwachung des Sendungsverlaufs (Tracking) beziehungsweise zu einem Nachweis des Sendungsverlaufs (Tracing) möglich.
In einer bevorzugten Ausgestaltung enthalten die Label neben der Anschrift des Empfängers und des Absenders einen der Empfängeradresse zugeordneten Leitcode, der bei der Produktion der Postsendungen in einem Paket- bzw. BriefZentrum eines Versanddienstleisters genutzt wird.
In einer besonders bevorzugten Ausführungsform beinhaltet das Label einen eindeutigen Labelidentifikationscode. Anhand des Labelidentifikationscodes können Missbrauchsfälle ermittelt werden, bei denen ein Frankierlabel mehrfach für die Frankierung von Postsendungen verwendet wird. Hierzu werden die La- belidentifikationscodes der ausgegebenen Frankierlabel in einem Entgeltsicherungssystem gespeichert. Bei der Produktion einer Sendung wird der Labelidentifikationscode in dem Entgeltsicherungssystem als verwendet markiert. Ferner wird für jede produzierte Sendung überprüft, ob der Labelidentifikati- onscode als ungültig markiert ist. Ist dies der Fall, wird ein Missbrauchsfall festgestellt. Leitcode und Labelidentifikationscode werden sowohl in Klarschrift als auch in Form eines Barcodes in das Label eingebracht. Die Frankierlabel werden dem Kunden anhand von intelligenten PDF-Dokumenten bereitge- stellt.
Die Erfindung beinhaltet verschiedene Ausführungsformen zur Erzeugung des Labels und zu seinem Ausdruck. Besonders bevorzugte Ausführungsformen sind nachfolgend genannt :
Nach der Bezahlung des Warenkorbs durch den Kunden erhält der POP-Server eine Benachrichtigung über die erfolgte Zahlungstransaktion von dem Zahlungsprovider. Daraufhin wird in einer Dokumentendatenbank ein Datensatz für das von dem Kunden erworbene Frankierlabel erzeugt. Der Datensatz enthält insbesondere einen eindeutigen Dokumentenidentifikationscode für das intelligente PDF-Dokument, eine Angabe darüber, ob das Label bereits mit gültigen Codes gedruckt worden ist, sowie Formulardaten. Die Formulardaten umfassen die Absender- und Empfängeradresse der zu frankierenden Postsendungen, den Leitcode. Zudem beinhalten die Formulardaten den Labelidentifikationscode, der nach der Bezahlung aus einem Pool mit zuvor generier- ten Codes entnommen wird. Dieser Code wird zudem auch an das Entgeltsicherungssystem übertragen. Ferner wird ein intelligentes PDF-Dokument erzeugt, bei dem es sich um ein leeres Formular mit Formularfeldern für die zuvor genannten Formulardaten handelt . Als Bezeichnung des PDF-Dokuments dient der Do- kumentenidentifikationscode.
Der Druck des Labels erfolgt im Rahmen des iPDF-Mechanismus anhand einer Kommunikation zwischen dem Nutzerclient und dem POP-Server bzw. einem mit dem POP-Server verbundenen Lizenz- server, der auf die Dokumentendatenbank zugreifen kann. Für die Kommunikation zwischen dem Nutzerclient wird die SOAP- Schnittstelle des Acrobat Readers genutzt. Nach dem Öffnen des PDF-Dokuments wird zunächst sukzessive geprüft, ob eine Internetverbindung vorhanden ist, ob der Dokumentenidentifikations- code gültig ist und ob das Label nicht bereits gedruckt worden ist. Zur Durchführung der letzten beiden Prüfungsschritte wird über die SOAP-Schnittstelle des Acrobat Readers ein Service des POP-Servers aufgerufen, der nach einer entsprechenden Abfrage der Datenbank zurückmeldet, ob ein Datensatz für den Do- kumentenidentifikationscode in der Dokumentendatenbank vorhanden ist, und ob der Frankiervermerk bereits als gedruckt markiert worden ist. Nach erfolgreicher Durchführung der Prüfungsschritte werden die in der Datenbank gespeicherten Formulardaten mit Ausnahme der gültigen Codes über die Schnittstelle des Acrobat Readers vom POP-Server geladen und in die Formularfelder des PDF- Dokuments eingebracht. Anstelle der gültigen Codes enthält das PDF-Dokument zunächst nur Dummy-Codes, um zu verhindern, dass der Nutzer eine Kopie eines gültigen Labels anfertigen kann. Ferner ist der Inhalt des Dokuments zunächst deutlich als Muster markiert. Für den Druck stellt das PDF-Dokument eine eige- ne Funktionalität bereit, bei der Testdrucke sowie ein Druck eines gültigen Labels - nachfolgend Portodruck genannt - über entsprechende Schaltflächen innerhalb des Dokuments durchgeführt werden können. Bei einem Testdruck wird das zunächst in dem PDF-Dokument enthaltene Muster des Labels mit den Dummy- Codes gedruckt. Bei einem Portodruck wird das gültige Label gedruckt, wobei die gültigen Barcodes nach einer Betätigung der entsprechenden Schaltfläche von dem POP-Server abgerufen werden. Ferner wird aufgrund der Betätigung der Schaltfläche für den Portodruck in der Dokumentendatenbank des POP-Servers eingetragen, dass ein Druck des gültigen Labels erfolgt ist und die Schaltfläche wird ausgeblendet bzw. funktionslos geschaltet .
Bei einem erneuten Öffnen des Dokuments nach einem Portodruck wird anhand der zunächst durchgeführten Prüfungsschritte festgestellt, dass das Label bereits einmal ausgedruckt worden ist. Zumindest ein Portodruck wird in diesem Fall nicht mehr gestattet .
Das Label kann unterschiedliche Gestalt aufweisen. Es ist vorzugsweise so gestaltet, dass es eine Identifikation und/oder Steuerung von Postsendungen und gegebenenfalls auch die Koordination eines Lagerplatzes ermöglicht. Zweckmäßigerweise sind die Label kratz- und schlagfest sowie temperaturbeständig .
Beispiele derartiger Label sind:
• Barcode-Label,
• EAS-Etiketten,
• Etiketten für Warenverfolgung, • intelligente Etiketten,
• Inventuretiketten,
• Palettenetiketten,
• Sicherheitsetiketten,
• Thermoetiketten, • Thermotransferetiketten,
• Transponderetiketten.
In die Label werden codierte Informationen als Steuerungsinstrumente für die Paketlogistik eingebracht.
Insbesondere können die Label eine fortlaufende Nummerierung - gegebenenfalls mit PrüfZiffer -, sonstige Nummerierungen sowie Adressangaben oder sonstige Informationen, die die Sendung klassifizieren oder beispielsweise zu Werbezwecken dienen, enthalten.
Besonders umfassende Datenmengen können in Smart -Label eingebracht werden.
RFID-Identifikationssysteme - "Smart-Label " - ermöglichen eine Optimierung der logistischen Vorgänge. Sie sind damit ein geeignetes Mittel zur Beeinflussung - einschließlich Steuerung flexibler Distributionssysteme für die wegeoptimierte Bereitstellung der Postsendungen.
Eine Übermittlung des Labels an die Bedieneinheit erfolgt vorzugsweise in Form eines intelligenten Dokuments.
In einer Weiterbildung der Erfindung wird ein intelligentes Dokument eingesetzt, das ein Programm umfasst, das bei Vorlie- gen einer Voraussetzung mittels einer Programmausführungsumgebung ausführbar ist und das mittels eines Darstellungsprogramms darstellbare Inhalte enthält. Das intelligente Dokument zeichnet sich dadurch aus, dass ein Programm-Modul enthalten ist, das dazu ausgebildet ist, eine darstellbare Angabe eines Ergebnisses des Prüfungsschritts zur Prüfung des Vorliegens der Voraussetzung innerhalb des intelligenten Dokuments zu erzeugen.
Eine weitere Ausgestaltung des Verfahrens, des intelligenten Dokuments und der Vorrichtung beinhaltet, dass die Programmausführungsumgebung Bestandteil des Darstellungsprogramms ist.
Nach dem Erwerb eines Artikels durch einen Käufer - beispielsweise durch das Ende einer Auktion oder den Erwerb zu einem Festpreis bei z.B. einem Versandhändler - beginnt für den Verkäufer der Prozess der Versandabwicklung, der durch die vorliegende Erfindung optimiert wird. Alternativ kann auch unabhängig von einem oben beschriebenen Geschäftsvorfall ein Label erzeugt werden, das z.B. privaten Versandzwecken dient oder das Ziel hat ein Frankiervermerk mit dem Ziel zu erzeugen, dieses für den Rückversand eines oder mehrerer Artikel an einen Versender zu nutzen. Vorzugsweise werden die versand- und/oder frankierrelevanten Daten vom Versandinformationssystem bzw. der Listingtools automatisiert - d.h. ohne weiteres Zutun des Verkäufers - über eine Schnittstelle an ein Mittel zur Erstellung eines Labels (Labelerstelldienst) übergeben.
Ein Einsatz der Erfindung in Systemen zum Erzeugen von Labein oder anderen Aufdrucken zum Versehen von Postsendungen oder anderen zu transportierenden Gütern ist besonders vorteilhaft.
Ein Label ist vorzugsweise eine grafische Darstellung - beispielsweise ein Ausdruck oder eine Bildschirmdarstellung eines intelligenten Dokuments.
Eine Weiterbildung der Erfindung beinhaltet ein Verfahren zum Erzeugen eines intelligenten Dokuments, das ein Programm um- fasst, das bei Vorliegen einer Voraussetzung mittels einer Programmausführungsumgebung ausführbar ist und das mittels eines Darstellungsprogramms darstellbare Inhalte enthält.
Eine bevorzugte Ausführungsform der Erfindung zeichnet sich dadurch aus, dass die darstellbaren Inhalte aus statischen Inhalten und dynamischen Inhalten bestehen, wobei ein Einbringen der dynamischen Inhalte in das intelligente Dokument von einem Einbringen der statischen Inhalte getrennt erfolgt.
In diesem Fall ist es besonders vorteilhaft, dass Adressdaten und/oder frankierrelevante Daten Beispiele dynamischer Inhalte im Sinne bevorzugter Weiterbildungen der Erfindung sind. Eine Weiterbildung der Erfindung eignet sich jedoch auch für einen Einsatz anderer dynamischer Informationen und in anderen technischen Zusammenhängen, beispielsweise für eine Automatisierung von sonstigen Logistikvorgängen, von Produktionsvor- gangen sowie von der Erzeugung und Verarbeitung von Informationen. Besonders vorteilhaft sind Einsatzgebiete, bei denen dynamische Informationen in einem statischen Rahmen wiedergegeben und/oder bearbeitet werden.
Bei den statischen Informationen handelt es sich um Angaben, die insbesondere ein Einbetten von Daten ermöglichen.
Bei den Rahmen kann es sich beispielsweise auch um so genannte
Frames handeln.
Ein Frame ist ein Teilbereich einer graphischen Darstellung, insbesondere einer Bildschirmseite, beispielsweise einer grafischen Benutzeroberfläche. Ein einzelnes Segment wird dabei als Frame (englischer Ausdruck für Rahmen) bezeichnet, die De- finition aller Frames als Frameset.
Der Einsatz von Frames ermöglicht die parallele Darstellung von mehreren Einzeldokumenten, die sich gegebenenfalls unabhängig voneinander verschieben lassen. Über die Frames lassen sich Inhalte aus unterschiedlichen Quellen bzw. aus verschiedenen Datenquellen miteinander kombinieren.
Ferner können Inlineframes (iframes) eingesetzt werden. Sie erlauben eine besonders einfache Dateneinbindung in eine dar- gestellte Bildschirmseite.
Demgemäß wird ein Verfahren der eingangs genannten Art geschaffen, bei dem das intelligente Dokument ein Programm um- fasst, das bei Vorliegen einer Voraussetzung mittels einer Programmausführungsumgebung ausführbar ist und das mittels eines Darstellungsprogramms darstellbare Inhalte enthält.
Erfindungsgemäß wird das Verfahren so durchgeführt, dass zwei verschiedene Arten von Inhalten in das intelligente Dokument eingebracht werden, die aus einer oder mehreren Quellen stammen können .
Bei einer ersten Art von Inhalten handelt es sich um statische Inhalte. Statische Inhalte stimmen vorzugsweise bei mehreren Dokumenten überein.
Bei den statischen Inhalten handelt es sich vorzugsweise um solche Inhalte, die sich für eine Erzeugung mehrerer Dokumente eignen. Eine Erzeugung mehrerer Dokumente ist sehr vorteilhaft, jedoch nicht notwendig.
Bei den statischen Inhalten handelt es sich beispielsweise um Rahmeninformationen für die Erzeugung von Dokumenten oder um andere Informationen, deren Aktualisierung seltener als bei den dynamischen Inhalten, vorzugsweise erst bei Ablauf eines vorgebbaren Zeitintervalls oder bei Erreichen eines Ereignisses, erfolgt. Alternativ ist es möglich, die statischen Daten vollständig unverändert zu lassen.
Ferner wird ein intelligentes Dokument geschaffen, das ein Programm umfasst, das bei Vorliegen einer Voraussetzung mittels einer Programmausführungsumgebung ausführbar ist, und das mittels eines Darstellungsprogramms darstellbare Inhalte enthält. Das intelligente Dokument zeichnet sich dadurch aus, dass ein Programmmodul enthalten ist, das dazu ausgebildet ist, eine darstellbare Angabe eines Ergebnisses des Prüfungsschritts zur Prüfung des Vorliegens der Voraussetzung innerhalb des intelligenten Dokuments zu erzeugen.
Eine Ausführungsform der Erfindung sieht vor, dass das Programmmodul ein Bestandteil der statischen Inhalte ist.
Eine Weiterbildung der Erfindung zeichnet sich dadurch aus, dass das Programmmodul ein Bestandteil der dynamischen Inhalte ist.
Eine besonders bevorzugte Ausführungsform der Erfindung sieht vor, dass das Programmmodul entweder Bestandteil der dynamischen Inhalte oder der statischen Inhalte ist.
Zudem wird eine Vorrichtung zum Erzeugen eines intelligenten Dokuments geschaffen, das ein Programm umfasst, das bei Vorliegen einer Voraussetzung mittels einer Programmausführungs- Umgebung ausführbar ist, und das mittels eines Darstellungs- programms darstellbare Inhalte enthält. Die Vorrichtung ist dazu eingerichtet, ein Programmmodul in das intelligente Dokument einzubringen, das dazu ausgebildet ist, eine darstellbare Angabe eines Ergebnisses des Prüfungsschritts zur Prüfung des Vorliegens der Voraussetzung innerhalb des intelligenten Doku- ments zu erzeugen.
Eine Weiterbildung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass in dem intelligenten Dokument selbst ein Programmmo- dul enthalten ist, mit dem eine Angabe des Ergebnisses eines Prüfungsschritts erzeugt werden kann. Hierdurch ist das intelligente Dokument selbst zur Angabe des Ergebnisses eines Prü- fungsschritts in der Lage, so dass das Ergebnis des Prüfungsschritts unabhängig von der Konfiguration des Darstellungsprogramms angezeigt wird.
Unter einer darstellbaren Angabe innerhalb eines intelligenten Dokuments wird im Rahmen der Erfindung eine Angabe verstanden, die mittels des Darstellungsprogramms beispielsweise an einem Bildschirm angezeigt werden kann. Intelligente Dokumente können neben den darstellbaren Inhalten weitere Inhalte, wie bei- spielsweise Programmcodes enthalten, die zumindest in einem normalen Darstellungsmodus nicht mittels eines Darstellungs- programms angezeigt werden.
Das erfindungsgemäße Verfahren zum Erzeugen eines intelligen- ten Dokuments, das ein Programm umfasst, das bei Vorliegen einer Voraussetzung mittels einer Programmausführungsumgebung ausführbar ist, das mittels eines Darstellungsprogramms darstellbare Inhalte enthält, kann auf verschiedene Weise fortgebildet werden.
Eine Weiterbildung des Verfahrens, des intelligenten Dokuments und der Vorrichtung sieht vor, dass die statischen Inhalte von einem Server über ein Netzwerk an einen Client übermittelt werden .
Eine Ausgestaltung des Verfahrens, des intelligenten Dokuments und der Vorrichtung sieht vor, dass die dynamischen Inhalte von einem Server über ein Netzwerk an den Client übermittelt werden.
Hierdurch ist eine besonders rasche Dokumentenerzeugung möglich. Eine unabhängig von einer Übermittlung oder NichtÜbermittlung der statischen Inhalte erfolgende Übermittlung der dynamischen Inhalte hat den Vorteil, dass der Datenübertragungsaufwand für die Erzeugung eines intelligenten Dokuments verringert wird.
Dieser Vorteil ist noch ausgeprägter, falls mehrere intelligente Dokumente erzeugt werden.
Bei einer Erzeugung mehrerer intelligenter Dokumente ist es vorteilhaft, einmal die statischen Inhalte zu übertragen und diese mit verschiedenen dynamischen Inhalten zu verschiedenen intelligenten Dokumenten zu kombinieren.
So ist es möglich, mit einmal erzeugten statischen Inhalten mehrere voneinander verschiedene intelligente Dokumente zu erzeugen.
Eine Weiterbildung des Verfahrens, des intelligenten Doku- ments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass die statischen Inhalte und die dynamischen Inhalte getrennt voneinander übertragen werden.
Eine Weiterbildung des Verfahrens, des intelligenten Doku- ments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass die Übertragung zeitlich getrennt erfolgt.
Eine Ausgestaltung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung zeich- net sich dadurch aus, dass die Übertragung auf verschiedenen Übertragungswegen erfolgt . Eine Weiterbildung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass die statischen Inhalte von einer anderen Datenquelle bereitgestellt werden als die dynamischen Inhalte.
Eine Ausgestaltung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung zeichnet sich dadurch aus, dass die statischen Inhalte von einem ersten Server und dass die dynamischen Inhalte von einem ande- ren Server übertragen werden.
Eine Weiterbildung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass die statischen Daten in einem Bereich eines Clients gespeichert werden.
Dies hat den Vorteil, dass die statischen Daten auf eine besonders einfache und vorteilhafte Weise für eine Erzeugung mehrerer - vorzugsweise verschiedener - intelligenter Dokumen- te bereitstehen.
Eine Nutzung der Dokumente erfolgt insbesondere durch einen Client. Der Client steht vorteilhafterweise einem Benutzer des Systems zur Verfügung und wird deshalb in der vorliegenden An- meidung auch als Nutzerclient bezeichnet.
Der Client ist vorzugsweise so ausgestattet, dass er erkennt, ob er sich bei dem übermittelten Dokument um ein intelligentes Dokument handelt. Dies geschieht bei einer Weiterbildung der Erfindung dadurch, dass ein Vorhandensein einer Bestätigungsinformation überprüft wird. Bei der Bestätigungsinformation handelt es sich beispielsweise um eine Signatur. Eine Ausführungsform des Verfahrens, des intelligenten Dokument, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass der Client bei dem Öffnen eines Dokuments prüft, ob es signiert wurde.
In einer Weiterbildung der Erfindung wird - vorzugsweise durch einen weiteren Prüfungsschritt - überprüft, ob die Signatur, mit der das Dokument signiert wurde, gültig ist.
Die statischen Inhalte werden vorzugsweise getrennt von den dynamischen Inhalten übertragen. Die statischen Inhalte sind beispielsweise Layoutinformationen zur Gestaltung des Dokuments .
Weiterbildungen der Erfindung sehen vor, die statischen Inhalte teilweise, überwiegend oder vollständig anders zu bearbeiten als die dynamischen Inhalte.
Beispielsweise unterscheiden sich die statischen Inhalte von den dynamischen Inhalten durch den Zeitpunkt der jeweiligen Erzeugung .
Ferner können sich die statischen Inhalte und die dynamischen Inhalte auch durch das sie jeweils auslösende Ereignis voneinander unterscheiden.
Eine Weiterbildung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass die statischen Inhalte bei Vorliegen eines ersten Ereignisses übermittelt werden. Eine Ausgestaltung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung zeichnet sich dadurch aus, dass die statischen Informationen bei Vorliegen eines Ereignisses einer ersten Ereignisart übermit- telt werden.
Eine Weiterbildung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass die dynamischen Inhalte bei Vorliegen eines zweiten Ereignisses übermittelt werden.
Eine Ausgestaltung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung zeichnet sich dadurch aus, dass die dynamischen Informationen bei Vorliegen eines Ereignisses einer zweiten Ereignisart übermittelt werden.
Eine Weiterbildung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass ein Vorliegen des zweiten Ereignisses unter Berücksichtigung eines Prüfungsschritts ermittelt wird.
Eine Ausgestaltung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung zeich- net sich dadurch aus, dass sich das erste Ereignis von dem zweiten Ereignis unterscheidet.
Eine Weiterbildung des Verfahrens, des intelligenten Dokuments, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass sich die erste Ereignisart von der zweiten Ereignisart unterscheidet. Ferner wird ein intelligentes Dokument geschaffen, das ein Programm umfasst, das bei Vorliegen einer Voraussetzung mittels einer Programmausführungsumgebung ausführbar ist, und das mittels eines Darstellungsprogramms darstellbare Inhalte ent- hält. Das intelligente Dokument zeichnet sich dadurch aus, dass ein Programmmodul enthalten ist, das dazu ausgebildet ist, eine darstellbare Angabe eines Ergebnisses des Prüfungsschritts zur Prüfung des Vorliegens der Voraussetzung innerhalb des intelligenten Dokuments zu erzeugen.
Zudem wird eine Vorrichtung zum Erzeugen eines intelligenten Dokuments geschaffen, das ein Programm umfasst, das bei Vorliegen einer Voraussetzung mittels einer Programmausführungs- Umgebung ausführbar ist, und das mittels eines Darstellungs- Programms darstellbare Inhalte enthält. Die Vorrichtung ist dazu eingerichtet, ein Programmmodul in das intelligente Dokument einzubringen, das dazu ausgebildet ist, eine darstellbare Angabe eines Ergebnisses des Prüfungsschritts zur Prüfung des Vorliegens der Voraussetzung innerhalb des intelligenten Doku- ments zu erzeugen.
Eine Weiterentwicklung der Erfindung der Erfindung besteht darin, dass in dem intelligenten Dokument selbst ein Programmmodul enthalten ist, mit dem eine Angabe des Ergebnisses eines Prüfungsschritts erzeugt werden kann. Hierdurch ist das intelligente Dokument selbst zur Angabe des Ergebnisses eines Prüfungsschritts in der Lage, so dass das Ergebnis des Prüfungs- schritts unabhängig von der Konfiguration des Darstellungsprogramms angezeigt wird.
Unter einer darstellbaren Angabe innerhalb eines intelligenten Dokuments wird im Rahmen der Erfindung eine Angabe verstanden, die mittels des Darstellungsprogramms beispielsweise an einem Bildschirm angezeigt werden kann. Intelligente Dokumente können neben den darstellbaren Inhalten weitere Inhalte, wie beispielsweise Programmcode enthalten, die zumindest in einem normalen Darstellungsmodus nicht mittels Darstellungsprogramms angezeigt werden.
Innerhalb der Prüfungsschritte wird vorteilhaft überprüft werden, ob bestimmte Voraussetzungen für die Nutzung der Funktio- nalität des intelligenten Dokuments vorliegen. Sind diese Voraussetzungen erfüllt, wird ein positives Ergebnis des Prüfungsschritts angezeigt. Falls die Voraussetzungen nicht erfüllt sind, wird ein negatives Prüfungsergebnis angezeigt, so dass der Nutzer Kenntnis darüber erhält, welche Voraussetzung nicht erfüllt ist. Diese Kenntnis kann er dazu nutzen, die entsprechende Voraussetzung zu schaffen.
In einer Ausführungsform des Verfahrens, des intelligenten Dokuments und der Vorrichtung ist es vorgesehen, dass der Prü- fungsschritt mittels des Programmmoduls durchgeführt wird.
Vorteilhaft ist das Programmmodul in dieser Ausgestaltung auch zur Durchführung des Prüfungsschritts ausgebildet, so dass sich das intelligente Dokument unabhängig von der speziellen Konfiguration des Darstellungsprogramms selbst prüfen kann.
Eine Weiterbildung des Verfahrens, des intelligenten Dokuments und der Vorrichtung zeichnet sich dadurch aus, dass in dem Prüfungsschritt überprüft wird, ob die Programmausführungsum- gebung zur Verfügung steht. Diese Weiterbildung hat den Vorteil, dass geprüft wird, ob die Programmausführungsumgebung zur Verfügung steht, so dass der Nutzer gegebenenfalls darüber informiert werden kann, dass die Programmausführungsumgebung nicht vorhanden ist und daher be- stimmte Funktionen des intelligenten Dokuments nicht verfügbar sind.
Falls die Programmausführungsumgebung nicht zur Verfügung steht, kann der Prüfungsschritt jedoch nicht direkt durch die Ausführung eines Programms vorgenommen werden. Ebenso kann die Angabe eines negativen Ergebnisses des Prüfungsschritts nicht mittels des Programmmoduls in das intelligente Dokument eingebracht werden.
Eine Ausführungsform des Verfahrens beinhaltet daher, dass in das intelligente Dokument eine darstellbare Angabe eines negativen Ergebnisses des Prüfungsschritts eingebracht wird, und dass das Programmmodul dazu ausgebildet wird, die Angabe des negativen Ergebnisses des Prüfungsschritts in eine darstellba- re Angabe eines positiven Ergebnisses des Prüfungsschritts umzuwandeln.
Ferner sieht eine Ausführungsform des intelligenten Dokuments vor, dass das intelligente Dokument eine darstellbare Angabe eines negativen Ergebnisses des Prüfungsschritts enthält, die mittels des Programmmoduls in eine darstellbare Angabe eines positiven Ergebnisses des Prüfungsschrittes umwandelbar ist.
Zudem ist eine Ausführungsform der Vorrichtung dadurch gekenn- zeichnet, dass die Vorrichtung dazu ausgebildet ist, eine darstellbare Angabe eines negativen Ergebnisses des Prüfungs- schritts in das intelligente Dokument einzubringen, und dass das Programmmodul dazu eingerichtet ist, die darstellbare Angabe des negativen Ergebnisses des Prüfungsschritts in eine Angabe eines positiven Ergebnisses des Prüfungsschritts umzuwandeln.
Bei diesen Ausführungsformen kann die Prüfung, ob die Programmausführungsumgebung vorhanden ist, vorteilhaft implizit mittels des Programmmoduls vorgenommen werden, das die Angabe des Ergebnisses des Prüfungsschritts innerhalb des intelligen- ten Dokuments erzeugt. Dies wird dadurch erreicht, dass aufgrund der Ausführung des Programmmoduls, die nur bei verfügbarer Programmausführungsumgebung erfolgen kann, eine Angabe eines positiven Ergebnisses des Prüfungsschritts durch eine Umwandlung einer bereits in dem intelligenten Dokument vorhande- nen Angabe eines negativen Ergebnisses des Prüfungsschritts erzeugt wird. Falls die Programmausführungsumgebung nicht verfügbar ist, kann das Programmmodul nicht ausgeführt werden, und die Angabe des negativen Ergebnisses des Prüfungsschritts bleibt erhalten.
Bei einer Weiterbildung des Verfahrens, des intelligenten Dokuments und der Vorrichtung ist es vorgesehen, dass das Programm den einmaligen Druck eines Frankiervermerks steuert und dass das intelligente Dokument von einem Server über ein Netz- werk an einen Client übermittelt wird.
Eine Ausführungsform des Verfahrens, des intelligenten Dokuments und der Vorrichtung zeichnet sich weiterhin dadurch aus, dass bei einem ersten Druck des Frankiervermerks eine Nach- rieht von dem Client an den Server übermittelt wird und dass der Druck aufgrund der Nachricht in dem Server protokolliert wird. Ferner ist es bei einer Ausgestaltung des Verfahrens, des intelligenten Dokuments und der Vorrichtung vorgesehen, dass das Programm zur Steuerung des Drucks des Frankiervermerks nur dann ausführbar ist, wenn eine Netzwerkverbindung zwischen dem Client und dem Server besteht und wenn anhand einer Abfrage des Servers festgestellt wird, dass der Frankiervermerk noch nicht gedruckt worden ist .
Hierdurch wird verhindert, dass ein einmal bezahlter Frankiervermerk mehrfach ausgedruckt wird.
Eine Ausgestaltung des Verfahrens, des intelligenten Dokuments und der Vorrichtung ist dadurch gekennzeichnet, dass in dem Prüfungsschritt überprüft wird, ob ein Zugriff auf das Netzwerk besteht .
Zudem beinhaltet eine Weiterbildung des Verfahrens, des intelligenten Dokuments und der Vorrichtung, dass in dem Prüfungs- schritt eine Abfrage des Servers vorgenommen wird, bei der ü- berprüft wird, ob Inhalte des intelligenten Dokuments bereits einmal gedruckt worden sind.
Eine weitere Ausgestaltung des Verfahrens, des intelligenten Dokuments und der Vorrichtung beinhaltet, dass die Programmausführungsumgebung Bestandteil des Darstellungsprogramms ist.
Darüber hinaus wird ein Computerprogrammprodukt bereitgestellt, das ein Computerprogramm zur Ausführung eines Verfah- rens der zuvor beschriebenen Art enthält.
Diese und weitere Vorteile, Besonderheiten und zweckmäßige Weiterbildungen der Erfindung werden auch anhand der Ausfüh- rungsbeispiele deutlich, die im Folgenden unter Bezugnahme auf die Figuren beschrieben werden.
Kurze Beschreibung der Figuren
Von den Figuren zeigt :
Fig. 1 eine schematische Darstellung eines Nutzerclients, der mit einem Server verbunden ist, von dem intelligente Dokumente an den Nutzerclient übermittelbar sind;
Fig. 2 eine Übersicht über erfindungsgemäß eingesetzte Schnittstellen;
Fig. 3 eine schematische Darstellung einer Integration einer Dokumentenerzeugung in ein erfindungsgemäßes System;
Fig. 4 einen Ablaufplan einer bevorzugten Integration von Zahlungsvorgängen und
Fig. 5 ein erfindungsgemäß erzeugtes Label.
Darstellung der Erfindung anhand der Figuren
Die Erfindung beinhaltet vielfältige Möglichkeiten zur Erzeugung eines auf eine Postsendung aufbringbaren Labels. Durch das Aufbringen des Labels auf eine Postsendung wird das Verfahren zum Erzeugen eines auf eine Postsendung aufbringbaren Labels zu einem Verfahren zur Erstellung einer Postsendung weiterentwickelt . Falls in dem Label enthaltene Daten sendungsrelevante Informationen enthalten, beispielsweise zur Entgeltsicherung, Sendungsverfolgung oder Weiterleitung, handelt es sich bei der Erfindung auch um ein Verfahren und ein System zum Transport von Postsendungen.
Nachfolgend werden besonders bevorzugte Ausführungsformen der Erfindung dargestellt, bei denen ein einfaches und sicheres Einbringen von Inhalten in die Label mit einem besonders hohen Nutzen für den Transport der Postsendungen verbunden wird.
Bei der Erzeugung der Label ist es besonders vorteilhaft, sowohl dynamische Inhalte als auch statische Inhalte in die Label einzubringen.
Die statischen Inhalte betreffen beispielsweise Rahmeninformationen. Diese Rahmeninformationen bilden vorzugsweise einen graphisch darstellbaren Rahmen.
Dynamische Inhalte können in diesen Rahmen eingebracht werden.
Es ist vorteilhaft, dass die dynamischen Inhalte bei Auftreten eines Ereignisses - beispielsweise bei erfolgter Durchführung eines Prüfungsschritts - übermittelt werden.
Erfindungsgemäß sind verschiedene Lösungen für die Übernahme von dynamischen Inhalten vorgesehen.
So ist es beispielsweise möglich, dynamische Inhalte unmittel - bar vor einer Bildschirmdarstellung und /oder vor einem Druckvorgang zu übermitteln. Dies kann beispielsweise auf eine der folgenden Arten geschehen:
per Textdatei (csv) , - durch Direktübertragung aus einer Datenbank oder über SOAP-Calls.
In Figur 1 ist schematisch ein Server dargestellt.
Der Server ist über ein Netzwerk mit einem Benutzerclient (Benutzersystem) verbunden. Bei dem Metzwerk handelt es sich beispielsweise um das Internet oder ein Intranet.
Intelligente Dokumente werden von dem Server über das Netz- werk an einen Nutzerclient übermittelt. Hierzu verfügt der
Server über eine beispielsweise als Softwareprogramm ausgebildete Einrichtung zur Erzeugung intelligenter Dokumente.
In einer Ausführungsform ist der Server als Server ausgebil- det, der intelligente Dokumente für den Druck von Labelen bereitstellt. In dieser Ausführungsform umfasst der Server eine Datenbank mit jeweils einem Eintrag für jedes erzeugte und an einen Nutzerclient übermittelte Label.
Der dargestellte Server ist über ein Netzwerk mit einem Client verbunden. Bei dem Netzwerk handelt es sich beispielsweise um das Internet oder ein Intranet. Bei dem Client handelt es sich beispielsweise um einen PC (Personal Computer) .
Der Einsatz eines Personalcomputers ist lediglich beispielhaft zu verstehen. Hiermit ist jede Datenverarbeitungseinheit gemeint, die Bearbeitungsvorgänge ausführen kann. Insbesondere sind hierbei Systeme inbegriffen, die mit voneinander ver- schiedenen Betriebssystemen arbeiten können. Beispielsweise ist es möglich, Windows, Mac oder Linux-Betriebssysteme einzusetzen .
Insbesondere handelt es sich bei dem Client (Nutzerclient) um einen Computer, der über das Internet angeschlossen ist. Die Verbindung mit dem Server erfolgt zur Erhöhung der Datensicherheit insbesondere via https "hyper text transfer Protocol" mit verschlüsselter Übertragung. Dies erschwert "Man in the Middle" Attacken.
Es ist vorteilhaft, SOAP-Calls zusätzlich noch mit einer eigenen Signatur zu versehen und Informationen nur dann zu verarbeiten, wenn die jeweils angebrachte Signatur als gültig er- kannt wurde.
Bei den Informationen handelt es sich beispielsweise um Daten die mit der XML "Extended Markup Language" erstellt werden.
Es ist vorteilhaft, einen Datenaustausch entsprechend SOAP "Simple Object Access Protocol" durchzuführen.
In einer bevorzugten Ausführungsform werden die Daten auf den Client per Download übertragen.
Auf dem Client ist beispielsweise ein Adobe-Reader, Version 6.0.2, eine jüngere Version dieses Programms oder Adobe Professional Software installiert. Inhalte werden über PDFs, per Adobe-Reader geöffnet und anschließend werden die dynamische Inhalte (insbesondere anwenderspezifische Daten) per Soap-Call in den Hauptspeicher der Anwendung Adobe-Reader geladen und dann zusammen mit den statischen Daten durch einen Druckauftrag an einen Drucker geschickt . Zweckmäßigerweise ist der Client so ausgestattet, dass er über eine Anzeigeeinrichtung und wenigstens eine Eingabeeinrichtung sowie über einen Speicher und einen Prozessor verfügt . In dem Speicher ist insbesondere ein Darstellungsprogramm gespeichert, das in dem Client ausführbar ist und dazu in der Lage ist, herkömmliche Dokumente eines bestimmten Formats, wie beispielsweise PDF-Dokumente zu öffnen und deren Inhalt an der Anzeigeeinrichtung darzustellen. Ferner erlaubt das Darstel- lungsprogramm die Verarbeitung von intelligenten Dokumenten, d.h., es ist dazu ausgebildet, darstellbare Inhalte von intelligenten Dokumenten an der Anzeigeeinrichtung darzustellen und Programme auszuführen, die in dem intelligenten Dokument enthalten sind. Hierfür stellt das Darstellungsprogramm eine Programmausführungsumgebung bereit, mit der in den Programmen enthaltene Programmbefehle interpretiert und ausgeführt werden können. Darüber hinaus ist der Client über eine Schnittstelle mit einer Druckeinrichtung verbunden und verfügt über eine Netzwerkschnittstelle zur Verbindung mit dem Netzwerk .
Intelligente Dokumente werden von dem Server über das Netzwerk an den Client übermittelt. Hierzu verfügt der Server über eine beispielsweise als Softwareprogramm ausgebildete Einrichtung zur Erzeugung intelligenter Dokumente. In einer Ausführungsform ist der Server als Server ausgebildet, der intelligente Dokumente für den Druck von Frankiervermerken bereitstellt. In dieser Ausführungsform umfasst der Server eine Datenbank mit jeweils einem Eintrag für jeden erzeugten und an einen Client übermittelten Frankiervermerk.
Die intelligenten Dokumente umfassen Inhalte, die mittels des Darstellungsprogramms an der Anzeigeeinrichtung dargestellt werden können und aus Text- und/oder Grafikelementen bestehen. Ferner sind in die intelligenten Dokumente Programme eingebettet, die mittels der Programmausführungsumgebung des Darstellungsprogramms ausführbar sind. Bei den Programmen handelt es sich um Skripte, die den Programmcode umfassen, der von der Programmausführungsumgebung interpretiert werden kann. Anhand der Programme können darstellbare Inhalte der intelligenten Dokumente verändert werden. Ferner ermöglichen die Programme die Ausführung weiterer Prozesse, wie beispielsweise die Ansteuerung der Druckeinrichtung für den Druck von Inhalten des intelligenten Dokuments oder Zugriffe auf die Netzwerkschnittstelle. Der Programmcode wird in dem normalen Darstellungsmodus des Darstellungsprogramms nicht an der Anzeigeeinrichtung dargestellt. Grundsätzlich kann jedoch das Darstellungsprogramm über einen Sonderdarstellungsmodus verfügen, in dem auch der Programmcode darstellbar ist.
Ein von dem Server bereitgestelltes intelligentes Dokument enthält im Rahmen der vorliegenden Erfindung ferner eine Statusinformation zur Angabe des Ergebnisses eines oder mehrerer Prüfungsschritte. Darstellbare Angaben der Prüfungsergebnisse werden dabei mittels eines oder mehrerer Programmmodule erzeugt, die ebenfalls in dem intelligenten Dokument enthalten sind. Die Programmmodule können als eigenständige Programme ausgebildet oder Teil eines Programms sein, das zur Ausführung der Hauptfunktionalität des intelligenten Dokuments vorgesehen ist. Innerhalb der Prüfungsschritte wird ermittelt, ob bestimmte Voraussetzungen für die Nutzung der Hauptfunktionali- täten des intelligenten Dokuments vorliegen. Hierdurch erlangt der Nutzer im Falle einer nicht nutzbaren Funktionalität ins- besondere Kenntnis einer möglicherweise nicht erfüllten Voraussetzung. Diese Kenntnis kann er verwenden, um die Voraussetzung zu schaffen und so die Funktionalitäten des intelligenten Dokuments zu nutzen. Eine Voraussetzung für die Nutzung der Funktionalität eines intelligenten Dokuments ist die Verfügbarkeit der Programmausführungsumgebung. In der Regel enthalten jedoch nicht alle Darstellungsprogramme zur Darstellung von Dokumenten im Format des intelligenten Dokuments eine geeignete Programmausfüh- rungsUmgebung . So kann die Programmausführungsumgebung beispielsweise in älteren Versionen des Darstellungsprogramms nicht vorhanden sein. In einer Ausführungsform wird daher in einem Prüfungsschritt insbesondere geprüft, ob das Darstellungsprogramm des Clients über eine Programmausführungsumgebung verfügt, die zur Ausführung des in dem intelligenten Dokument enthaltenen Programms geeignet ist. Um das Ergebnis dieses Prüfungsschritts auch dann korrekt darstellen zu kön- nen, wenn die Programmausführungsumgebung nicht vorhanden ist, wird bereits bei der Erstellung des intelligenten Dokuments eine darstellbare Angabe eines negativen Ergebnisses des Prüfungsschritts in das Dokument eingebracht. Ferner wird in das intelligente Dokument ein Programmmodul eingebracht, das die Angabe des negativen Ergebnisses des Prüfungsschritts in die
Angabe einer erfolgreichen Durchführung des Prüfungsschritts umwandelt, wenn es ausgeführt wird. Das intelligente Dokument wird dabei vorzugsweise so konfiguriert, dass das Programmmodul nach dem Öffnen des intelligenten Dokuments in dem Dar- Stellungsprogramm bei vorhandener Programmausführungsumgebung automatisch gestartet wird.
Die Prüfung, ob die Programmausführungsumgebung zur Verfügung steht, wird vorzugsweise implizit durchgeführt und liefert ein positives oder negatives Ergebnis, je nachdem ob das Programmmodul ausgeführt werden kann oder nicht. Neben diesem Prüfungsschritt, in dem eine Entscheidung über das Vorhandensein der Programmausführungsumgebung getroffen wird, können gleichfalls andere Prüfungsschritte mittels eines in dem intelligenten Dokument enthaltenen Programms ausgeführt werden. Die Ergebnisse dieser Prüfungsschritte können dann in der gleichen Weise dargestellt werden, indem mittels eines Programmmoduls eine Umwandlung der Angabe eines negativen Ergebnisses in die Angabe eines positiven Ergebnisses vorgenommen wird.
Die Umwandlung der Angabe des negativen Ergebnisses des Prüfungsschritts in die Darstellung eines positiven Ergebnisses des Prüfungsschritts kann durch eine Veränderung der Angabe erfolgen. Beispielsweise können der negativen Angabe eine oder mehrere Zeichen hinzugefügt werden, um eine Angabe eines positiven Ergebnisses des Prüfungsschritts zu erzeugen. Ferner kann die Statusangabe beispielsweise farbig ausgebildet sein. Die Umwandlung der Angabe des negativen Ergebnisses des Prüfungsschritts in eine Angabe eines positiven Ergebnisses kann hierbei durch eine Farbänderung erfolgen, die mittels des Programms vorgenommen wird. Darüber hinaus kann es auch vorgesehen sein, dass Zeichen oder Symbole der Angabe des negativen Ergebnisses des Prüfungsergebnisses zumindest teilweise durch Zeichen oder Symbole ersetzt werden, mittels derer ein positi- ves Ergebnis des Prüfungsschritts dargestellt wird. Die Darstellung der Prüfergebnisse kann hierbei für den Nutzer sichtbar oder unsichtbar erfolgen.
Die intelligenten Dokumente umfassen Inhalte, die mittels des Darstellungsprogramms an einer Anzeigeeinrichtung dargestellt werden können und aus Text- und/oder Grafikelementen bestehen. Ferner sind in die intelligenten Dokumente Programme eingebet- tet, die mittels der Programmausführungsumgebung des Darstellungsprogramms ausführbar sind.
Bei den Programmen handelt es sich beispielsweise um Skripte, die den Programmcode umfassen, der von der Programmausführungsumgebung interpretiert werden kann. Anhand der Programme können darstellbare Inhalte der intelligenten Dokumente verändert werden. Ferner ermöglichen die Programme die Ausführung weiterer Prozesse, wie beispielsweise die Ansteuerung einer Druckeinrichtung für den Druck von Inhalten des intelligenten Dokuments oder Zugriffe auf die Netzwerkschnittstelle. Der Programmcode wird in dem normalen Darstellungsmodus des Darstellungsprogramms nicht an der Anzeigeeinrichtung dargestellt. Grundsätzlich kann jedoch das Darstellungsprogramm über einen Sonderdarstellungsmodus vorfügen, in dem auch der Programmcode darstellbar ist.
Ein von dem Server bereitgestelltes intelligentes Dokument enthält im Rahmen der vorliegenden Erfindung ferner eine Sta- tusinformation zur Angabe des Ergebnisses eines oder mehrerer Prüfungsschritte. Darstellbare Angaben der Prüfungsergebnisse werden dabei mittels eines oder mehrerer Programmmodule erzeugt, die ebenfalls in dem intelligenten Dokument enthalten sind. Die Programmmodule können als eigenständige Programme ausgebildet oder Teil eines Programms sein, das zur Ausführung der Hauptfunktionalität des intelligenten Dokuments vorgesehen ist. Innerhalb der Prüfungsschritte wird ermittelt, ob bestimmte Voraussetzungen für die Nutzung der Hauptfunktionali- täten des intelligenten Dokuments vorliegen. Hierdurch erlangt der Nutzer im Falle einer nicht nutzbaren Funktionalität insbesondere Kenntnis einer möglicherweise nicht erfüllten Voraussetzung. Diese Kenntnis kann er verwenden, um die Voraus- Setzung zu schaffen und so die Funktionalitäten des intelligenten Dokuments zu nutzen.
Eine Voraussetzung für die Nutzung der Funktionalität eines intelligenten Dokuments ist die Verfügbarkeit der Programmausführungsumgebung. In der Regel enthalten jedoch nicht alle Darstellungsprogramme zur Darstellung von Dokumenten im Format des intelligenten Dokuments eine geeignete Programmausführungsumgebung. So kann die Programmausführungsumgebung bei- spielsweise in älteren Versionen des Darstellungsprogramms nicht vorhanden sein. In einer Ausführungsform wird daher in einem Prüfungsschritt insbesondere geprüft, ob das Darstellungsprogramm des Nutzerclients über eine Programmausführungs- Umgebung verfügt, die zur Ausführung des in dem intelligenten Dokument enthaltenen Programms geeignet ist. Um das Ergebnis dieses Prüfungsschritts auch dann korrekt darstellen zu können, wenn die Programmausführungsumgebung nicht vorhanden ist, wird bereits bei der Erstellung des intelligenten Dokuments eine darstellbare Angabe eines negativen Ergebnisses des Prü- fungsschritts in das Dokument eingebracht. Ferner wird in das intelligente Dokument ein Programmmodul eingebracht, das die Angabe des negativen Ergebnisses des Prüfungsschritts in die Angabe einer erfolgreichen Durchführung des Prüfungsschritts umwandelt, wenn es ausgeführt wird. Das intelligente Dokument wird dabei vorzugsweise so konfiguriert, dass das Programmmodul nach dem Öffnen des intelligenten Dokuments in dem Darstellungsprogramm bei vorhandener Programmausführungsumgebung automatisch gestartet wird.
Die Prüfung, ob die Programmausführungsumgebung zur Verfügung steht, wird vorzugsweise implizit durchgeführt und liefert ein positives oder negatives Ergebnis, je nachdem, ob das Programmmodul ausgeführt werden kann oder nicht. Neben diesem Prüfungsschritt, in dem eine Entscheidung über das Vorhandensein der Programmausführungsumgebung getroffen wird, können gleichfalls andere Prüfungsschritte mittels eines in dem intelligenten Dokument enthaltenen Programms ausgeführt werden. Die Ergebnisse dieser Prüfungsschritte können dann in der gleichen Weise dargestellt werden, indem mittels eines Programmmoduls eine Umwandlung der Angabe eines negativen Ergebnisses in die Angabe eines positiven Ergebnisses vorgenom- men wird.
Die Umwandlung der Angabe des negativen Ergebnisses des Prüfungsschritts in die Darstellung eines positiven Ergebnisses des Prüfungsschritts kann durch eine Veränderung der Angabe erfolgen. Beispielsweise können der negativen Angabe eine oder mehrere Zeichen hinzugefügt werden, um eine Angabe eines positiven Ergebnisses des Prüfungsschritts zu erzeugen. Ferner kann die Statusangabe beispielsweise farbig ausgebildet sein oder für den Nutzer unsichtbar bleiben, außer im Falle, dass das Prüfergebnis negativ ist, um den Nutzer so über das negative Prüfergebnis zu informieren. Die Umwandlung der Angabe des negativen Ergebnisses des Prüfungsschritts in eine Angabe eines positiven Ergebnisses kann hierbei durch eine Farbänderung erfolgen, die mittels des Programms vorgenommen wird. Darüber hinaus kann es auch vorgesehen sein, dass Zeichen oder Symbole der Angabe des negativen Ergebnisses des Prüfungsergebnisses zumindest teilweise durch Zeichen oder Symbole ersetzt werden, mittels derer ein positives Ergebnis des Prüfungsschritts dargestellt wird.
Die dargestellten Schritte erfolgen vorzugsweise unter Einsatz des in Fig. 1 dargestellten Systems. Dieses System beinhaltet einen Anbieterserver und einen Netzwerkknoten (nachfolgend Maptos genannt) .
In der Übersicht steht Maptos für einen externen Einstiegs- punkt in die Anwendung POP. Weitere Zugriffe auf die einzelnen Webseiten der Anwendung POP werden ggf. transparent durch Maptos geschleust.
Maptos bezeichnet einen Netzwerkknoten zum Bereitstellen we- nigstens eines Internetdienstes, der in wenigstens einem Anbieterserver eines Dienstanbieters ausgeführt wird.
Eine Weiterbildung des Netzwerkknotens Maptos umfasst wenigstens einen äußeren Konnektor zum Empfangen einer Dienstanfor- derung, deren Erzeugung in einem Nutzercomputer eines Inter- netmarktplatznutzers initiierbar ist, und zum Übermitteln eines in dem Anbieterserver ermittelten Bearbeitungsergebnisses an den Nutzercomputer, wobei der äußere Konnektor in der Lage ist, eine an den Internetmarktplatz ange- passte Formatänderung der Dienstanforderung und des Bearbeitungsergebnisses vorzunehmen.
Ferner ist es zweckmäßig, den Netzwerknoten so auszubilden, dass er eine mit dem äußeren Konnektor verbundene Transforma- tionseinheit zum Ermitteln wenigstens eines Anbieterservers zur Ausführung des Dienstes anhand von Angaben, die in der Dienstanforderung enthalten sind, und zum Adressieren der Dienstanforderung an den ermittelten Anbieterserver aufweist.
Eine Weiterbildung des Netzwerkknotens umfasst wenigstens einen mit der Transformationseinheit verbundenen inneren Konnektor zum Übermitteln der Dienstanforderung an den Anbieterser- ver und zum Empfangen des in dem Anbieterserver ermittelten Bearbeitungsergebnisses von dem Anbieter-Server .
Der Begriff Internetmarktplatz ist dabei im Rahmen der Erfin- düng in seiner weitesten Bedeutung zu verstehen und umfasst insbesondere Webportale, wie beispielsweise Auktionsportale Tauschbörsen oder Diskussionsforen im Internet sowie Webseiten, die beispielsweise von Online-Shops bereitgestellt werden.
Der Netzwerkknoten ermöglicht es, von einem Dienstanbieter bereitgestellte Internetdienste auf einem Internetmarktplatz bereitzustellen, ohne dass Anpassungen der Anbieterserver, welche die Internetdienste ausführen, an den Internetmarktplatz erforderlich sind. Die Interpretation der Dienstanforderung, d.h. insbesondere die Vornahme erforderlicher Formatänderungen, die Ermittlung des zur Ausführung des Dienstes notwendigen Anbieterservers und die Adressierung der Dienstanforderung an den Anbieterserver erfolgt in dem Netzwerkknoten, so dass die zur Ausführung des Internetdienstes erforderlichen Angaben in einer marktplatzspezifischen Weise erfasst und in die Dienstanforderung eingebracht werden können, ohne dass bereits durch den Internetmarktplatz eine Anpassung an die Erfordernisse des Anbieterservers vorgenommen werden muss.
Darüber hinaus ist die Schnittstelle zwischen dem Netzwerkknoten und dem Internetmarktplatz von der Schnittstelle zwischen dem Netzwerkknoten und dem Anbieterserver entkoppelt, wodurch eine besonders große Flexibilität bei der Anpassung des Trans- formationsknotens erreicht wird.
Durch die äußeren Konnektoren wird mit Vorteil erreicht, dass der Netzwerkknoten selbst in einfacher und flexibler Weise an einen Internetmarktplatz und insbesondere an ein bei der Kommunikation mit einem Internetmarktplatz verwendetes Datenformat angepasst werden kann, ohne dass bei der Anpassung Änderungen der inneren Funktionalität des Netzwerkknotens, d.h. insbesondere Anpassungen der Transformationseinheit erforderlich sind.
Der POP-Server läuft auf mehreren Instanzen z.B. innerhalb eines BEA 9.x Clusters.
Ein vorgeschalteter Webserver ist bei einer bevorzugten Ausführungsform der Erfindung nicht erforderlich, falls die Anwendung alle Daten (HTML, PDF) dynamisch generiert.
Für die Verteilung der HTTP-Reguests auf die einzelnen Instanzen innerhalb des BEA-Clusters werden Sticky-Sessions benutzt. Sticky-Sessions stellen sicher, dass eine einzelne Session eines Anwenders immer von derselben Clusternode bearbeitet wird.
Für die persistente Speicherung der Daten verwendet die Anwendung POP für alle Instanzen eine gemeinsame Datenbank, beispielsweise Oracle 9.x oder 10.x.
Für die Aggregation von Logging-Daten für Statistiken ist als CronJob ein Java-Prozess vorgesehen, der auf die die Datenbank des POP-Servers zugreift. Dieser Prozess kann optional auch alte Logging-Daten periodisch löschen.
Ein weiterer Batchjob verwendet die vorher von dem POP-Server in die Datenbank geschriebenen Daten für das Melden von spezifischen Daten (nachfolgend PAN-Daten genannt) an DrittSysteme (nachfolgend ECICC genannt) . Eine Speicherung von Daten des POP-Servers außerhalb der Datenbank in einem Dateisystem ist möglich, jedoch nicht erforderlich. Es ist vorteilhaft, dass das EDICC-Modul temporäre Dateien (/tmp) für das sFTP-Protokoll anlegt.
Bemerkung :
Batch-Jobs werden vor einem parallelen, d.h. mehrfachen Starten geschützt, um zu verhindern, dass hierdurch unerwünschte Nebeneffekte auftreten.
In Fig. 2 ist eine Übersicht über besonders vorteilhafte Schnittstellen dargestellt.
Die Schnittstellen dienen zu einer Verbindung zwischen einem erfindungsgemäßen Anbieterserver mit einem Providerserver
(Provider genannt) . Die Erfindung erfolgt vorteilhafterweise über das Internet .
Der Anbieterserver ist mit einem Client (Benutzersystem) ver- bindbar. Bei dem Client handelt es sich beispielsweise um ein Benutzersystem, das so ausgestattet ist, dass es Daten von dem Server empfangen und/oder Daten zu dem Server übermitteln kann. Beispielsweise handelt es sich bei dem Client um einen Personalcomputer, ein Unternehmensnetzwerk oder um ein mobiles Benutzerendgerät, beispielsweise ein Mobiltelefon.
Vorzugsweise ist der Client so gestaltet, dass er Browser- Funktionalitäten beinhaltet.
Hierbei handelt es sich beispielsweise um einen Webbrowser
(mit aktiviertem JavaScript, HTML 4.0), wobei es vorteilhaft ist, dass die Applikation so ausgebildet ist, dass sie mit einer Vielzahl unterschiedlicher Browsertypen gestartet und be- nutzt werden kann. Hierunter fallen z.B. folgende Browsertypen:
• Internet Explorer Version 6.0, • Mozilla Firefox 1.5,
• Netscape 7.1,
• Safari 2.0.4 (Mac OS) .
Die Liste der genannten Browser ist jederzeit erweiterbar, um Fortentwicklungen berücksichtigen zu können.
Es ist zweckmäßig, Sicherungsmechanismen einzuführen, um die Kommunikation zwischen dem Client und dem Anbieterserver vor einem unberechtigten Abhören durch Dritte zu sichern.
Ebenso ist eine Sicherung der Kommunikation zwischen dem Anbieterserver und weiteren externen Systemen - insbesondere Zahlungssystemen - zweckmäßig.
Es ist daher vorteilhaft, bei der Kommunikation sichere Protokolle einzusetzen. Dies sind beispielsweise:
• HTTPS (POST, GET, XML) ,
• sFTP (EDICC) .
Beide Protokolle sind von Manipulation oder Abhören durch Dritte abgesichert.
Falls die Kommunikation mit einen unternehmensinternen System über ein internes Netz erfolgt und die übertragenen Daten keine sensiblen Daten enthält, kann optional HTTP anstatt HTTPS verwendet werden. In den versendeten E-Mails werden direkt keine Codes, Passwörter o. ä. versendet, sondern lediglich ein Link mit einer ID (vorzugsweise von der Transaktions-ID verschieden) eingebettet, der auf eine HTML-Seite (N0W3) verzweigt.
Missbrauchsicherung
Die von der Anwendung generierten Nummern - Gutscheine, Dokumente, Warenkorb, PIN - werden so generiert, dass sie nicht durch den Anwender erratbar sind. Außerdem werden diese Nummern in der Datenbank gespeichert und so ihr "Verbrauch" kontrolliert .
System-Zugangsdaten
Zugangsdaten, die für die Benutzung der externen Schnittstellen nötig sind, werden über ein symmetrisches Verschlüsselungsverfahren (in der Webanwendung enthalten) in der Datenbank abgelegt, d. h. diese können auch durch eine Datenbank- Administrator nicht eingesehen werden.
Sicherungsprotokolle der Bezahlplattformen
Die Standardmechanismen zur Absicherung der Kommunikation zwi- sehen Anwendung und Bezahlplattform werden verwendet.
Die eigentlichen Bezahlvorgänge werden auf den Webseiten der Bezahlplattform durchgeführt, so dass diese Transaktion für die Anwendung gekapselt ist . Nutzerbezogene Daten
Vorzugsweise enthält der Anbieterserver nur die Daten, die für die Durchführung des Verfahrens zweckmäßig sind. Dies sind beispielsweise :
• Inhalt des Warenkorbes, solange es notwendig ist, dem Nutzer die entsprechenden Funktionen zur Verfügung zu stellen (PDF- Dokumente beispielsweise 32 Tage; für Gutscheincodes auch länger, wobei diese Werte aus technischer Hinsicht beliebig konfigurierbar sind, so dass die vorgegebene Setzung lediglich exemplarischen Charakter hat) .
• Die gekauften Label inkl. der notwendigen Daten (32 Tage - siehe vorherigen Punkt) .
• E-Mail -Adresse des Nutzers aus der Kurzregistrierung mit Teilnahme an Mailing-Aktionen (unbegrenzt) .
• Enthält der Warenkorb Gutscheine, die noch nicht aufgebraucht sind, so ist der Warenkorb mit diesen Gutscheinen entsprechend länger gültig (Gültigkeit der Gutscheine) .
Daten werden in der Datenbank nicht gelöscht, sondern lediglich entsprechend über z. B. ein Attribut markiert.
Der nachträgliche Zugriff eines Anwenders auf seinen Warenkorb erfolgt ab einem gewissen Preisvolumen über die zusätzliche Eingabe einer PIN oder PIN2.
Nachvollziehbarkeit durch Protokollierung (Logging)
Alle wichtigen Aktionen der Anwendung sowie die Aufrufe von externen Schnittstellen werden in der Datenbank protokolliert. Ist die Protokollierung in der Datenbank nicht möglich, z. B. bei Datenbankfehlern, werden die Logging-Mechanismen des Applikationsservers verwendet.
Konfigurationsmanagement
Das Konfigurationsmanagement mit den zeitbehafteten Daten (z. B. Preise, Gutscheine) und den statischen Ressourcen ist so angelegt, dass einmal angelegte und bereits produktiv ge- schaltete Konfigurationen nicht mehr aus der Datenbank entfernt werden können. Weiterhin sind für jeden Zeitpunkt in der Vergangenheit die zu diesem Zeitpunkt gültigen Konfigurations- daten rekonstruierbar.
Oberfläche
Die für den Benutzer sichtbare Oberfläche der Anwendung gliedert sich im Wesentlichen in folgende Webseiten:
• NOWl: Anzeige des kompletten Warenkorbes,
• NOW2 -Sendung : Detaildarstellung einer Sendung,
• NOW2 -Gutschein: Detaildarstellung eines Gutschein-Sets,
• Now2 -Abholung : Detaildarstellung einer Abholungsbeauftragung
• NOW3 : Angaben zum im vorherigen Schritt bezahlten Warenkorb.
Felddefinitionen
Um eine Beeinflussung des Seitenlayouts durch die Anzeige überlanger Feldinhalte zu verhindern (beispielsweise sehr lan- ge Straßennamen) , werden diese entweder in nicht editierbaren Textboxen mit fester Länge angezeigt oder nach einer festgelegten Anzahl von Zeichen abgeschnitten (natürlich nur für die Anzeige) . Eingabefelder sind speziell markiert (Edit, Input) ; ansonsten sind die beschriebenen Felder reine Anzeigefelder ohne weitere Funktion. Ggf. folgende Angaben in runden Klammern wie AN (64) bedeuten "maximal 64 Stellen alphanumerisch"; analog etwa N (6) "maximal 6 Stellen numerisch". Falls nicht genauer spezifiziert, handelt es sich um einzeilige Eingabefelder mit freier Eingabe (keine Dropdown-Liste o.a.). Bei Validierungsfehlern (falsches Format; fehlende Eingabe) wird das entsprechende Feld oder der Bereich farbig markiert.
NOWl : Warenkorb
Diese Seite zeigt den Warenkorb und enthaltene Positionen in einer Übersicht an. Der Benutzer kann Einträge im Warenkorb erzeugen oder manipulieren und schließlich die Bezahlung anstoßen.
Erreichbar von
- NOWO : Link auf Eingangsseite
NOWl: Reload (beispielsweise Fehlermeldungen anzeigen; Gutschein einlösen)
- N0W2 : Rücksprung nach Bearbeitung einer einzelnen Listenposition
Die Anzeige einer einzelnen Sendung des Warenkorbes besteht aus folgenden Elementen:
- Icon "Ausrufezeichen" bei fehlerhaften Sendungsdaten; in diesem Fall ist die Position auch mit einer anderen Farbe hinterlegt, Absender-Adresse, bestehend aus den Zeilen Namel, Name2, Straße, Hausnummer, Postleitzahl, Ort und Land (Land nur, falls nicht Deutschland) ,
Empfänger-Adresse, bestehend aus den Zeilen Namel, Name2, Straße, Hausnummer, Postleitzahl, Ort und Land (Land nur, falls nicht Deutschland) .
- Produkt-ZeIIe o Gewähltes Produkt und Liste aller möglichen wählbaren
Services zum Produkt. Die vom Benutzer bereits gewählten Optionen sind markiert. Falls noch kein Produkt ausgewählt wurde, wird ein statischer Text „Kein Produkt gewählt" angezeigt . o Aktion "Service (de-) selektieren" .
Preis-Zelle o Ein Gesamtpreis inklusive Währung für die komplette Sendung. Falls kein Preis bestimmbar ist, wird auch kein Preis angezeigt. o Ist für diese Sendung bereits ein Gutschein eingelöst, erscheint der statische Text "Gutschein eingelöst". o Alternativ: Aktion: "Gutschein einlösen" (Button "Ok") mit Eingabefeld für die Gutschein-Nummer.
- Aktion "Entfernen",
- Aktion: (Position) "Ändern ...". Aufruf von N0W2 , Optionale Meldungen zur Sendung, die die volle Breite einer Sendung einnehmen. Position - Abholung
Dieser Eintrag erscheint hinter allen Sendungs- und Gutschein- set-Positionen und nur, wenn eine Abholung für den Warenkorb gebucht ist. Der angezeigte Preis wird bei jeder Änderung des Warenkorbes neu berechnet .
Die Anzeige besteht aus folgenden Elementen:
Die Zellen "Absender" und "Empfänger" bleiben leer,
Zelle "Produkt": Statischer Text "Abholung aller Sendungen",
Zelle "Preis": Der Gesamt-Aufpreis für die Abholung; hier werden die Beträge pro Sendung summiert, - Aktion "Position entfernen" storniert eine gebuchte Abholung,
- Aktion "Position ändern": Aufruf des Popup-Fensters .
Position - Rabatt-Information
In dieser Position werden dem Anwender Informationen zu einem eventuell eingeräumten Rabatt angezeigt.
Die Anzeige besteht aus folgenden Elementen:
In den Zellen "Absender" und "Empfänger" kann ein in der Rabattregel hinterlegter Text eingeblendet werden.
- In der Zelle "Produkt" wird der statische Text "Rabatt" und der Name der entsprechenden Rabattdefinition angezeigt.
- In der Zelle "Preis" wird die Rabattsumme inklusive Währung als negativer Posten angezeigt. - Aktion "Position entfernen" und Aktion "Position ändern" entfallen.
Aktion "Service (de-) selektieren"
Der Anwender kann einzelne Services auf eine Sendungsposition buchen. Die Änderung wird direkt nach der Selektion aktiv, d. h. , die Webseite wird nach jeder Aktion neu geladen. Existiert kein entsprechendes Produkt zu der gewählten Kombination, so wird eine Fehlermeldung angezeigt. In einer besonders bevorzugten Ausprägungsform kann durch technische Verfahren auch erreicht werden, dass zur Neukonfiguration eines Preises kein kompletter Reload einer Seite erforderlich ist.
Aktion "Weitere Sendung hinzufügen ..."
Direkte Anzeige der Seite N0W2-Sendung. Als Vorgabe für die Absenderadresse wird die Adresse der ersten Sendung benutzt, falls vorhanden.
Aktion 11MwSt . -Aufschlüsselung"
Anzeige des Popups .
Aktion "Wieso ist eine gültige E-Mail-Adresse erforderlich?"
Anzeige des Popups .
Aktion: "Allgemeine Geschäftsbedingungen aufrufen"
Anzeige des Popups . Aktion: (Position) "Ändern"
Aufruf von NOW2-Sendung.
Aktion "Gutschein einlösen"
Als Eingabe dient eine Gutscheinnummer. Der Gutschein ist der Sendung zugeordnet, in dessen Zeile die Nummer eingegeben wurde. Bei fehlerhaftem Code wird an der definierten Stelle ein Fehlertext wie "Ungültiger Gutscheincode", "Gutscheincode abgelaufen" oder "Gutschein passt nicht zur Sendung" eingeblendet. Ist für die Sendung noch kein Produkt ausgewählt, so wird es anhand des Gutscheincodes gesetzt.
Ist im Gutschein auch eine TAS-Abholung enthalten, so wird diese automatisch für den ganzen Warenkorb gebucht.
Aktxon "Weiter zur Bezahlung"
Diese Aktion ist deaktiviert, wenn
- der Warenkorb leer ist, eine Sendung mit fehlerhaften Daten existiert,
- die Abhol-Adresse nicht TAS-leitcodierbar ist.
Sollten während des Bezahlungsvorganges Fehler auftreten, so wird wieder NOWl angezeigt und an der definierten Stelle eine textuelle Fehlermeldung eingeblendet. Im Erfolgsfall springt die Anwendung zu NOW3.
Aktion "Position entfernen"
Zunächst muss der Anwender die Aktion bestätigen ("Wollen Sie wirklich ..."). Bei Zustimmung wird die Position aus dem Wa- renkorb entfernt. Ein auf dieser Position eingelöster Gutschein wird wieder freigegeben.
Aktion (Abholung) "Buchen"
Über das nun erscheinende Popup-Fenster erfasst der Anwender das Abholdatum und die Abholadresse. Die Kosten für die TAS- Abholung werden dann in einer eigenen Warenkorb-Position angezeigt .
Aktion "Gutscheine auswählen"
Ruft die Seite N0W2-Gutschein auf.
Optionale Meldungen zu einer Sendung
Meldung "Für diese Sendung ist keine Abholung möglich" wird angezeigt, wenn für den Warenkorb eine Abholung gebucht ist, das der Sendung zugrunde liegende Produkt aber nicht mit die- sem Service kombiniert werden kann.
Meldung "Die Empfängeradresse konnte nicht verifiziert werden", falls die Empfängeradresse nicht leitcodierbar ist.
Fehlermeldung "Die Sendungsdaten sind nicht vollständig. Bitte korrigieren Sie Ihre Angaben", falls die Sendungsdaten fehlerhaft sind.
Baustein NOWl
Auf der Seite wird unten links der dynamische Baustein NOWl eingeblendet . In einer Eingabemaske (Popup-Fenster) kann der Anwender mit Hilfe einer Dropdownliste ein Abholdatum und eine Abholadresse erfassen. Die Datumsliste enthält n Folgetage in chronologischer, aufsteigender Reihenfolge. Der erste Tag ist vorselek- tiert. Sonntage werden nicht in der Liste angeboten. Ob der nächste Tag noch in der Liste angezeigt wird, entscheidet sich mit Hilfe einer konfigurierbaren Zeitangabe: Liegt die aktuelle Systemzeit noch vor dieser Uhrzeit, wird der nächste Tag angeboten; ansonsten frühestens der übernächs- te. Die Gesamtzahl der Einträge in der Liste lässt sich ebenfalls konfigurieren. Als initiale Vorgabe für die Abholadresse wird die Absenderadresse der ersten Sendung benutzt. Das Fenster kann erst mit „Bestätigen" verlassen werden, wenn die Abholadresse leitcodierbar ist. Im Fehlerfall wird eine Meldung wie im Screenshot ersichtlich angezeigt.
In einer Weiterführung der Erfindung ist es ebenfalls möglich, auch Abholung für denselben Tag respektive für spezifische Zeitfenster zu buchen.
Popup E-Mail-Bestätigung
Will der Benutzer den Warenkorb bezahlen, so wird er mit Hilfe dieses Popup-Fensters aufgefordert, die im Warenkorb erfasste E-Mail -Adresse zu bestätigen. (Ausnahme: Bei der Adresse handelt es sich um die per Maptos übertragene E-Mail-Adresse) . Bei Bedarf kann die Angabe in diesem Fenster überschrieben werden. Zustimmung zu AGBs
Für jeden Warenkorb muss der Anwender erneut den AGBs zustim- men, indem er die entsprechende Selectbox markiert, d.h. der Defaultwert ist "nicht gesetzt".
Fehlerhafte Sendungsdaten
Jede fehlerhafte Sendung wird durch ein führendes " ! " gekennzeichnet und muss durch den Anwender korrigiert oder entfernt werden, bevor der Warenkorb bezahlt werden kann.
In einem ersten Schritt wird für Absender- und Empfänger- Adresse geprüft, ob die Pflichtfelder
Name ,
- Straße, Postleitzahl, - Ort
gefüllt sind. Ist beispielsweise der Name einer Empfängeradresse für eine Sendung leer, so gilt die ganze Adresse und damit die Sendung als fehlerhaft.
Analog wird verfahren, wenn
- kein oder ein ungültiger Produktschlüssel hinterlegt oder
- bei einer gebuchten Abholung die Abholadresse nicht leitco- dierbar ist.
Gewisse, im folgenden Absatz beschriebene, Funktionen sind zusätzlich von der Leitcodierbarkeit von Absender- oder Empfängeradresse abhängig. Leitcodes prüfen
Bei (Wieder) -Eintritt in NOWl werden die Leitcodes der Empfän- ger-Adressen bestimmt. Dieser Vorgang erfolgt synchron, um die Ergebnisse sofort anzeigen zu können. Die bestimmten Leitcodes bzw. der Status Adresse nicht leitcodierbar wird innerhalb der Anwendersession bei jeder Adresse gespeichert, um die Anzahl der Leitcodieraufrufe aus Performancegründen zu minimieren.
N0W2 : Sendungs-Details
Auf dieser Seite können die Daten einer Sendung wie Adressen und Produkt erfasst und manipuliert werden. Bei nicht gesetz- tem Produkt wird das zum Empfängerland passende Produkt (höchster Sortierschlüssel-Wert) vorausgewählt.
Erreichbar von:
- NOWl: Aktion "Weitere Sendung hinzufügen" (Anzeige von N0W2 mit Vorgabewerten)
- NOWl: Aktion "Ändern ..."
(Anzeige mit den Daten der entsprechenden Sendung)
Im oberen Teil der Seite werden Absender- und Empfängeradresse erfasst. Für das Sender- und Empfänger-Land wird eine Dropdownliste angeboten, aus der der Anwender das Land auswählen kann. Eine freie Eingabe ist nicht möglich, aber generell vorstellbar. Ist für das Land keine explizite Angabe vorhanden, so wird "Deutschland" als Voreinstellung benutzt.
Die Länderliste ist im System hinterlegt. Im zweiten Teil werden abhängig vom Empfängerland die möglichen Basisprodukte angezeigt (normalerweise immer "Päckchen", "Paket 10kg", "Paket 20kg", wobei dies lediglich Beispiele für Basisprodukte sind) , von denen der Anwender genau eines aus- wählen muss. Ist für die Sendung noch kein Produkt hinterlegt, so wird der erste Eintrag automatisch selektiert. Bei Selektion eines Produktes wird die Seite aktualisiert und der für das selektierte Produkt und die aktuelle Kombination der Services gültige Produktpreis angezeigt.
Im dritten Teil der Seite werden die für die Kombination aus Empfängerland und Basisprodukt möglichen Services zur Auswahl angeboten. Bei (De-) Selektion wird die Seite aktualisiert und der aktuelle Preis für die selektierten Services angezeigt.
Durch ein geeignetes Darstellungsmedium - insbesondere eine Webseite - wird eine Auswahl einzelner, mehrerer oder sämtlicher der nachfolgenden Aktionen ermöglicht.
Aktion "Gutscheincode entfernen"
Falls für diese Sendung ein Gutscheincode erfasst ist, wird er nach einer Sicherheitsabfrage ("Wollen Sie wirklich ...?") wieder entfernt.
Aktion "Abbrechen"
Die Änderungen auf der Seite werden verworfen und wieder NOWl angesprungen . Aktion "Gutschein entfernen"
Diese Aktion ist nur aktiviert, wenn bereits ein Gutschein auf diese Sendung eingelöst ist. Der Code wird nach einer Sicherheitsabfrage ("Wollen Sie wirklich ...") aus der Sendung entfernt und wieder dieselbe Seite angezeigt .
Aktion "Ok" (Sendung bestätigen)
Anhand der ausgewählten Kombination aus Empfängerland, Produkt, Services und dem AbholStatus des Warenkorbes wird geprüft, ob ein passendes Produkt in der Produktliste existiert. Falls nicht, so wird dem Anwender erneut dieselbe Seite mit einer Fehlermeldung angezeigt.
Falls ein passendes Produkt bestimmt werden konnte, so wird die Sendung aktualisiert und wieder die Warenkorbseite NOWl angezeigt .
N0W2: Gutschein-Details
Mit Hilfe dieser Seite können neue Gutschein-Sets in den Warenkorb gelegt werden. Der Anwender wählt zunächst ein Basis- produkt aus, wodurch die Dropdownliste mit den für dieses Basisprodukt erhältlichen Gutscheindefinitionen aktualisiert wird. Wählt er eine neue Gutscheindefinition, so wird analog die Dropdownliste mit den verschiedenen Stückelungen aktualisiert (unter Beachtung einer Vorgabe-Stückelung) .
Zusätzlich wird im oberen Bereich der Seite eine Liste mit maximal 3 Einträgen angezeigt . Diese Einträge beschreiben die ersten drei der auch in der Dropdown-Liste angebotenen Gut- Scheindefinitionen zusammen mit der in der Gutscheindefinition hinterlegten Standard-Stückelung und dem zugehörigen Preis. Für jeden Eintrag wird eine Aktion "Jetzt kaufen!" angeboten.
Erreichbar von:
NOWl: Aktion "Gutschein hinzufügen"
Aktion 11Ok"
Legt das ausgewählte Gutschein-Set in den Warenkorb und springt wieder zu NOWl .
N0W3
Diese Seite enthält die vom Anwender erworbenen Marken in Form von Links auf die PDF-Dokumente sowie ggf. eine Liste von erworbenen Gutscheincodes. Sie wird nach erfolgreicher Bezahlung des Warenkorbes angezeigt. Alternativ kann der Benutzer über einen Link in seiner Bestätigungs-E-Mail wieder auf diese Seite gelangen.
Unter gewissen Bedingungen wird der Zugriff auf die Daten der Seite durch Eingabe einer PIN bzw. PIN2 abgesichert.
Erreichbar von:
- NOWl: Aktion "Weiter zur Bezahlung"
- N0W3-Login
Die Textdarsteilung der PDF-Links auf der Seite wird auf folgende Weise zusammengestellt: - Text "Label", Empfänger-Namel , Empfänger-Name2 ,
Tagesdatum in der Form "31.12.2006", - Laufende Nummer,
- Text "PDF".
Diese Felder werden auf eine Einzellänge von jeweils 15 Zeichen gekürzt und mit "_" verbunden. Sonderzeichen und Umlaute werden ersetzt.
- Header für Liste mit den Spaltenköpfen "Gedruckt", "Gutscheincode" und "Gutscheintyp" : o Ein "Häkchen" , falls verbraucht o Gutscheincode o Gutscheintyp (Kurzbezeichnung aus der Gutscheindefinition)
Box "Per E-Mail erhalten und bequem zu Hause bearbeiten" : o Dynamisch eingeblendete E-Mail -Adresse mit einem Hinweis, dass die Unterlagen an diese Adresse gesendet wurden. o Eine Warenkorb-ID mit dem Hinweis, diese bei Rückfragen an den Support griffbereit zu haben. o Die PIN für den Warenkorb mit einem weiteren Hinweis, falls benötigt.
Einblendung des dynamischen Bausteins NOW3 (0) links unten
- Box "Abholung" (falls im Warenkorb gebucht) o Text "Sie haben eine Abholung Ihres Warenkorbes zum
30.12.2006 gebucht" (dynamisches Datum), gefolgt von der Abholadresse .
- Alternativ zu Box "Abholung": Box "Befindet sich eine Pack- Station in Ihrer Nähe?" o Falls nein, wird in der Box ein Text "Es kann leider keine Packstation in Ihrer Nähe gefunden werden" angezeigt. o Falls ja, wird in der Box ein Text "Nutzen Sie die Vorteile der Packstation. Sie können Ihre Sendungen rund um die Uhr in Ihre Packstation einliefern", dahinter ein Link auf den Packstationfinder (externe Webseite) . Dahinter wird die Adresse der gefundenen Packstation angezeigt.
Aktion: "Fenster schließen"
N0W3 -Login
Der Anwender kann über einen in der E-Mail enthaltenen Link auch später auf die Seite NOW3 gelangen. Übersteigt der Warenkorb einen gewissen Mindestwert, so wird dieser Zugriff über die Eingabe einer PIN bzw. PIN2 in der Maske NOW3 -Login abgesichert
Nach Eingabe einer gültigen PIN oder PIN2 wird der Anwender auf die Seite NOW3 weitergeleitet. Im Fehlerfall erscheint ei- ne Meldung innerhalb derselben Seite und der Anwender kann erneut seine Anmeldedaten eingeben.
Hinweis: Diese zusätzliche Absicherung des Warenkorbes wird ggf. erst in Phase II umgesetzt.
Bausteine
In Abhängigkeit von Uhrzeit und Marktplatz können verschiedene Bausteine in einer Webseite eingeblendet werden. Ein Baustein beschreibt hierbei eine rechteckige Teilfläche einer Webseite. Der Inhalt des Bausteines ist statisch. In einer Weiterentwicklung der Darstellungsmethode können die Bausteine in ihrer Beschaffenheit auch lediglich durch Datenkonventionen beschrieben werden, so dass die Ausgestaltung der Bausteine selbst komplett durch einen Marktplatz erfolgen kann .
Mögliche Ausgestaltungsformen der Bausteine können sein:
Portal -Baustein
Auf den Webseiten eines Marktplatz-Betreibers kann dynamisch ein Baustein von der POP-Anwendung geladen und in die eigenen Seiten eingebettet werden. Beispielsweise kann dieser Baustein einen einfachen Link auf die Warenkorb-Seite (NOWl) enthalten, über den ein Marktplatz-Kunde zur POP-Anwendung gelangen kann.
NOWl-Baustein
Dieser Baustein wird auf der Seite NOWl unten links eingeblen- det. Hier kann z.B. ein FAQ-Baustein vorkonfiguriert sein. Bei Klick auf eine Frage im Baustein wird ein Popup-Fenster mit dem FAQ-Text geöffnet .
N0W3-Baustein
Auf der Seite N0W3 wird unten links ein weiterer Baustein eingeblendet. Dieser ist separat zum vorherigen Baustein konfigurierbar, wird aber initial mit identischem Inhalt gefüllt sein. E-Mail-Bestätigung
Ist der Warenkorb eines Anwenders abgegolten, so wird Ihm eine Benachrichtigung per E-Mail zugesandt. Diese E-Mail besteht aus folgenden Bestandteilen:
statischer Text,
ein einziger - mit einem eindeutigen Schlüssel versehener - Link auf die Seite NOW3 ; über diesen Link erfolgt die nachträgliche Zuordnung zum Warenkorb,
- Warenkorb- Id für Support-Anfragen,
Zahlungsbestätigung über den Warenkorb analog Mehrwertsteuer-Popup, - falls vorhanden, ein Hinweis inklusive Adresse einer Packstation in der Nähe der ersten Sendungs-Absender-Adresse.
Buchungstext
Auf dem Kontoauszug des Anwenders erscheinen folgende Angaben (beispielhaft) :
- "Ihre Warenkorb- Id: ABCDEFGHKL, " (31 Zeichen)
- Optional: "Ihre PIN2 : 9999," (17 Zeichen),
"Vielen Dank für die Nutzung von DHL Express" (43 Zeichen) .
Es ergibt sich eine Summe von 101 Zeichen (Obergrenze PayPal : 127 Zeichen) . Einsprungspunkte in die Anwendung
Die POP-Anwendung kann über Maptos angesprochen werden, wobei initial die Seite NOWl angezeigt wird. Alternativ ist der direkte Zugriff auf die Seite NOW3 - ggf. mit zusätzlicher Anmeldung über PIN oder PIN2 - über den Link in der Bestätigungs-E-Mail möglich.
Services
In der Anwendung sind folgende Services fest integriert (exemplarisch) :
- Abholung TAS,
Rollenservice, - "Grün" .
Der Service "Abholung TAS" kann nur komplett für den gesamten Warenkorb selektiert werden. Hier ist eine Angabe eines Abholdatums zwingend erforderlich. In einer Weiterentwicklung kann bei einer Abholung ferner ein Zeitfenster für die Abholung einer Postsendung ausgewählt werden.
Bei den restlichen Services werden keine weiteren Daten vom
Anwender abgefragt, insbesondere auch keine Gewichte und Maße.
Services werden in der Datenbank hinterlegt . Einfache Services (ohne spezielle Logik) können nachträglich über Datenbankände- rungen ohne Programmierung hinzugefügt werden. Hierbei ist jedoch zu beachten, dass abhängige Daten wie etwa Preise nachgepflegt werden müssen. Service-Attribute
Ein einzelner Service wird vorzugsweise über folgende Attribute definiert.
Attribut Beschreibung
Für einen Service eindeutiges symbolische
Kürzel
3X11 Name für die Anzeige in der Oberfläche
Eine Kurzbeschreibung des Services Flag, ob zu diesem Service ein Preis hinterlegt sein muss (für TAS-Abholung beispielsweise nicht)
Länder
Produkte (Kombinationen aus Basisprodukten und Services) kön- nen länderspezifisch administriert werden. Um nicht für jedes EU-Land identische Produkte definieren zu müssen, wird eine besondere Kennung "EU" eingeführt. Mittels einer im System hinterlegten Länderliste können dann Produkte mehreren Ländern gleichzeitig zugeordnet werden. Die Zuordnung "EU" wird jedoch nur so lange benutzt, wie kein Produkt einem "echten" Land zugeordnet ist.
Beispiel :
In einer fiktiven Länderpreisliste sind mehrere Produkt mit Länderkennung "EU" und ein einzelnes Produkt mit Länderkennung "AT" für Österreich definiert. Wird jetzt nach allen Produkten für das Empfängerland Österreich gesucht, liefert der eingesetzte Algorithmus nur ein Produkt zurück. Wird aus der Produktivliste das "AT" -Produkt entfernt, so liefert der Algo- rithmus alle Produkte mit Länderkennung "EU" . Adressen
Adressen werden in der Anwendung POP in folgenden Feldern abgelegt :
- Name1 ,
- Name2 ,
- Straße, Hausnummer, Postleitzahl, - Ort,
- Land .
Adressen, die durch Maptos weitergegeben werden, enthalten kein separates Feld für die Hausnummer. Diese wird analog zur Leitcode-Bibliothek von Online Label Druck aus dem kombinierten Straße-Hausnummer-Feld abgespalten.
Marktplätze
In der Anwendung können über das Admin-Web neue Marktplätze definiert werden. Bei den Marktplätzen handelt es sich beispielsweise um den dargestellten Provider.
Elemente wie
Bausteine,
Preise und Gutscheine
können marktplatzabhängig definiert werden. In der Session des Anwenders ist immer auch ein Marktplatz gesetzt.
Figure imgf000066_0001
Marktplatz-Attribute
Positivliste
Die Positivliste enthält alle im System verfügbaren Produkte. Jede Zeile beschreibt ein einzelnes Produkt. Die „linke" Seite (Produktnummer, Produktname, Basisproduktangäbe, Land) kann mehrmals vorkommen. Die rechten Seiten der Tabellenzeilen geben dann alle gültigen Kombinationen an Services an, die dieser „linken Seite" zugeordnet werden können. Jede Zeile beinhaltet immer auch das Basisprodukt selbst .
Es ist zweckmäßig, die Liste so zu gestalten, dass sie für alle Marktplätze gilt. Vorzugsweise sind die Liste und das System so aufeinander angepasst, dass nicht enthaltene Kombinationen ungültig sind.
Die folgende Tabelle beschreibt die Spalten, aus welchen die Positivliste aufgebaut ist. Kürzel Erklärunq / Inhalt
Eindeutige Nummer für das Produkt
Name des Produktes, der in der Oberfläche angezeigt wird
Basisprodukt Päckchen
Basisprodukt Paket 10kg
Basisprodukt Paket 20kg
Iso-Code eines Landes; als Sonderfall "EU" mδglich
Services mim Abholung TAS
Rollenservice
"Grün"
Spaltenbeschreibung der Positivliste
Ein verkürztes Beispiel einer Positivliste:
Figure imgf000067_0001
Exemplarische Positivliste
In jeder Zeile können über eine Liste von Iso-Codes (3 -stellig analog Maptos) ein oder mehrere Länder referenziert werden. Das spezielle Kürzel "EU" steht für alle EU-Länder (diese sind in einer Liste hinterlegt) .
Produkt-Attribute
Neben den Preisangaben sind jeder Zeile der Positivliste noch weitere Attribute zugeordnet :
Produktschlüssel (zur Verbesserung der Entgeltsicherung) . - Produktschlüssel ESI,
Produktcode (Bestandteil des Leitcodes, 2-stellig) , Verfahrensnummer (ESI und Labeldruck) ,
- Teilnahme (ESI und Labeldruck) , ProductcodeLabel (für Labeldruck erforderlich) , - ServicecodeLabel (für Labeldruck erforderlich) ,
Featurestringlabel (für Labeldruck erforderlich) , Sortierschlüssel; bestimmt die Reihenfolge der Anzeige bzw. welches Produkt als Default benutzt wird.
Produktauswahl nach Land
Auf der Seite NOW2 kann die Auswahl der Produkte abhängig vom Empfängerland vorgenommen werden: es werden nur die Produkte angeboten, die diesem Land zugeordnet sind.
Hierarchische Daten
Elemente wie
- Preise,
- Bausteine, Gutscheindefinitionen und
- Rabatte
können auf der Ebene von
- Marktplatz-Aktionen (gültig für genau einen Marktplatz und einen konfigurierbaren Zeitraum) ,
eines Marktplatzes (gültig ohne Zeitfenster für genau einen Marktplatz) oder
- vollkommen Marktplatz-unspezifisch (gültig für jeden Marktplatz ohne Zeitfenster)
definiert werden, wobei die „höhere" Definition maßgeblich ist, auch wenn weitere Preise oder Bausteine existieren. Die Elemente der Marktplatz-unspezifischen Ebene sind Pflichtelemente, die der beiden anderen Ebenen sind optional.
Objekte, die diese Vorgehensweise unterstützen, sind mit einem MZF-Header (Marktplatz-ZeitFenster) versehen, der folgende Attribute umfasst :
Attribut Beschreibung
I Optionale Marktplatz-Kennung IAb diesem Zeitpunkt ist der Datensatz gültig Bis zu diesem Zeitpunkt ist der Datensatz gültig
Zu diesem Zeitpunkt ist der Datensatz aktiv geschaltet worden.
Symbolischer Name für den Datensatz. Zwei Datensätze mit gleichem symbolischen Namen werden als gleich angesehen und nur die "Neuere" Angabe (Att- I ribut Activated) verwendet.
MZF-Header
Ist beispielsweise für den aktuellen Zeitpunkt keine Marktplatz-Aktions-Preis für "Päckchen D" definiert, wir nach einem Marktplatz-Preis für "Päckchen D" gesucht. Ist auch dieser nicht definiert, so wird der Preis in der Marktplatzunabhängigen Preisliste verwendet.
Informationen, die auf diese Weise abgelegt sind, werden nicht internationalisiert. Im Zweifelsfall kann dies über eine marktplatz-abhängige Konfiguration abgebildet werden.
Preise
Für die Produkte in der Positivliste können Teilpreise definiert werden, und zwar für Kombinationen aus
- Basisprodukt und Land ("Päckchen D"), - Service und Land ("Rollenservice D") .
Der Gesamtpreis einer Produktzeile ergibt sich dann zunächst aus der Summe der Einzelpreise.
Die Default-Preisliste (marktplatz-unabhängig) kann folgendermaßen aussehen:
Figure imgf000070_0001
Figure imgf000071_0001
Default-Preisliste (Tabelle I) - exemplarische Darstellung
In dieser Liste muss jedes Basisprodukt und jeder Service - mit Ausnahme der TAS-Abholung -, als "land-loser" Eintrag mit einem Preis versehen sein. Alle anderen Einträge sind optional. Falls beispielsweise kein Preis für (Päckchen, DEU) definiert wäre, würde der Preis von (Päckchen,*) als Vorgabe benutzt .
Diese Liste kann mehrfach für verschiedene Ebenen definiert werden. Für die anderen beiden Ebenen sind alle Preisangaben optional, d.h. hier können Preise definiert sein, müssen aber nicht. Dieses Verfahren stellt sicher, dass zu beliebigen Kom- binationen aus (Basisprodukt, Land) bzw. (Service, Land) ein Preis bestimmbar ist.
Über eine geeignete Suchreihenfolge kann zu jeder Zeile der Positivliste (und ggf. abhängig vom Marktplatz und einem Zeit- punkt) ein eindeutiger Preis berechnet werden. Dieser ist einfach die Summe des Preises für das Basisprodukt+Land und die zugeordneten Services+Land.
In einer Weiterentwicklung kann ein detaillierteres Preismo- dell umgesetzt werden, in dem auch einzelne Zellen der Positivliste mit Preisen versehen werden können ("Produkt/Service- Kombipreise") . Beispiel
Zusätzlich zur Default-Preisliste oben sind zwei weitere Preislisten definiert. Zuerst spezialisierte Preise für den Marktplatz Provider:
Figure imgf000072_0001
Marktplatz Provider-Default (Tabelle II)
Für eine Marketingaktion auf dem Marktplatz Provider in der Kalenderwoche 50 wird ein spezieller Preis für ein Päckchen DEU definiert (Begin und Ende des Zeitraumes können minutengenau angegeben werden) :
Figure imgf000072_0002
Marktplatz Provider-Wochenaktion KW 50 (Tabelle III)
Beispiel-Ergebnisse I
Suchkriterien :
- Der aktuelle Zeitpunkt (die Serverzeit ist hier maßgeblich) befindet sich in der KW 49, d.h. dass außerhalb des Zeitrau- mes, für den Tabelle III gültig ist.
- Das Zielland der exemplarischen Sendung ist Deutschland [DEU) .
- Der Marktplatz des Anwenders ist Provider Die folgende Tabelle enthält die Teilpreise für das Produkt Päckchen+Rollenservice und Paket 10kg:
Figure imgf000073_0001
Beispiel-Ergebnisse I (die römischen Ziffern hinter den Preisen geben die Preistabelle an, die jeweils zur Anwendung kommt) .
Beispiel-Ergebnisse II
Die Suchkriterien werden wie oben gewählt, jedoch die aktuelle Serverzeit als ein angebbares Zeitfenster, beispielsweise ein Tag, eine Woche oder ein Monat.
Die folgende Tabelle enthält die Teilpreise für das Produkt Päckchen+Rollenservice und Paket 10kg:
Figure imgf000073_0002
Beispiel -Ergebnisse II (die römischen Ziffern hinter den Preisen geben die Preistabelle an, die jeweils zur Anwendung kommt) .
Preis-Attribute
Die folgende Tabelle beschreibt die Attribute eines einzelnen Preises : Attribut Beschreibung
; Angaben zu Marktplatz und Zeitfenster, siehe auch
Referenz auf ein Basisprodukt oder Service, dessen Preis in diesem Datensatz abgelegt ist ("TAS-Abholung") Bruttopreis ("2,10")
Mehrwertsteuerpflichtig: Ja/Nein (interne Speicherung: NULL oder z. B. MWST-D)
Phase II: eine optionale Referenz auf ein einzelnes Produkt der Positivliste; in diesem Fall wäre die Zeile der Positivliste beschrieben, zu der der Preis gehört; das Attribut Basisprodukt/Service beschreibt dann die Spalte innerhalb dieser Zeile.
Attribute eines Preises
Abholung und Abholpreis
Eine Abholung erfolgt für Teile des Warenkorbes oder, was besonders bevorzugt ist, für den gesamten Warenkorb.
Die Buchung der Abholung geschieht explizit auf der Seite NOWl oder implizit durch die Eingabe eines Gutscheincodes, der eine TAS-Abholung beinhaltet.
Durch die Beifügung des Gutscheincodes an eine Postsendung o- der durch eine Übermittlung des Gutscheinscodes an einen ers- ten Empfänger einer Postsendung ist es möglich, Retourenlabel zu erzeugen. Durch die Erzeugung von Retourenlabeln wird die Erfindung zu einem Verfahren zur Handhabung von Retouren weitergebildet .
Die Preise für die Abholung werden gestaffelt (maximal 5 Einträge) angegeben, beispielsweise wie in folgender Tabelle:
Figure imgf000075_0001
Beispiel für eine Preisstaffelung
Es wird die Anzahl aller abholfähigen Sendungen (anhand Positivliste) im Warenkorb benutzt, um den Preis in der Tabelle zu finden. Bei mehr als 5 Sendungen wird der letzte Preis der Tabelle benutzt (nach der Beispieltabelle ist also eine Abholung ab 5 Sendungen immer kostenlos - wobei es sich hier um eine exemplarische Darstellung handelt) .
Definition der Staffelung
Die Preisstaffelung für die Abholung kann analog zu den anderen Preisen hierarchisch angegeben werden.
Figure imgf000075_0002
Definition einer Preisstaffel
Bausteine
Bausteine stellen einen rechteckigen Bereich auf einer Webseite dar und können hierarchisch konfiguriert werden. Sie enthalten ein HTML-Fragment, welches ggf. wiederum einzelne Images, css-Files etc. referenzieren kann. Bausteine werden über einen logischen Namen angesprochen.
Figure imgf000076_0001
Attribute eines Bausteines
Gutscheine
Über den Verkauf von Gutscheinen auf der Webplattform in Pake- ten sollen dem Kunden Preisvorteile eingeräumt werden können. Weiter sollen spezielle Marketingaktionen möglich sein, in deren Rahmen Gutscheine bzw. deren Codes beispielsweise über Printmedien verteilt werden.
Attribut Beschreibung
IAngaben zu Marktplatz und Zeitfenster.
Möglichst eindeutiger Name für die Gutscheindefinition; wird zur Anzeige beinutzt .
Kurze Beschreibung; zur Anzeige im Warenkorb
Promotions- oder Kaufgutschein Referenz auf genau ein Produkt in der Positivliste
(Nur bei Promotionsgutscheinen) Maximal 5 Einzelpositionen Beispielsweise "10er" Preis für die spezielle Stückelung Eindeutiger Produktschlüssel Die Stückelung, die als Vorgabe benutzt werden soll.
Nur bei MP-Aktion: in welchem Zeitfenster wird der Gutschein auf der Webseite angeboten; Datum-von und Datum-bis Pflichtfelder
Wie lange in Tagen ist der Gutscheincode ab Kaufdatum gültig?
Bis zu welchem Datum ist ein Gutscheincode gültig?
Ist ein Gutscheincode einmalig oder mehrfach benutzbar?
Numerischer Schlüssel, über den die Reihenfolge bei der Anzeige der Gutscheindefinitionen gesteuert wird.
Attribute einer Gutscheindefinition
Gutscheindefinition
Bevor Gutscheine vom Anwender gekauft oder im Rahmen von Mar- ketingaktionen verteilt werden können, müssen auf administrativer Ebene Gutscheine definiert werden.
Gutscheinname
Gutscheindefinitionen werden über ihren bei der Anlage frei vergebbaren, aber möglichst eindeutigen Namen (Screenname) angesprochen.
Gutscheintyp
Bei der Anlage der Gutscheindefinition wird festgelegt, ob es sich um einen Promotionsgutschein oder um einen vom Anwender käuflich zu erwerbenden Gutschein (Code) handelt.
Produktreferenz
Bei der Definition eines Typs wird genau ein Produkt der Positivliste referenziert . Diese Angabe bestimmt, ob ein Gutschein auf eine Sendung angewandt werden kann: Stimmen die Basisprodukte überein und sind alle Services des referenzierten Produktes im Sendungsprodukt enthalten, so ist ein Anwenden möglich. Eine gewählte Sendung kann damit mehr Services enthalten als im referenzierten Produkt definiert, jedoch nie weniger. Wert eines Gutscheines
Ein Gutschein kann entweder einen absoluten Geldbetrag dar- stellen ("Wert 10 Euro") oder genau für das Produkt einlösbar sein, für welches er hinterlegt ist {100%-Gutschein) .
Die Verrechnung erfolgt dann nur für diese Bestandteile, d.h. sich eventuell durch die Gutscheinverrechnung ergebende nega- tive Preise werden auf den Preis 0 Euro abgebildet.
Beispiel :
Der 100%-Gutschein deckt das Produkt "Paket inklusive TAS- Abholung" ab, für die Sendung im Warenkorb ist das Produkt "Paket mit TAS-Abholung und Rolle" vom Anwender ausgewählt. Als Folge muss der Anwender nur noch den Service "Rolle" bezahlen.
Der "Wert" eines Gutscheines kann unvollständig ausgeschöpft werden, beispielsweise wenn ein Gutscheinpreis über dem aktuell gültigen Preis für "abgedeckte" Produkte liegt; der Restwert des Gutscheines verfällt in diesem Fall.
Stückelung (nur für Kaufgutschein)
Der Anwender kann Gutscheine in Paketen kaufen. Hierzu kann eine Stückelung mit bis zu 5 verschiedenen Stückelungsgrößen definiert werden (z.B. "5er, 10er, 20er, 50er, 100er") . Für jede Stückelungsgrδße wird ein separater absoluter Preis in- klusive Umsatzsteuerangabe definiert. Eine der Stückelungen wird als Vorgabewert definiert. Gültigkeit für Verkauf
Über ein Zeitfenster wird definiert, in welchem Zeitraum der Gutschein dem Anwender zum Kauf angeboten wird. Das Ende des Zeitfensters kann begrenzt oder unbegrenzt sein.
Informationen zur Einlösbarkeit
Käuflich erwerbbare Gutscheine können erst nach dem Kauf eingelöst werden, d.h., erst nachdem sie bezahlt worden sind und dem Anwender in Form von Gutscheincodes vorliegen.
Über ein Zeitfenster wird festgelegt, in welchem Zeitraum ein einzelner Gutscheincode eingelöst werden kann. Entweder ist dies eine relative Angabe in Tagen ("maximal 30 Tage nach Kauf einzulösen") oder ein absolutes Datum ("bis 31.12.2007").
Kaufgutscheine können immer nur einmal benutzt werden. Bei Promotionsgutscheinen kann alternativ angegeben werden, ob die Codes beliebig oft nutzbar sind. Diese sind dann auch für ein oder mehrere Sendungen innerhalb eines einzelnen Warenkorbes einlösbar.
Beispielsweise können für Printaktionen Gutscheine erzeugt werden, die beliebig oft nutzbar sind. Alternativ können für E-Mail-Aktionen auch Promotionsgutscheine erzeugt werden, die analog zu Kaufgutscheinen nur einmalig benutzbar sind.
Unabhängig vom Gutscheintyp gilt jedoch immer, dass pro Sendung nur maximal ein Code einlösbar ist. Markplatz
Optional kann ein Gutscheintyp einem einzelnen Marktplatz zugeordnet werden. Die Gutscheine werden dann nur auf diesem Marktplatz zum Kauf angeboten. Die gekauften Gutscheincodes sind ausschließlich auf diesem einen Marktplatz einlösbar.
Anzeige-Sortierung
Jedem Gutschein ist eine numerische Sortierzahl zugeordnet, über die die Anzeige-Reihenfolge bestimmt werden kann.
Gutscheincodes
Gutscheincodes werden entweder beim Kauf eines Gutscheinsets oder bei der Generierung von Promotionscodes über das Admin- Web erzeugt .
Ein einzelner Gutschein ist über diesen eindeutigen alphanume- rischen Bezeichner (Gutscheincode) definiert, der nicht ohne weiteres erratbar sein sollte. Der Code ist mit zugehörigen Daten im System hinterlegt .
Als Bestandteil des 8-stelligen Gutscheincodes sind folgenden 31 Zeichen gültig:
- Ziffern „2" bis „9" und die
- Buchstaben „A"-„H", „K"-„N", „P"-Z"
Dies ergibt eine theoretische Menge von 852.891.037.441 (ca. 850 Milliarden) Gutscheincodes. Kollisionen, d. h. mehrfache Verwendung desselben Codes und die Erratbarkeit eines fremden Codes, soll somit verhindert werden. Warenkorb-ID
Jeder neu erstellte Warenkorb ist mit der Generierung einer eindeutigen numerischen Warenkorb-ID verbunden. Diese wird dem Kunden auf der Seite NOW3 angezeigt. Außerdem erscheint sie bei erfolgreicher Buchung auf dem Kontoauszug des Anwenders. Anhand dieser ID können Anwender beispielsweise bei telefonischen Support-Nachfragen ihren Warenkorb referenzieren.
Validierungen vor der Anzeige von NOWl
Diese Prüfungen werden jedes Mal vor Anzeige der Warenkorb- Seite NOWl durchgeführt. Status- und Fehlermeldungen werden sendungsbasiert oder für den ganzen Warenkorb angezeigt.
Jede Sendung wird überprüft, ob sie fehlerfrei ist; dies wird ggf. über Status- Informationen in der Sendungsposition optimiert. Die pro Sendung angezeigten Informationen und Fehlermeldungen werden aktualisiert.
- Bei gebuchter TAS-Abholung wird überprüft, ob der Abholzeit- punkt noch gültig ist und die Abhol -Adresse TAS-leitcodier- bar ist, falls dies noch nicht geprüft wurde. Im Fehlerfall wird dem Anwender eine Warenkorb-bezogene Fehlermeldung auf NOWl angezeigt.
Gutschein einlösen
Wird ein Gutscheincode für eine Sendung eingelöst, so wird an- hand der in der Datenbank hinterlegten Daten überprüft, ob er gültig ist: Ist der Code überhaupt ein gültiger Code, d. h. in der Datenbank vorhanden?
Passt der hinterlegte Gutscheintyp zum Produkt der Sendung, d.h. ist das Sendungsprodukt in der Positivliste des Gut- scheintyps enthalten?
Ist der Gutschein nicht bereits abgelaufen ("Haltbarkeit")?
- Bei Einmal-Gutscheinen:
Ist der Gutschein nicht bereits eingelöst worden (sowohl im aktuellen Warenkorb als auch in der Datenbank) ?
Warenkorb bezahlen
In diesem Absatz werden die Vorgänge beschrieben, die durchgeführt werden, wenn der Anwender auf der Seite NOWl die Aktion "Weiter zur Bezahlung" ausführt.
Grundsätzliche Validierungen
Zuerst werden die Prüfungen wie in Paragraph 0 beschrieben durchgeführt. Falls diese oder eine der folgenden Bedingungen nicht erfüllt ist, wird dies dem Anwender in Form eines Fehlertextes auf der Seite NOWl angezeigt.
Ist der Warenkorb leer?
- E-Mail -Adresse erfasst und plausibel (Regular-Expression- Validierung) ?
- ABGs akzeptiert?
- Falls der Preis des Warenkorbes nicht "0" ist (beispielsweise alle Sendungen über Gutschein abgegolten) : o Payment-Art ausgewählt? Ggf. auch BLZ erfasst? o Liegt der Wert des Warenkorbes innerhalb des für den Marktplatz und Payment-Art konfigurierten Bereichs?
- Falls eine TAS-Abholung gebucht ist:
Validierung der Empfänger-Adressen (Anforderung der TAS- Schnittstelle; kann in einem Aufruf für n Adressen erfolgen) .
Sind eingelöste Gutscheincodes immer noch gültig? (Diese Validierung wird zwar bereits bei der Eingabe der Codes durchgeführt, hier aber sicherheitshalber wiederholt, da der Code in einer anderen Session ebenfalls verwendet werden konnte.)
Hat sich der Warenkorb-Preis im Vergleich zur letzten Preisberechnung und dem aktuell neu berechneten Preis verändert? Falls ja, werden dem Anwender die aktualisierten Preise in NOWl mit einem Hinweistext angezeigt, worauf er erneut die Bezahlaktion anstoßen kann.
Vorbereitung der Bezahlung
Die Vorprüfungen haben ergeben, dass die Daten des Warenkorbes gültig sind und der Bezahlvorgang vorbereitet werden kann.
Hieran schließt sich ein Persistieren der Warenkorb-Daten in der Datenbank als weiterer Schritt an.
Ist dieser Schritt fehlerfrei verlaufen und ist der Preis des Warenkorbes nicht "0", so wird der Anwender auf die Seiten des Payment-Providers weitergeleitet (Redirect-Anweisung an den Web-Browser des Anwenders) .
Bricht er dort den Bezahlvorgang ab, so wird er wieder auf die Seite NOWl geleitet, bekommt dort eine entsprechende Meldung angezeigt und kann den Warenkorb weiterhin bearbeiten. Ist der Bezahlvorgang erfolgreich durchgeführt worden, so geht es mit dem nächsten Schritt weiter.
Aktionen unmittelbar nach Bezahlung
Nach erfolgreicher Bezahlung bekommt POP eine Rückmeldung vom Payment-System. Anschließend werden folgende Aktionen durchgeführt :
Warenkorb-Daten als bezahlt markieren,
Gutscheincodes verbrauchen,
Daten für PDF-Generierung ablegen; Document-IDs generieren; Nummern aus Nummernkreisen entnehmen,
- ggf. TAS-Abholungen beauftragen,
- Umschlagdaten für EDICC in DB ablegen, E-Mail an den Anwender versenden.
Treten während dieser Schritte Fehler auf, so versucht die An- wendung trotzdem, möglichst alle weiteren Schritte durchzuführen. Ein Rollback wird nicht durchgeführt, da die Schnittstellen teilweise keine Stornomöglichkeiten zur Verfügung stellen. Warnungen und Fehlermeldungen, die während dieser Prozesse auftreten, werden natürlich persistent in die Datenbank abge- legt.
PIN / PIN2
In der BestätigungsE-Mail des Anwenders ist ein Link mit ange- hängtem Schlüssel eingebettet, über den er die Seite NOW3 auch nachträglich öffnen kann. Falls der Warenkorb einen gewissen Wert übersteigt, wird dieser Zugang zusätzlich über die Einga- be einer PIN bzw. PIN2 abgesichert (jeweils vierstellige numerische Werte) . Die PIN bekommt der Anwender unmittelbar nach Erwerb des Warenkorbes auf der Seite NOW3 - versehen mit einem entsprechenden Hinweistext - angezeigt. Alternativ kann er auch die PIN2 eingeben, die er auf seinem Kontoauszug finden kann.
PDF Label
Die Anwendung "PDF Label" erzeugt PDFs mit Labein, die vom
Nutzer ausgedruckt und auf die Sendung (Päckchen, Paket, etc.) geklebt werden kann.
In einer bevorzugten Ausführungsform hat das PDF folgende Be- standteile:
Das eigentliche Postage-Label : Label o als Musterdruck und o als Portodruck. - Einlieferbeleg.
Ein elektronischer bzw. PDF-Umschlag um das Postage-Label, der den Einmaldruck steuert .
Produktabhängige Label
Zu jeder Produkt- Service- Kombination kann - aber muss nicht - in der Anwendung eine entsprechende PDF-Vorlage für die Erzeugung des Labels hinterlegt werden.
Felder des Labels
Die folgende Aufteilung der Bestandteile entspricht der Fachspezifikation Common Label . Produkt / Logo-Block
Der Produkt/Logo-Block enthält ein Logo eines Unternehmens und den Produktnamen des Basisprodukts. Der Produktname wird der aus der Produktkonfiguration ermittelt.
Absenderblock
Der Absenderblock entspricht der Common Label Spezifikation in der nachfolgenden Tabelle:
Figure imgf000087_0001
Ist ein Datenfeld zu lang für die von der Common Label Spezi- fikation vorgesehene Anzahl der Zeichen, wird der Eindruck rechts abgeschnitten.
Empfängerblock
Der Empfängerblock entspricht der Common Label Spezifikation in der nachfolgenden Tabelle:
Figure imgf000087_0002
Es gelten die gleichen Einschränkungen wie bei dem Absenderblock.
Produkteigenschaftsblock
In den Produkteigenschaftsblock können produktspezifische Zeichen eingedruckt werden. Der Inhalt des Eindrucks wird pro Produkt konfiguriert .
Sendungsinformationen-Block
Im Sendungsinformationen-Block werden folgende Informationen eingedruckt :
Figure imgf000088_0001
Kundeninformationen-Block / 2D-Barcode-Block
Der Kundeninformationen-Block wird von der Anwendung nicht verwendet . Es ist vorteilhaft, einen Einlieferbeleg zu erstellen.
Dieser Einlieferbeleg weist ein übliches Papierformat (bei- spielsweise DIN A 6 bis DIN A 4) auf. Bevorzugte Daten des Einlieferbeleges sind:
Figure imgf000089_0001
Allgemein
Bei einer Weiterbildung der Erfindung wird das zu druckende Label wird mit einem PDF-Umschlag versehen. Innerhalb dieses Umschlags wird in Kommunikation mit einem Lizenzservice der Druck des in dem PDF-Umschlag enthaltenen Dokumentes gesteuert . Zur Berücksichtigung hiervon werden diese Dokumente in der vorliegenden Anmeldung als iPDF bezeichnet.
Folgende Prozessschritte werden hierbei vorgenommen: POP-Anwendung : Während der Generierung (oder eventuell auch im Vorfeld) des PDF wird jedes PDF mit einer eindeutigen, durch den Nutzer nicht durch Ausprobieren zu erratende Dokument-ID verknüpft. Diese Dokument-ID wird einerseits in das iPDF 'eingebettet', andererseits auch in einer Datenbanktabelle der POP-Anwendung eingefügt .
Fig. 3 zeigt eine schematische Darstellung einer Integration einer Dokumentenerzeugung in ein erfindungsgemäßes System.
Das dargestellte System beinhaltet einen Server, der eine Ü- bertragung darstellbarer Inhalte ermöglicht.
Die darstellbaren Inhalte bestehen aus statischen Inhalten und dynamischen Inhalten.
In der dargestellten Ausführungsform werden die statischen Inhalte als PDF-Templates in ein zu erzeugendes Dokument eingebracht .
Dynamische Inhalte werden von einem geeigneten Server, vor- zugsweise einem POP-Web-Server 302 in einen Dokumentendatensatz 303 eingebracht. Diese dynamischen Inhalte werden ggf. durch weitere Inhalte ergänzt . Bei den weiteren Inhalten kann es sich - je nach beabsichtigtem Einsatz - um statische Inhalte oder um dynamische Inhalte handeln. Eine Hinzufügung von dynamischen Inhalten ist bevorzugt, da sich hierdurch auf eine besonders einfache und zweckmäßige Weise identifizierbare Dokumente erstellen lassen.
Dies geschieht in einer besonders bevorzugten Ausführungsform der Erfindung dadurch, dass die dynamischen Inhalte mit Lizenzierungsinformationen 304 verknüpft werden. Nachfolgend wird die Erfindung am Beispiel der Erzeugung von Labein erläutert. Bei den Labein handelt es sich beispielsweise um Adresslabel und/oder Frankierlabel. Derartige Label eignen sich insbesondere für eine Steuerung logistischer Vorgän- ge, beispielsweise Tracking und Tracing sowie für die Steuerung logistischer Prozesse beispielsweise für die Sortierung von Postsendungen.
Für diesen Zweck sind die Label vorzugsweise maschinenlesbar ausgestaltet.
Das zu druckende Label wird mit einem PDF-Umschlag versehen. Innerhalb dieses Umschlags wird in Kommunikation mit dem Server eine Übertragung der Lizenzierungsinformationen 304 ermög- licht.
Durch Einbeziehung der Lizenzierungsinformationen 304 wird somit ein Lizenzservice für den Druck des PDF-Umschlages bereitgestellt . Der Lizenzservice steuert den Druck des in dem PDF- Umschlag enthaltenen Dokumentes.
Da auf diese Weise intelligente Dokumente bereitgestellt werden, werden sie nachfolgend als iPDF bezeichnet.
Folgende Prozessschritte werden hierbei vorgenommen: POP-Anwendung :
Während der Generierung (oder eventuell auch im Vorfeld) des PDF wird jedes PDF mit einer eindeutigen, durch den Nutzer nicht durch Ausprobieren zu erratende Dokument-ID verknüpft.
Diese Dokument-ID wird einerseits in das iPDF 'eingebettet1, andererseits auch in einer Datenbanktabelle der POP-Anwendung eingefügt . Für die Umsetzung der Verhinderung von Mehrfachdrucken werden innerhalb des zum Anwender gelieferten PDFs Mechanismen eingebaut, die vor jedem Druck überprüfen, ob das Dokument bereits einmal gedruckt wurde .
Für diese Überprüfung muss aus dem Acrobat Reader eine Verbindung mit einem von der POP Anwendung gestellten Service aufgenommen werden, über die diese Überprüfung vorgenommen wird.
Nachdem der Nutzer über die Bezahlfunktionalität der Anwendung ein Produkt gekauft hat, sind auch alle Daten für die Generierung der PDFs vorhanden.
Zu diesem Zeitpunkt generiert die Serveranwendung für jedes aus dem Warenkorb zu generierenden PDF einen Datensatz, in dem alle für die Generierung notwendigen Angaben bereits vollständig aufgelöst sind.
Ein für die Kontrolle des Einmaldrucks vorteilhafter Datensatz ist nachfolgend dargestellt.
Dokumenten-Datensatz
Figure imgf000092_0001
Figure imgf000093_0001
FormularData hält in einer strukturierten Form (XML) bezüglich der einzudruckenden Daten alle bereits aufgelösten Daten. So werden z. B. die bereits generierten Päckchen- Identifizierer, Leitcodes und evt . weitere Angaben (auch Preise, auch wenn dies zurzeit nicht vorgesehen ist) bereits als Zahlen oder Zeichenketten vorgehalten. Eine nachträgliche Berechnung solcher Daten ist nicht vorgesehen, da diese evtl. zu anderen Ergebnissen kommen könnte.
Weiterhin müssen in diesem FormularData-FeId Referenzen auf die PDF-Vorlage sowie die Koordinaten für den Eindruck vorgehalten werden. Hierfür werden Ressourcen- IDs aus dem Konfi- gurations-Repository verwendet. Da sich die hinter einer Ressourcen-ID stehende Ressource während der Lebenszeit der Anwendung (sprich auch bei geänderter Version durch Änderung der Anwendungskonfiguration) nicht ändert, wird eine Generierung des PDF stets zu gleichen Ergebnissen kommen.
Auf die dargestellte Weise ist es möglich, PDFs oder andere intelligente Dokumente im Sinne der Erfindung anhand eines Do- kumenten-Datensatzes zu generieren. Der Dokumenten-Datensatz hat beispielsweise die zuvor dargestellten Feldinhalte.
Nach Aufruf einer geeigneten Aufforderung kann dem Nutzer über eine URL eine Dokument -ID für den späteren Download in Form einer URL zur Verfügung gestellt werden. Beispiel : http : //pop . dhl . de/getPDF?documentId=abxkdl2fszoδafwg3 Oy
Anhand der Dokument-ID kann direkt ein PDF erzeugt werden.
Da das vom Nutzer downgeloadete Dokument lediglich ein leeres Formular darstellt, kann ein allgemeines - eventuell für jedes Produkt (Produktschlüssel) individuelles - PDF zur Verfügung gestellt werden.
Das Servlet, das das PDF ausliefert, muss nun lediglich den Dateinamen für das PDF so umbenennen, dass die Dokument -ID im Dateinamen enthalten ist.
Signieren des Dokumentes über ARES 306
Die Vorlagen werden offline während der Entwicklung bzw. Vorbereitungsphase für ein neues Produkt durch den Acrobat Reader Extension Server signiert .
Das durch ARES 306 signierte Dokument wird dann in der Anwendung in das Konfigurations-Repository eingespielt.
iPDF Umschlag, Muster- und Portodokument
Nachdem der Anwender das generierte PDF heruntergeladen hat, wird ihm auf der ersten Seite der Umschlag des PDF angezeigt.
Es ist vorteilhaft bei dem Laden des PDFs in einem geeigneten Leseprogramm, insbesondere einem Acrobat Reader einzelne, mehrere oder sämtliche folgender Prüfschritte vorzunehmen: Kompatibilität des Leseprogramms Bestehen einer Internetverbindung Gültigkeit der Dokumenten-ID - Überprüfung, ob bereits ein Ausdruck erfolgte.
Für die letzten beiden Prüfungen wird über die SOAP- Schnittstelle des Acrobat Readers ein von der Anwendung zur Verfügung gestellter Service aufgerufen, der zurück gibt, ob die übermittelte Dokumenten-ID vorhanden ist und/oder bereits als gedruckt in der Datenbank markiert wurde.
Mittels der Dokument-ID werden dann die Formularfelder über die SOAP-Schnittstelle vom POP-eigenen Server geladen und in die Formularfelder gefüllt.
Konnte die Dokumenten-ID nicht ermittelt werden - z.B. da der Anwender das PDF-Dokument umbenannt hatte - , wird er über ein Acrobat Formfeld aufgefordert, die Dokumenten-ID einzugeben. Die Dokumenten-IDs werden dem Nutzer in der ihm zugesendeten
E-Mail zusätzlich mitgeteilt.
Für den Musterdruck werden für die Barcodes Dummy-Codes verwendet . Die korrekten Barcodes werden erst für den Portodruck durch JavaScript kurzzeitig gesetzt.
Verwendete PDF-Reader Funktionalität (Technologie)
Für die dynamische Abfrage des Lizenzservers aus dem Acrobat Reader heraus nutzt die Anwendung folgende JavaScript-
Funktionen: - app.viewerVersion: Für das Überprüfen der Reader-Version.
SOAP.*: Für das Prüfen auf InternetVerbindung.
document .getField ( "feldname" ) .display = display .hidden / display.visible: Für das Ein- und Ausblenden von "Muster" Überdrucken.
document .print ( {bUI : true, nStart : 1, nEnd: 1, bSilent : true, bAnnotation: true}) bzw. document .print ( {bUI : false, nStart : 1, nEnd: 1, bSilent: true, bAnnotation: true}): Für das direkte Drucken des Dokumentes ohne Nutzerinteraktion.
Die eigentlich zu druckenden PDFs werden als Annotation- Formfelder hinterlegt (ursprünglich für ein visuelles Feedback - z.B. beim Drücken eines Buttons - gedacht, um zwischen gedrücktem und nicht gedrücktem Zustand zu unterschei- den) und nur unmittelbar vor dem Druck auf "visible" geschaltet .
Barcode-Felder. Der Acrobat Reader unterstützt Formfelder, die zu einem Wert (i.d.R. Zahlenwert) einen entsprechenden Barcode anzeigen.
- Alternativ können für Barcode-Felder spezielle Fonts verwendet werden, die im dem Dokument eingebettet werden.
Für Barcodetypen, die der Acrobat Reader weder intern, noch durch zusätzliche Schriftarten unterstützt, kann der Barcode als Bitmap-Image über eine externe URL geladen werden. Hier- zu müsste in der Anwendung ein Servlet-Service implementiert werden, der das entsprechende Bitmap generiert und zur Verfügung stellt.
Die dargestellten Funktionalitäten weisen mehrere Vorteile auf: Da der Nutzer keine individualisierten PDF downloaded, müssen die PDFs nur pro Template/Produkt über den ARES-Server signiert werden.
Das hat zur Konsequenz, dass ein ARES 306 während des Normal - betriebes von der Anwendung nicht benötigt wird.
Es ist zweckmäßig, den ARES 306 für eine Einführung neuer Dokumenttypen - insbesondere für eine Einführung neuer Produkte eines Diensteanbieters - einzusetzen, um einmal das entsprechende PDF zu signieren. Innerhalb der Anwendung wird dann das signierte Dokument als Ressource eingeführt. Diese Installation des ARES 306 kann auf einem beliebigen Rechner geschehen. Das Interface für das Signieren einer Dokumentvorlage kann einfach gestaltet sein.
Der Download der PDFs ist ein einfaches - quasi statisches - Ausliefern einer Datei durch die Pop-Anwendung. Eventuell Performance-relevante Prozesse für den Eindruck entfallen.
Die PDFs können mit Standardwerkzeugen, die beispielsweise von dem Unternehmen Adobe bereitgestellt werden, erstellt werden (mit Acrobat-Professional können die Position der Formfelder definiert werden) . Das Befüllen der PDF-Formfelder innerhalb des Acrobat Readers ist eine Standardfunktion.
Weiterhin entfallen durch den Wegfall der Notwendigkeit des Signierens jedes einzelnen individuellen PDFs auch an dieser Stelle eventuell auftretende Fehlerquellen bzw. Performance- Engpässe.
Die zuvor gewählte Darstellung bezieht sich auf PDF-Dokumente. Es ist jedoch gleichfalls möglich, Dokumente und Programme mit vergleichbaren Funktionen einzusetzen. Dokumente im Sinne der vorliegenden Erfindung sind vorzugsweise graphisch darstellbar. Je nach Einsatzgebiet sind sie manuell oder maschinell erfassbar. Es ist je nach Einsatzgebiet ferner zweckmäßig, eine Verschlüsselung vorzusehen.
Die Erfindung umfasst auch Dokumente, die nicht graphisch darstellbar sind. Dokumente im Sinne der Erfindung sind insbesondere Smart-Label. Smart-Label sind RFID-Identifikationsmittel (Transponder) . Diese eignen sich für einen Einsatz von Steuerungsprozessen bei der Bearbeitung oder Beförderung von physischen Objekten, insbesondere von Postsendungen oder anderen zu transportierenden Gütern.
Die dargestellten Ausführungsformen der Erfindung sind mit einer Vielzahl von Vorteilen verbunden:
• Es ist möglich, das Layout der Label auf einfache Weise zu ändern und in begrenztem Umfang sogar die Funktionalität des "intelligenten PDFs" anzupassen, ohne die Anwendung neu ausrollen zu müssen, d.h. es wird nur die PDF-Vorlage ausgetauscht .
Alternativ ist es möglich, eine neue Formatvorlage via Kon- figurations-Update / Admin-Tool auf die Produktionssysteme bereitzustellen.
• Es wird eine Performance-Steigerung erzielt, so dass weniger Serverkapazität benötigt wird.
• Datenschutz und Sicherheit werden erhöht, denn im PDF - in der PDF-Vorlage - sind keine anwendungsspezifischen Daten, Adressen, Produktinformationen, ...) enthalten, auch nicht, wenn das PDF abgespeichert wird, nachdem die Daten via SOAP- CaIl zum Drucken übertragen wurden und/oder der Druck angestoßen wurde .
• In besonders bevorzugten Ausgestaltungen der Erfindung ist es möglich, die Konfiguration von Benutzersystemen - insbesondere von eingesetzten Computern der Benutzer - ggf. einschließlich eingesetzter Programmversionen - zu ermitteln und ggf. auch zu protokollieren.
Das Servlet, das das PDF ausliefert, muss nun lediglich den Dateinamen für das PDF so umbenennen, dass die Dokument-ID im Dateinamen enthalten ist.
Signieren des Dokumentes über ARES
Die Vorlagen werden offline während der Entwicklung bzw. Vorbereitungsphase für ein neues Produkt durch den Acrobat Reader Extension Server signiert.
ARES selbst muss nicht in der Produktumgebung installiert sein, sondern extern auf einen einfachen PC mit Linux installiert werden. Hierzu wird ein Kommandozeilenwerkzeug eingesetzt, mit dem man beliebige PDF-Dokumente mit den notwendigen Rechten über den ARES versehen kann.
Das durch ARES signierte Dokument wird dann in der Anwendung in das Konfigurations-Repository eingespielt.
iPDF Umschlag, Muster- und Portodokument
Nachdem der Anwender das generierte PDF herunter geladen hat, wird ihm auf der ersten Seite der Umschlag des PDF angezeigt. Hier werden beim Laden des PDFs im Acrobat Reader folgende Ü- berprüfungen vorgenommen.
- Acrobat Reader kompatibel (Version>= 6.02)?
- Besteht eine Internetverbindung? Ist die Dokument-ID gültig?
- Wurde das Produkt bereits gedruckt?
Für die letzten beiden Prüfungen wird über die SOAP-
Schnittstelle des Acrobat Readers ein von der Anwendung zur Verfügung gestellter Service aufgerufen, der zurückgibt, ob die übermittelte Dokument-ID vorhanden ist und/oder bereits als gedruckt in der Datenbank markiert wurde.
Mittels der Dokument-ID werden dann die Formularfelder über die SOAP-Schnittstelle vom POP-eigenen Server geladen und in die Formularfelder gefüllt.
Konnte die Dokumenten- ID nicht ermittelt werden - z.B. da der Anwender das PDF-Dokument umbenannt hatte -, wird er über ein Acrobat Formfeld aufgefordert, die Dokumenten-ID einzugeben. Die Dokumenten- IDs werden dem Nutzer in der ihm zugesendeten E-Mail zusätzlich mitgeteilt.
Für den Musterdruck werden für die Barcodes Dummy-Codes verwendet . Die korrekten Barcodes werden erst für den Portodruck durch JavaScript kurzzeitig gesetzt.
Die Codes können beispielsweise als Leitcodierung eingesetzt werden . LeitCodierung
Für die Leitcodierung werden zwei verschiedenen Schnittstellen verwendet :
Für die Überprüfung auf Leitcodierbarkeit der Abhol- und Empfängeradressen wird die Schnittstelle "Webbooking - Leit- codeprüfung (eShop, FBE) -Schnittstelle" verwendet. - Für die Generierung von Leitcodes für Empfängeradressen - die auch auf dem PDF Label als Leitcode oder Routing Code als Barcode eingedruckt werden - wird die bestehende Implementation der Anwendung Online Label Druck in der aktuellen Version verwendet.
Online Label Druck Leitcodierung
Für die Leitcodierung der Empfängeradressen wird das Leitcode- Modul der Anwendung Online Label Druck verwendet.
Es wird davon ausgegangen, dass von Seiten der POP-Anwendung über eine im Applicationserver konfigurierte Datasource transparent auf die entsprechenden Tabellen zugegriffen werden kann.
Die Implementierung, die auf diese Leitcodetabellen zugreift, wird von der Anwendung Online Label Druck 1:1 übernommen. Die Pflege und Updates dieser Tabellen bzw. Daten sind nicht Bestandteil dieses SRS. Webbooking - Leitcodeprüfung (eShop, FBE) -Schnittstelle Grundlage
Grundlage der Schnittstellenbeschreibung ist das Dokument
"FBE-Schnittstellenuebersicht_eFiliale_2_0.doc", im Weiteren als Referenzdokument bezeichnet.
Beschreibung
Mit Hilfe der Schnittstelle werden die Abholadresse und die Empfängeradressen auf Leitcodierbarkeit geprüft. Die Schnittstelle liefert keinen Leitcode zurück.
Die Prüfung der Leitcodierfähigkeit erfolgt über eine Funktion des TAS. Es wird somit die Schnittstelle verwendet, die bei der Schnittstelle "Webbooking - Leitcodeprüfung (FBE, TAS) " implizit verwendet wird.
Nicht leitcodierfähige Adressen werden als solche in der GUI markiert .
Semantik der Schnittstelle
Eingabe (LeitcodeRequest .xsd)
Figure imgf000103_0001
Tabelle 1 - Eingabeparameter Leitcodierfähigkeit (LeitcodeRequest .xsd) Adresse Request (TypeAdresseRequest aus PruefAdresse. xsd)
Figure imgf000104_0001
Tabelle 2 - Adresse Request (TypeAdresseRequest aus PruefAdresse . xsd)
Ausgabe (LeitcodeResponse . xsd)
Figure imgf000105_0001
Tabelle 3 - Ausgabeparameter Leitcodierfähigkeit (LeitcodeResponse . xsd) Adresse Response (TypeAdresseResponse aus PruefAdresse .xsd)
Figure imgf000106_0001
Tabelle 4 - Adresse Response (TypeAdresseResponse aus PruefAdresse .xsd)
In der Suchanfrage ist eine ID für die Suchadresse definiert. In der Antwort ist die Adresse mit der gleichen ID im XML- Knoten <GepruefteAdressen> zu selektieren. Ist der PrüfStatus dieser Adresse "OK", gilt die Adresse als leitcodierbar . Ist eine der Adressen nicht codierbar, steht der Service nicht zur Verfügung. Fehlerhandling
Ist die Schnittstelle nicht verfügbar oder hat der Statuscode einen Wert <> 0, steht der Service nicht zur Verfügung. Die fehlgeschlagenen Suchanfragen werden geloggt .
Beschreibung
Erteilt POP Aufträge für TAS-Abholung (en) , erfolgt die Beauftragung mit Hilfe der Schnittstelle "Webbooking - Sendungsbeauftragung (eShop, FBE)". Für jede Warenkorb-Position wird ein Auftrag generiert, d.h. die Abholadresse und Empfängeradresse müssen leitcodierbar sein. Die Leitcodierbarkeit der Ab- holadresse und aller Empfängeradressen wird zuvor über die Schnittstelle "Webbooking - Leitcodeprüfung (eShop, FBE) - Schnittstelle" sichergestellt.
Eine Stornierung wird nicht durchgeführt.
Giropay-Schnittstelle
Mit Hilfe der Schnittstelle erfolgt die Abrechnung der vom Anwender beauftragten Produkte und Services.
Verwendung der Schnittstelle Integration Giropay Button
Auf der Seite NOWl gibt es ein Button Giropay und ein Eingabe- feld für die Bankleitzahl. Dieser Button verzweigt nicht direkt auf Giropay-Seite, sondern öffnet ein Popup, in dem der Anwender aufgefordert wird, seine E-Mail noch einmal zu überprüfen. Wenn der Nutzer die Korrektheit seiner E-Mail -Adresse bestätigt, wird die NOWl Seite erneut geladen. In diesem Re- questzyklus wird von der Anwendung noch einmal der Warenkorb bezüglich eventueller Preisänderungen oder sonstigen Inkon- sistenzen (fehlende Angaben) überprüft.
Bleibt der Warenkorbpreis unverändert, werden folgende Aktionen durchgeführt :
Erzeugen der Dokumentdefinitionen in der DB (Dokument-ID) .
- Erzeugen des Warenkorbes in der DB (WarenkorbID.
Anmerkung: der in der DB persistierte Warenkorb enthält nur diejenigen Daten, die für die Überprüfung der Transaktion und weitere Schritte nach der Bezahlung (NOW3 anzeigen, Erstellung der E-Mail etc.) notwendig sind.
- Prüfen der Bankleitzahl.
Senden der Transaktionsdaten an den PaySolution-Server .
Bankleitzahlprüfung
Es werden die folgenden Pflichtparameter in einer Punkt -zuPunkt-Verbindung über HTTPS mit Authentifizierung übermittelt.
Figure imgf000108_0001
Im gleichen Zyklus antwortet der Giropay-Server mit geeigneten Parametern.
Für die Auswertung der Bankleitzahlprüfung ist lediglich der Antwortparameter rc relevant . Bei einem Antwortparameter rc = 0 wurde eine BLZ übergeben, die am giropay-Verfahren teilnimmt. Es wird ein Bezahlvorgang initialisiert .
Bei einem Antwortparameter rc = 1 wurde eine BLZ übergeben, die nicht am giropay-Verfahren teilnimmt. Der Anwender erhält auf der Seite NOWl die Meldung "Die Bank nimmt nicht am giropay-Verfahren teil".
Bei einem Antwortparameter rc = 2 wurde eine ungültige BLZ ü- bergeben. Der Anwender erhält auf der Seite NOWl die Meldung "Die BLZ ist ungültig. Bitte prüfen Sie die BLZ".
Initialisierung des BezahlVorganges
Es werden die folgenden Parameter in einer Punkt -zu-Punkt- Verbindung über HTTPS mit Authentifizierung übermittelt:
Figure imgf000109_0001
Figure imgf000110_0001
Rückmeldung über Bezahlvorgang
Nachdem der Anwender bei Giropay bezahlt hat, sendet der Pay- Solution-Server eine Bestätigung der Bezahlung an die im Controlcenter (Anwendung des Payment-Providers) hinterlegte UrI. Diese könnte wie folgt definiert werden:
http : //pop.dhl .de/Giropay/confirm. do
Es wird vorrausgesetzt , das in einem definierten Zeitfenster- fenster eine Antwort der Schnittstelle erfolgt.
In der Antwort werden die folgenden Parameter übergeben.
Figure imgf000110_0002
Figure imgf000111_0001
Mittels des Parameters basketid kann die Anwendung nun den Warenkorb (evt. HTTP-Session) aus der Datenbank laden.
Danach überprüft die Anwendung, ob die angegebenen Beträge und Währung mit denen im Warenkorb übereinstimmen. Weiterhin wird eine Prüfung über den Message Authentication Code (MAC) , der in Antwort mitgeliefert wird, durchgeführt. Die MAC wird über die Werte aller übergebenen Parameter in alphabetischer Reihenfolge gebildet.
Falls diese nicht übereinstimmen, wird auf NOW3 eine Fehlermeldung angezeigt und natürlich eine entsprechende Meldung geloggt .
Nach erfolgreicher Prüfung des Warenkorbes werden die Aktionen für die Lieferung des Produktes durchgeführt (ESl/GLOBUSS, E- Mail an Anwender, TAS-/Express-Abholung Beauftragung, etc. PP-) .
Der Anwender kann nun auf NOW3 die PDF-Dokumente herunterladen. Rücksprung von GiroPay zur Anwendung
Als Antwort auf die Rückmeldung des Bezahlvorganges schickt POP dem PaySolution-Server die UrI für den Rücksprung zu.
Dies geschieht in Form eines URL-kodierten Dokumentes, das lediglich den Parameter "rurls" enthält. Die Antwort auf die Benachrichtigung erfolgt möglichst zeitnah.
Der PaySolution-Server führt ein Redirect im Browser des Anwenders auf die gesendete UrI durch. Die Rücksprungadresse sieht dann beispielsweise wie folgt aus:
rurls=http%3A%2F%2Fpop . dhl .de%2FGiropay%2Fresponse . do ; j Session id=1234123
Ein anderes bevorzugtes Bezahlsystem ist das PayPal-Zahlungs- system.
Bevorzugte Schnittstellen zur Einbeziehung des PayPal-Zah- lungssystems sind nachfolgend dargestellt:
PayPal-Schnittsteile
Mit Hilfe der Schnittstelle erfolgt die Abrechnung der vom Anwender beauftragten Produkte und Services. Die Kommunikation zwischen der Anwendung und PayPal erfolgt über einen verschlüsselten (128 Bit Schlüssellänge) HTTP-Request (GET bzw. POST) . Verwendung der Schnittstelle
Die Fakturierung eines Vorganges erfolgt mit der PayPal - Option: "Buy Now and Donations". Es wird der Gesamtbetrag inkl. Steuer dem PayPal-System mitgeteilt und abgerechnet.
Verwendete Verfahren zur Prüfung der Bezahltransaktion
Die PayPal-Schnittstelle bietet zwei Methoden zur Überprüfung des Status und der Korrektheit der Bezahltransaktion.
IPN (Instant Payment Notification)
Bei der IPN wird von PayPal eine feste in der Konfiguration des Händleraccounts bei PayPal definierte URL der Anwendung angesprochen. Über Parameter werden Status und Daten des Bezahlvorgangs an die Anwendung übermittelt.
IPN ist asynchron zum Paymentablauf . Der Zeitpunkt, zu dem ei- ne IPN generiert wird, kann von PayPal nicht garantiert werden. Die IPN wird von der Anwendung auch nach Beendigung der Nutzer-Session verarbeitet.
In der Regel wird eine IPN unmittelbar nach dem Bestätigen der Zahlung auf den PayPal -Seiten ausgelöst.
PDT (Payment Data Transfer)
Beim PDT-Verfahren wird von der Anwendung mittels eines Re- quests auf die URL https : //www. PayPal . com/cgi-bin/webscr der Status des Bezahlvorgangs abgerufen. Siehe Ablauf PayPal im
Positiv-Fall, Schritt 5. Hierzu wird in einer Punkt -zu-Punkt - Verbindung ein Parameterset über HTTPS mit folgenden Parametern übermittelt:
Figure imgf000114_0001
Die Rückgabeparameter beim PDT-Verfahren werden von PayPal als Key-Value Paare im Body des Responses geliefert. Abweichend zum IPN wird im PDT zusätzlich in der ersten Zeile ein String übermittelt, der mit dem Wert "SUCCESS" kennzeichnet, dass die PDT Anfrage aus technischer Sicht erfolgreich war.
Die von PayPal bei den Methoden IPN und PDT im Response an die Anwendung übermittelten Daten sind in den für die Anwendung relevanten Parametern identisch:
Figure imgf000114_0002
Ablauf
Es ist vorteilhaft, das Verfahren so durchzuführen, dass bei PayPal (über die PayPal -Eigene Shop-Konfiguration) nur diejenigen Bezahloptionen aktiviert werden, die spätestens beim Wiedereintritt in die Anwendung eine eindeutige Aussage von PayPal "Bezahlt" oder "Abgebrochen/Nicht Bezahlt" ermöglichen. Ein "Pending" -Status wird von der Anwendung ignoriert bzw. als "Nicht Bezahlt" interpretiert.
In Fig. 5 ist ein Ablaufplan für eine Durchführung eines PayPal -Bezahlungsvorgangs wiedergegeben .
Ablauf PayPal im Positiv-Fall
1. Auf der NOWl wird ein PayPal Button (POST Formular) angeboten.
2. Durch ein POP-Post-Formulars wird der Anwender zu PayPal weitergeleitet .
3. PayPal sendet optional nach erfolgter Zahlung eine IPN (Instant Payment Notification) an die Anwendung, noch bevor der Anwender wieder auf der POP-Anwendung zurückgeleitet wurde. Wird innerhalb der IPN die Transaktion als Bezahlt gemeldet, werden die Aktionen für die Auslieferung der PDFs vorgenommen (EDICC, Versand E-Mail, etc) . Hiermit ist gewährleistet, dass der Anwender auch dann eine E-Mail erhält, wenn er direkt nach dem Bezahlen bei PayPal den Browser schließt und die Anwendung den Redirect von PayPal auf eine POP-Seite nicht mehr erhält.
4. PayPal leitet den Anwender über einen Post oder Redirect den Anwender wieder auf eine Seite der POP-Anwendung.
5. Nach dem Redirect von PayPal zurück zu der POP-Anwendung wird geprüft, ob bereits eine IPN erhalten wurde. Falls keine positive IPN erhalten wurde, wird über das PDT Verfahren von der POP-Anwendung der Status der Sendung nachgefragt. Falls diese von PayPal als Bezahlt gemeldet wird, werden die Aktionen für die Auslieferung der PDFs vorgenommen (EDICC, Versand E-Mail, etc) .
6. Dem Nutzer wird die Seite für den PDF-Download (NOW3) angezeigt .
7. Nachfolgende IPN-Nachrichten, die von PayPal an die POP-
Anwendung gesendet werden, werden von der Anwendung igno- riert .
Grundsätzlich werden alle IPN- und PDT-Nachrichten - auch die von der Anwendung bezüglich des Workflows ignoriert werden - in der Datenbank geloggt, so dass zu einem späteren Zeitpunkt über das Adminweb diese noch nachvollzogen werden können .
Über die Datenbank müssen die asynchron eintreffenden IPN und PDT synchronisiert werden.
Integration PayPal Button
Auf der Seite NOWl gibt es ein Button PayPal. Dieser Button verzweigt nicht direkt auf PayPal-Seite, sondern öffnet ein Popup, in dem der Anwender aufgefordert wird, seine E-Mail noch einmal zu überprüfen.
Anmerkung :
Wenn die E-Mail bereits durch den Maptos-Request gesetzt wur- de, wird das Popup nicht angezeigt, sondern die Seite direkt wieder aufgerufen. Wenn der Nutzer die Korrektheit seiner E-Mail -Adresse bestätigt, wird die NOWl Seite erneut geladen. In diesem Re- questzyklus wird von der Anwendung noch einmal der Warenkorb bezüglich eventueller Preisänderungen oder sonstiger Inkon- sistenzen (fehlende Angaben) überprüft.
Bleibt der Warenkorbpreis unverändert, werden folgende Aktionen durchgeführt :
- Erzeugen der Dokumentdefinitionen in der DB (DokumentID) .
Erzeugen des Warenkorbes in der DB (WarenkorbID. Anmerkung :
Der in der DB persistente Warenkorb enthält nur diejenigen Daten, die für die Überprüfung der Transaktion und weitere Schritte nach der Bezahlung (N0W3 anzeigen, Erstellung der E-Mail) notwendig sind.
Anzeige der NOWl-Seite.
Anstelle des PayPal -Buttons mit dem Verweis auf das E-Mail- Bestätigung-Popup wird nun ein PayPal -Buy-Now HTML-Formular hinterlegt. Die Ziel-URL dieses Formulars verweist nun auf die PayPal -Plattform. Dieses Formular wird sofort über Ja- vascript gesteuert ausgeführt, so dass der Browser sofort zu PayPal springt .
In dem PayPal -Buy-Now HTML-Formular werden folgende Felder gefüllt:
Ziel des Formulars beispielsweise: https : //www. sandbox. PayPal . com/cgi-bin/webscr
Figure imgf000118_0001
Diese Felder (außer cmd) werden innerhalb des Formulars nicht als einzelne HTML-Formfelder codiert, sondern nach dem Verfahren Public-Key RSA 1024bit in das HTML-Formularfeld verschlüsselt (encrypted) gespeichert, so dass eine Manipulation seitens des Anwenders ausgeschlossen werden kann. Der Public-Key wird von PayPal vergeben und innerhalb der Anwendung konfiguriert . Rücksprungadressen:
Rücksprungadressen sind folgendermaßen aufgebaut: http : //pop . dhl . de/PayPal/success ; j sessionid=123456
Die Session der Anwendung wird an die URL angehängt.
Rücksprung von PayPal zur Anwendung
Nachdem der Nutzer bei PayPal den Betrag bezahlt hat, wird von Seiten PayPal auf die Return-URL zurückgesprungen. Bei der Rückgabe werden folgende Parameter übermittelt :
Figure imgf000119_0001
Überprüfung der Zahlung
Falls der Nutzer den Bezahlvorgang nicht abgebrochen und die Zahlung durchgeführt hat, gelangt er zurück zur Anwendung. Ist zu diesem Zeitpunkt der Status des Warenkorbs nicht "Bezahlt", wird anhand des Rückgabeparameters tx mittels des PDT- Verfahren bei PayPal der Bezahlvorgang überprüft. Falls in der ersten Zeile nicht der Wert SUCCESS steht oder der Parameter payment_status ungleich "Completed" ist, geht die Anwendung davon aus, dass die Bezahlung nicht erfolgreich abgeschlossen werden konnte. In diesem Fall wird dem Nutzer auf NOW3 eine Fehlermeldung angezeigt. In allen anderen Fällen prüft die Anwendung die Daten der Bezahltransaktion. Dazu wird über den Parameter custom, welcher die WarenkorbID enthält, die Relation zum entsprechenden Warenkorb in der Datenbank der Anwendung hergestellt.
Der Wert des Parameters "mc_gross" wird mit dem Betrag in der Datenbank verglichen.
Der Wert des Parameters mc_currency wird mit der Währung in der Datenbank verglichen.
Stimmen die Werte überein, wird der Warenkorb des Nutzers als "Bezahlt" markiert. Falls diese nicht übereinstimmen, wird auf NOW3 eine Fehlermeldung angezeigt.
Nach Erfolgreicher Prüfung des Warenkorbes werden die Aktionen für die Lieferung des Produktes durchgeführt (ESI/GLOBUSS, E- Mail an Anwender, TAS-/Express-Abholung Beauftragung, etc.
PP-) •
Der Anwender kann nun auf N0W3 die PDF-Dokumente herunterladen.
Da eine IPN asynchron auftritt, wird von der Anwendung im FaI- Ie einer erfolgreich abgeschlossenen Bezahltransaktion in der Datenbank ein dem Warenkorb zugeordneter Status auf "In Bearbeitung" gesetzt. Cancel
Falls der Nutzer den Bezahlvorgang abgebrochen hat, und die HTTP-Session noch gültig ist, wird er wieder auf NOWl mit sei- nem Warenkorb weitergeleitet. Hat der Nutzer den Bezahlvorgang abgebrochen, konnte jedoch innerhalb der Anwendung wegen eines Timeouts die Session nicht fortgeführt werden, wird dem Anwender N0W3 mit einer entsprechenden Fehlermeldung angezeigt.
Um das System vor Missbräuchen zu schützen und um eine schnelle, zuverlässige und sichere Vornahme von Änderungen zu erreichen, ist es zweckmäßig, ein geschütztes Administrationssystem vorzusehen.
In einer besonders bevorzugten Ausgestaltung ist das Administrationssystem ein Administrations-Web.
Vorzugsweise ist das Administrations-Web Teil der POP- Webanwendung .
Es ist zweckmäßig, eine Protokollierung (Logging) der Aktionen des Administrations-Webs durchzuführen.
Modifiziert ein Anwender Konfigurationsdaten der Anwendung, werden diese Aktionen in den Reportingtabellen mit Username und Zeitstempel protokolliert.
Nutzerverwa1tung
Die Nutzerverwaltung des Administrations-Webs wird über eine einfache Konfigurationsdatei gesteuert, die über das Konfigu- rations-Repository versioniert verwaltet wird. Jedem Nutzer ist eine Liste von Rollen zugewiesen. Diese Rollen entsprechen den Rechten für die Benutzung der einzelnen Bestandteile (sprich Masken) des Administrationswebs.
Durch das dargestellte System ist es möglich, ein Verfahren zum Erzeugen eines auf eine Postsendung aufbringbaren Labels auf verschiedene zweckmäßige Arten durchzuführen.
Insbesondere wird das Verfahren so durchgeführt, dass ein Netzwerkknoten (Maptos) einen Datendienst bereitstellt, der in wenigstens einem Anbieterserver eines Dienstanbieters ausgeführt wird, wobei Daten zum Einbringen in das Label erzeugt werden .
Bei dem Datendienst handelt es sich beispielsweise um einen Internetdienst .
Die Erzeugung des Labels wird so gesteuert, dass ein Druck des Labels erst dann ermöglicht wird, wenn ein Prüfungsschritt durchgeführt wurde. Der Prüfungsschritt dient beispielsweise zur Überprüfung der Gültigkeit eines Gutscheins oder der Überprüfung, ob ein angefordertes Frankierlabel bezahlt wurde.
Ferner ist es zweckmäßig zu überprüfen, ob ein angefordertes Frankierlabel bereits einmal ausgedruckt wurde. In diesem Fall wird ein erneuter Ausdruck des Frankierlabels verhindert.
Es ist besonders vorteilhaft, die Label beziehungsweise Druckvorlagen zur Erzeugung der Label als intelligente Dokumente bereitzustellen.
Hierbei ist es vorteilhaft, dass ein Programmmodul in das intelligente Dokument eingebracht wird, das dazu ausgebildet ist, eine darstellbare Angabe eines Ergebnisses des Prüfungs- schrittes oder eines weiteren Prüfungsschrittes zur Prüfung des Vorliegens der Voraussetzung innerhalb des intelligenten Dokuments zu erzeugen.
Eine Weiterbildung hiervon sieht vor, dass wenigstens einer der Prüfungsschritte mittels des Programmmoduls durchgeführt wird.
Ein oder mehrere weitere Prüfungsschritte können in dem Anbieterserver, dem Netzwerkknoten oder einer anderen serverbasierten Recheneinheit erfolgen.
Ferner ist es vorteilhaft, dass in dem Prüfungsschritt über- prüft wird, ob die Programmausführungsumgebung zur Verfügung steht.
Um missbräuchliche Mehrfachausdrucke zu verhindern, ist es vorteilhaft, dass ein Programm einen einmaligen Druck des La- bels steuert und dass ein intelligentes Dokument von einem
Server über ein Netzwerk an einen Client übermittelt wird.
Zur weiteren Erhöhung der Datensicherheit wird das Verfahren so durchgeführt, dass bei einem ersten Druck des Labels eine Nachricht von dem Nutzerclient an den Server übermittelt wird und dass der Druck aufgrund der Nachricht in dem Server protokolliert wird.
Um sicherzustellen, dass serverbasierte Sicherheitsmechanismen eingesetzt werden können, ist das zur Steuerung des Drucks der
Label dienende Programm so ausgestaltet, dass es nur dann ausführbar ist, wenn eine Netzwerkverbindung zwischen dem Client und dem Server besteht und wenn anhand einer Abfrage des Ser- vers festgestellt wurde, dass das Label noch nicht gedruckt worden ist.
Dies erfolgt in einer besonders sicheren Ausgestaltung da- durch, dass in wenigstens einem der Prüfungsschritte überprüft wird, ob ein Zugriff auf das Netzwerk besteht.
Eine Weiterbildung sieht vor, dass in wenigstens einem der Prüfungsschritte eine Abfrage des Servers vorgenommen wird, bei der überprüft wird, ob Inhalte des intelligenten Dokuments bereits einmal gedruckt worden sind.
Auf die dargestellte Weise ist es möglich, berechtigten Benutzern auf einfache und zuverlässige Weise ein Ausdrucken von Labein zu ermöglichen. Gleichzeitig wird eine missbräuchliche Erzeugung von Labein verhindert .
Insbesondere ist es durch die Erfindung auch möglich, Gutscheine (Codes) für eine Erzeugung von Labein einzusetzen.
Bei den Gutscheinen kann es sich beispielsweise um vorab bezahlte Portobeträge oder Gutschriften für die Vornahme von Bestell- oder Liefervorgängen handeln.
Die Gutscheine enthalten vorzugsweise geltwerte Informationen. In Weiterbildungen der Erfindung können sie auch für Bezahl - Vorgänge eingesetzt werden.
Ferner ist es möglich, die Gutscheine an Empfänger von Waren- Sendungen zu übermitteln. Die Empfänger der Warensendungen können als Benutzer des Systems Label erstellen. So ist es möglich, auf die erfindungsgemäße Weise Label als Retourenla- bel für eine Rücksendung von Postsendungen an einen Ursprung- liehen Absender - insbesondere ein Versandunternehmen - zu erstellen.
Zur Erzeugung eines als Retourenlabel dienenden Labels wird auf einem ersten Übermittlungsweg ein Gutschein an einen Benutzer übermittelt. Später - insbesondere wenn der Benutzer eine Rücksendung einer Postsendung oder eines in ihr enthaltenen Produkts wünscht - wird der Gutschein (Code) durch eine in einem Einflussbereich des Benutzers befindliche Bedieneinheit an einen Server übermittelt.
Diese Weiterbildung der Erfindung sieht eine mehrschrittige Erzeugung eines Labels vor. Dieses mehrschrittige Erzeugen zeichnet sich dadurch aus, dass auf einem ersten Übermitt- lungsweg ein Gutschein an einen Benutzer übermittelt wird, dass der Gutschein durch eine in einem Einflussbereich des Benutzers befindliche Bedieneinheit an einen Server übermittelt wird und dass der Server einen Prüfungsschritt zur Überprüfung des Gutscheins durchführt und in Abhängigkeit von dem Ergebnis des Prüfungsschritts das Erzeugen des Labels beeinflusst .
Die Übermittlung des Gutscheins an den Benutzer kann auf verschiedene Weise erfolgen.
Eine Weiterbildung der Erfindung sieht vor, dass der Gutschein oder ein Bestandteil des Gutscheins auf verschiedene Übermittlungswege an den Benutzer übermittelt wird.
Eine Übermittlung an den Benutzer erfolgt auch dann, wenn der Gutschein oder ein Bestandteil an eine in einem Einflussbereich des Benutzers befindliche Bedieneinheit übermittelt wird. Dies ist beispielsweise bei einer Übermittlung an einen Computer oder ein mobiles Benutzerendgerät wie ein Mobiltelefon der Fall.
Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts und der Vorrichtung zeichnet sich dadurch aus, dass der Gutschein einer an den Benutzer gerichteten Postsendung beigefügt ist.
Eine Ausgestaltung des Verfahrens, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass der Gutschein elektronisch an den Benutzer übermittelt wird.
Eine Weiterbildung des Verfahrens, des Computerprogrammpro- dukts und der Vorrichtung zeichnet sich dadurch aus, dass der Gutschein bei Eintreten eines Ereignisses an den Benutzer ü- bermittelt wird.
Eine Ausgestaltung des Verfahrens, des Computerprogrammpro- dukts und der Vorrichtung sieht vor, dass der Gutschein bei Eintreten eines Versandereignisses übermittelt wird.
Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts und der Vorrichtung zeichnet sich dadurch aus, dass der Gutschein auf eine Anforderung übermittelt wird.
Eine Ausgestaltung des Verfahrens, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass die Bedieneinheit ein Computer ist.
Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts und der Vorrichtung zeichnet sich dadurch aus, dass der Prüfungsschritt eine Gültigkeitsprüfung des Gutscheins beinhaltet.
Eine Ausgestaltung des Verfahrens, des Computerprogrammpro- dukts und der Vorrichtung sieht vor, dass der Prüfungsschritt eine Gültigkeitsprüfung des Gutscheins beinhaltet.
Eine Weiterbildung des Verfahrens, des Computerprogrammprodukts und der Vorrichtung zeichnet sich dadurch aus, dass un- ter Berücksichtigung des Gutscheins eine Empfängeradresse für die Postsendung ermittelt wird.
Eine Ausgestaltung des Verfahrens, des Computerprogrammprodukts und der Vorrichtung sieht vor, dass unter Berücksichti- gung des Gutscheins eine Absenderadresse für die Postsendung ermittelt wird.
Die Erfindung umfasst auch Dokumente, die nicht graphisch darstellbar sind. Dokumente im Sinne der Erfindung sind insbeson- dere auch Smart-Label . Smart-Label sind RFID-Identifi- kationsmittel (Transponder) . Diese eignen sich für einen Einsatz von Steuerungsprozessen bei der Bearbeitung oder Beförderung von physischen Objekten, insbesondere von Postsendungen oder anderen zu transportierenden Gütern.
Ein Einsatz von Kennungsdaten erhöht die Datensicherheit weiter. Die Kennungsdaten werden vorzugsweise dadurch erkannt, dass eine Signatur für den jeweiligen dynamischen Inhalt erstellt und dass diese Signatur mit dem jeweiligen dynamischen Inhalt übertragen wird.
Zweckmäßigerweise wird die Signatur im Ziel einer jeweils erfolgenden Kommunikation (Zielsystem) erneut erstellt und der sich ergebende Wert - insbesondere Hash-Wert - mit dem sich aus der übertragenen Signatur ergebenden Wert verglichen.
Durch den Vergleich der Werte ist es möglich, eine Manipulati- on der Inhalte zu verhindern, da die jeweilige Anwendungslogik nur dann aktiv wird, wenn die Prüfungen korrekt verlaufen sind.
Die Erfindung beinhaltet auch einen Einsatz anderer Programme als die dargestellten.
Insbesondere ist es möglich, unter Einsatz der dargestellten Ausgestaltung des Systems und der Vorrichtung andere als die zuvor dargestellten Computerprogramme einzusetzen.
Ebenso ist es möglich, andere Dateiformate einzusetzen.
Eine Auswahl der Software sollte so erfolgen, dass mit ihr eine Datei erzeugbar ist, welche folgende Eigenschaften auf- weist:
1. Ein Download der Datei sollte möglich sein.
2. Eine Darstellung und ein Druck des Labels in gleicher Form (Rahmen, Logos, variabler Texte) sollte möglich sein.
3. Ein Druck von Barcode-Labels sollte möglich sein, idealerweise durch Einbindung von FONTs.
4. Eine Applikationslogik (via Java-Script, Visual Basic,
.net, ....) sollte in der Datei verwendbar/aktivierbar sein. Diese Eigenschaft erfüllen beispielsweise auch Adobe-Flash und eine Vielzahl von Microsoft/Windows Produkten aus dem Office-Umfeld.
4.1 Soap-Requests (HTTPs-Requests) sollten möglich sein.
4.2 Ein Druckdialog sollte über die Anwendungslogik ansteuerbar sein.
5. Die Datei sollte schreibgeschützt übertragbar sein.
6. Die Datei sollte gegen die Änderung der Applikationslogik/vor beziehungsweise während der Ausführung (insbesondere beim Drucken) geschützt sein.
Diese Anforderungen werden beispielsweise auch durch Microsoft Excel erfüllt. Zur Erhöhung der Datensicherheit empfiehlt sich hier eine entsprechende zusätzliche Verschlüsselung des eingebetteten Script-Codes, den man dann zusätzlich absichern soll- te.
Es ist zweckmäßig, die intelligenten Dokumente so auszugestalten, dass sie eine Überprüfung von Programmversionen ermöglichen.
Insbesondere ist es zweckmäßig, dass die Dokumente in der Lage sind zu überprüfen, welche Version beziehungsweise welche Implementierung eines Computerprogramms und/oder welches Betriebssystem auf einem Client installiert sind.
Die Erfindung ist nicht auf die dargestellten Einsatzgebiete beschränkt . Bei einer Erzeugung von Labein für Postsendungen ist es zweckmäßig, dass diese Informationen zur Identifikation, zum Leit- wege, zu Vorausverfügungen und zu mit dem Versandauftrag verbundenen Extraleistungen enthalten.
Weiterhin ist es zweckmäßig, dass die Label Kunden- und/oder Abrechnungsinformationen enthalten .
Die dargestellten Label dienen als Informationsträger und er- möglichen beispielsweise eine Annahme, Entgeltabrechnung, Sortierung, Verladung, Sonderbehandlung, Zustellung, Ausgabe, Abrechnung, Nachforschung, Nachbearbeitung, Betriebsdatenverarbeitung, Sendungsverfolgung (Tracking & Tracing) und Archivierung einer Sendung.
Die intelligenten Dokumente - insbesondere die Label für ein Aufbringen auf die Postsendungen - weisen bei Weiterbildungen der Erfindung Informationsblöcke auf. Hierbei ist es zweckmäßig, Datentypen und/oder Datengrößen für die Informationsblö- cke festzulegen. Diese Festlegung erfolgt zweckmäßigerweise entsprechend der jeweiligen logistischen Anforderungen.
Beispiele für dynamische Inhalte, die in den statischen Rahmen eingebracht werden, sind Empfängeradresse und Angaben, welche eine Sendungsidentifikation ermöglichen, beispielsweise eine Sendungsidentifikationsnummer .
Die übermittelten Rahmeninformationen dienen zu einer übersichtlichen, strukturierten und formatierten Darstellung der dynamischen Inhalte.
Figur 5 zeigt eine graphische Darstellung erfindungsgemäß erzeugter intelligenter Dokumente. Die graphischen Darstellungen können beispielsweise an einem Bildschirm eines Clients angezeigt oder ausgedruckt und gegebenenfalls - für einen Einsatz als Versandlabel für eine Postsendung - ausgedruckt werden.
Zur Erzeugung der Dokumente werden jeweils statische Inhalte von den dynamischen Inhalten getrennt übertragen.
Bei den statischen Inhalten handelt es sich beispielsweise um die in den Abbildungen eingezeichneten Rahmen und um Firmenan- gaben wie "DHL" .
Dynamische Inhalte, die in die Sendungen eingebracht werden, sind beispielsweise Absenderangabe, Empfängerangabe, Rechnungsnummer, Größenangaben, Sendungsidentifikationsnummer und/oder gegebenenfalls auch eine Produktbezeichnung.
Fig. 5 zeigt den Labelinhalt beispielhaft in einem DIN A 4- Querformat , nebeneinander liegend.
Es ist für den Fachmann selbstverständlich, die jeweilige graphische Gestaltung der Label einschließlich der wiedergegebenen Informationen - Klarschriftanteile und Maschinenschriftanteile und gegebenenfalls verschlüsselte Informationen - entsprechend den Anforderungen von Versandunternehmen, welche die Postsendungen transportieren beziehungsweise bearbeiten, auszuwählen.
Die dynamischen Inhalte werden in einer Weiterführung der Erfindung von einem Auftraggeber eines Versandvorgangs (Versen- der) in elektronischer Form übermittelt. Die elek-tronische
Übertragung der Sendungsdaten kann vor, während und nach einer physischen Übergabe der Sendungen an ein Versandunternehmen erfolgen. Eine zeitgleiche elektronische und physische Übertragung ist jedoch zur Vereinfachung der logistischen Prozesse bevorzugt.
Zur Übertragung der Daten wird vorzugsweise ein geeigneter Nummernkreis vorgegeben.
Ferner können die Label Handhabungsinformationen - beispielsweise für Mitarbeiter des Versandunternehmens, insbesondere einen Zusteller - enthalten. Es ist möglich und zweckmäßig, für die graphische Wiedergabe einzelner der Handhabungsfunkti- onen ein von sonstigen Labelinhalten abweichendes Format zu wählen.
Die vorherige Beschreibung von Ausführungsbeispielen der Erfindung anhand der Figuren ist illustrativ und beispielhaft zu verstehen. Die Erfindung ist nicht auf die dargestellten Ausführungsbeispiele beschränkt.
Im Zusammenhang mit dem Druck von Labein mittels eines intelligenten Dokuments ist die Erfindung insbesondere nicht auf die dargestellten Übertragungsarten, Formatarten oder Prüfungsschritte beschränkt. Vielmehr erkennt der Fachmann, dass im Rahmen der Erfindung auch andere Übertragungsarten gewählt und/oder andere Formate genutzt und/oder andere Prüfungs- schritte durchgeführt werden können, deren Ergebnisse gegebenenfalls in dem Dokument dargestellt werden.
Der Fachmann erkennt ferner, dass die Erfindung auch auf ande- ren Gebieten als den dargestellten eingesetzt werden kann. So ist es beispielsweise möglich, das Vorhandensein der Programmausführungsumgebung bei jedem beliebigen intelligenten Dokument zu prüfen und das Ergebnis der Prüfung darzustellen.
Bei den intelligenten Dokumenten kann es sich beispielsweise um intelligente Dokumente mit animierten Graphiken oder um Formulare handeln. Insbesondere ist die Erfindung bei Formularen einsetzbar, die im Verkehr mit Behörden verwendet werden und als intelligente Dokumente ausgeführt sind. Anhand der Prüfungsschritte, deren Ergebnisse bei der Erfindung dargestellt werden, kann dabei insbesondere auch geprüft werden, ob bestimmte Pflichtfelder eines Formulars ausgefüllt worden sind.
Darüber hinaus kann die Erfindung auch bei intelligenten Dokumenten eingesetzt werden, die mittels der "Intelligenz" vor einem unberechtigten Zugriff geschützt werden. In diesem Zusammenhang sind etwa Texte zu nennen, die nur dann angezeigt und/oder gedruckt werden können, wenn der Nutzer hierzu be- rechtigt ist, wobei die Berechtigung des Nutzers beispielsweise durch eine über ein Netzwerk erfolgende Serverabfrage von dem intelligenten Dokument geprüft wird.
Die unterschiedliche Handhabung von dynamischen und statischen Inhalten ermöglicht weit reichende Gestaltungsmöglichkeiten für individuell oder in zeitlichen Abständen zu erstellende und/oder zu aktualisierende Dokumente.
Zur Weiterentwicklung von Retourenlogistikprozessen sind OnIi- ne-Frankierlösungen vorteilhaft, wobei sowohl die Einsparung von Prozesskosten als auch die Optimierung der Informationstransparenz möglich ist. Retourenlogistikprozesse bezeichnen logistische Prozesse zur Handhabung von Retouren.
Die Erfindung beinhaltet sowohl die Weiterbildung eines Logis- tiksystems als Retourenlogistiksystem als auch die Ausgestaltung eines Logistiksystems mit Handhabungsvorgängen zur Handhabung von Retouren.
Die Erfindung beinhaltet ein Logistiksystem zum Befördern ei- ner Postsendung auf einem Transportweg innerhalb eines Postverteilnetzes, wobei der Transportweg mehrere Knoten des Postverteilnetzes enthält, insbesondere einen Knoten, der einem Zustellpunkt entspricht .
Gegebenenfalls enthält der Transportweg zusätzlich einen oder mehrere Knoten, die jeweils einem Sortierpunkt entsprechen.
Der Begriff Logistiksystem ist im Rahmen der Erfindung in einer weiten Bedeutung zu verstehen. Er umfasst insbesondere Systeme, welche die Mittel und Einrichtungen enthalten, um den Transport von Postsendungen von einem Abgangsort zu einem Zustellpunkt auf einem Transportweg innerhalb eines Postverteil - netzes durchzuführen.
Bei dem Abgangsort handelt es sich beispielsweise um einen Lagerort oder Einlieferungsort des zu transportierenden Gegenstandes. Der Zustellpunkt wird vorzugsweise von dem Auftraggeber des Transports ausgewählt. Bei einer Rücksendung ist dies beispielsweise ein Lager eines Händlers oder Herstellers.
Auf die dargestellte Weise ist es möglich, die Label schnell, zuverlässig und bedarfsgesteuert zu übermitteln. Insbesondere ist eine Berücksichtigung von Anforderungen eines Versand- dienstleisters, der zunächst eine Ware mit einer ersten Postsendung an den Benutzer übermittelt und eine gezielte Rückführung der Ware durch eine zweite Postsendung wünscht, möglich.
Dies geschieht erfindungsgemäß zweckmäßigerweise dadurch, dass auf einem ersten Übermittlungsweg ein Gutschein an einen Benutzer übermittelt wird, dass der Gutschein durch eine in einem Einflussbereich des Benutzers befindliche Bedieneinheit an einen Server übermittelt wird und dass der Server einen Prü- fungsschritt zur Überprüfung des Gutscheins durchführt und in Abhängigkeit von dem Ergebnis des Prüfungsschritts das Erzeugen des Label beeinflusst .
Die Übermittlung des Gutscheins erfolgt zweckmäßigerweise bei Eintreten eines Versandereignisses, beispielsweise bei einer Einlieferung der an den Benutzer gerichteten Postsendung, bei einem Beförderungs- oder Verarbeitungsschritt der Postsendung oder einer Auslieferung der Postsendung an den Benutzer.
Die Erfindung beinhaltet verschiedene Arten der Übermittlung des Gutscheins und ermöglicht eine Integration verschiedener Übermittlungswege .
Um eine besonders hohe Datensicherheit zu gewährleisten, er- folgt der Prüfungsschritt so, dass er eine Gültigkeitsprüfung des Gutscheins beinhaltet.
Zur Beschleunigung der Verarbeitung ist es zweckmäßig, dass unter Berücksichtigung des Gutscheins eine Empfängeradresse für die Postsendung ermittelt wird. Ferner ist es zweckmäßig, dass unter Berücksichtigung des Gutscheins eine Absenderadresse für die Postsendung ermittelt wird.
Glossar
Abholung TAS
Termin-Abholungs-System Anwender
Endanwender, der die POP-Anwendung nutzt, um Marken oder Gutscheine zu kaufen.
Anwendung
Die Webanwendung ParcelOnlinePostage. Basisprodukt
"Päckchen", "Paket 10 kg", "Paket 20 kg";
Wird beispielsweise für die Gruppierung innerhalb der Produkt- auswahl verwendet .
Baustein Rechteckige statische Fläche in einer Webseite, die zeit- und marktplatzgesteuert eingeblendet werden kann.
BLNN
Beleglose Nachnahme
BHNN Belegbehaftete Nachnahme
Dokumenten-ID
Eindeutige Nummer, über die ein Anwender eine von ihm erworbene Marke referenzieren kann.
EKP-Nummer Eine Art Kundennummer für den Marktplatz.
ESI
Entgeltsicherung (Mittel zum Ermitteln missbräuchlich erzeugter Label .
Gutschein Eine Instanz eines Gutscheintypes; kann über einen eindeutigen
Gutscheincode identifiziert werden.
Gutscheintyp
Eine Klasse eines Gutscheines.
Kunde Begriff wird nicht benutzt, da zweideutig. LP
License Plate.
Marktplatz Jeder Anwendersession ist ein Marktplatz zugeordnet, der eini' ge Rahmenbedingungen wie die Währung vorgibt .
PALS
Photo Anschriften Lese System
PAN Pre Advice Notification
POC
Proove of Collection
POD
Proove of Delivery POM
Proove of Money
POT
Proove of Transport
Produkt Eine Kombination aus Basisprodukt und Services; wird über einen Produktschlüssel identifiziert.
Produktcode
Numerischer, zweistelliger Code für Basisprodukt
ProduktSchlüssel Eindeutiger Schlüssel für eine Basisprodukt-/Services- Kombination. Service Bepreiste Eigenschaft eines Produktes.
Warenkorb-ID Über diese eindeutige Nummer kann ein Anwender bei Supportanfragen seinen Warenkorb referenzieren. Bezugszeichenliste :
301 PDF-Template
302 POP-Web-Server 303 Dokumentendatensatz
304 Li zenzierungsinformationen
305 Intelligentes Dokument (beispielsweise iPDF)
306 ARES

Claims

Patentansprüche
1. Verfahren zum Erzeugen eines auf eine Postsendung aufbringbaren Labels, dadurch gekennzeichnet, dass ein Netzwerkknoten (Maptos) einen Datendienst bereitstellt, der in einem Anbieterserver eines Dienstanbieters ausgeführt wird, wobei Daten zum Einbringen in das Label erzeugt werden.
2. Verfahren nach Anspruch 1 , d a du r c h g e k e nn z e i c hn e t, dass der Datendienst ein Internetdienst ist .
3. Verfahren nach einem der Ansprüche 1 oder 2, d a du r c h g e k e nn z e i c hn e t, dass ein Prüfungsschritt zur Überprüfung eines Gutscheins durchführt und in Abhängigkeit von dem Ergebnis des Prüfungsschritts das Erzeugen des Labels beeinflusst wird.
4. Verfahren nach Anspruch 3 , d a du r c h g e k e n n z e i c hn e t, dass in einem dem Prüfungsschritt vorangehenden Verfahrensschritt der Gutschein an einen Benutzer übermittelt wird.
5. Verfahren nach einem der vorangegangenen Ansprüche, dadurc h gekennz e i chne t, dass ein Programmmodul in das intelligente Dokument eingebracht wird, das dazu ausgebildet ist, eine darstellbare Angabe eines Ergebnisses des Prüfungsschrittes oder eines weiteren Prüfungsschritts zur Prüfung des Vorliegens der Voraussetzung innerhalb des intelligenten Dokuments zu erzeugen.
6. Verfahren nach Anspruch 5 , d a d u r c h g e k e n n z e i c h n e t, dass wenigstens einer der Prüfungsschritte mittels des Programmmoduls durchgeführt wird.
7. Verfahren nach einem der Ansprüche Anspruch 3 bis 6, d a d u r c h g e k e n n z e i c h n e t, dass in dem Prüfungsschritt überprüft wird, ob die Programmausführungsumgebung zur Verfügung steht.
8. Verfahren nach einem der vorangegangenen Ansprüche, dadur ch gekenn z e i c hne t, dass ein Programm einen einmaligen Druck des Labels steuert und dass ein intelligentes Dokument von einem Server über ein Netzwerk an einen Client übermittelt wird.
9. Verfahren nach einem der vorangegangenen Ansprüche, dadur c h gekenn z e i c hne t, dass bei einem ersten Druck des Labels eine Nachricht von dem Nutzerclient an den Server übermittelt und dass der Druck aufgrund der Nachricht in dem Server protokolliert wird.
10. Verfahren nach einem der Ansprüche 8 oder 9, d a d u r c h g e k e n n z e i c h n e t, dass das Programm zur Steuerung des Drucks des Labels nur dann ausführbar ist, wenn eine Netzwerkverbindung zwischen dem Client und dem Server besteht und wenn anhand einer Abfrage des Servers festgestellt worden ist, dass das Label noch nicht gedruckt wurde.
11. Verfahren einem der Ansprüche Anspruch 3 bis 10, d a d u r c h g e k e n n z e i c h n e t, dass in wenigstens einem der Prüfungsschritte überprüft wird, ob ein Zugriff auf das Netzwerk besteht.
12. Verfahren einem der Ansprüche Anspruch 3 bis 11, d a d u r c h g e k e n n z e i c h n e t, dass in wenigstens einem der Prüfungsschritte eine Prüfung der Version der Programmausführungsumgebung stattfindet.
13. Verfahren einem der Ansprüche Anspruch 3 bis 12, d a d u r c h g e k e n n z e i c h n e t, dass in wenigstens einem der Prüfungsschritte eine Abfrage des Servers vorgenommen wird, bei der überprüft wird, ob
Inhalte des intelligenten Dokuments bereits einmal gedruckt worden sind.
14. Computerprogrammprodukt, d a d u r c h g e k e n n z e i c h n e t, dass es ein Computerprogramm zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 13 enthält.
15. Netzwerkknoten, dadur c h gekenn z e i c hne t, dass er einen Datendienst bereitstellt, der in wenigstens einem Anbieterserver eines Dienstanbieters ausgeführt wird, wobei Daten zum Einbringen in ein Label erzeugt werden.
16. System zum Erzeugen eines auf eine Postsendung aufbringbaren Labels, dadurch gekennzeichnet, dass ein Netzwerkknoten (Maptos) mit einem Anbieterserver verbunden ist und dass ein Datendienst bereitgestellt und in dem Anbieterserver ausgeführt wird, wobei Daten zum Einbringen in das Label erzeugt werden.
PCT/EP2007/009183 2006-10-27 2007-10-23 Verfahren zum erzeugen eines labels, computerprogrammprodukt, netzwerkknoten und system zur durchführung des verfahrens WO2008049579A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/447,264 US8477345B2 (en) 2006-10-27 2007-10-23 Method for producing a label, computer program product, network node and system for carrying out the method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP06022477A EP1916627A1 (de) 2006-10-27 2006-10-27 Verfahren zum Erzeugen eines Labels, Computerprogrammprodukt, Netzwerkknoten und System zur Durchführung des Verfahrens
EP06022477.1 2006-10-27

Publications (1)

Publication Number Publication Date
WO2008049579A1 true WO2008049579A1 (de) 2008-05-02

Family

ID=37814386

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/009183 WO2008049579A1 (de) 2006-10-27 2007-10-23 Verfahren zum erzeugen eines labels, computerprogrammprodukt, netzwerkknoten und system zur durchführung des verfahrens

Country Status (3)

Country Link
US (1) US8477345B2 (de)
EP (2) EP1916627A1 (de)
WO (1) WO2008049579A1 (de)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7937331B2 (en) * 2006-06-23 2011-05-03 United Parcel Service Of America, Inc. Systems and methods for international dutiable returns
US8667394B1 (en) * 2007-06-19 2014-03-04 William C. Spencer System for generating an intelligent cross-platform document
EP2382591A1 (de) * 2008-12-29 2011-11-02 Deutsche Post AG System zum frankieren einer postsendung
US10032239B2 (en) * 2010-06-10 2018-07-24 United Parcel Service Of America, Inc. Enhanced payments for shipping
US20140006128A1 (en) * 2012-06-28 2014-01-02 Bank Of America Corporation Systems and methods for presenting offers during a shopping experience
US8918341B2 (en) * 2013-03-06 2014-12-23 United States Postal Service System and method for international merchandise return service
US20140279426A1 (en) * 2013-03-15 2014-09-18 Elwha Llc Devices, methods, and systems for technologically shifting options and modalities
US20140279425A1 (en) * 2013-03-15 2014-09-18 Elwha Llc Methods, systems, and devices for handling multiple disparate systems
JP5974024B2 (ja) * 2014-01-18 2016-08-23 株式会社モリサワ フォント配信システム、及びフォント配信方法
CA2983745C (en) 2015-05-04 2024-02-20 United States Postal Service System and method for processing items for international distribution
US10621239B2 (en) * 2015-06-08 2020-04-14 Docsolid Llc Managing printed documents in a document processing system
US10931848B2 (en) 2015-06-08 2021-02-23 Docsolid Llc Adding a graphical symbol to a print stream for a document file
US11687868B2 (en) * 2017-10-25 2023-06-27 KlearNow Corporation Delivering international shipped items
US11281850B2 (en) * 2017-12-28 2022-03-22 A9.Com, Inc. System and method for self-filing customs entry forms
CN108763171B (zh) * 2018-04-20 2021-12-07 中国船舶重工集团公司第七一九研究所 一种基于格式模板的文档自动化生成方法
CN111176588B (zh) * 2019-12-11 2023-09-29 中国平安财产保险股份有限公司 业务单据出单方法、装置、介质及电子设备
CN113961956A (zh) * 2021-10-28 2022-01-21 平安科技（深圳）有限公司 标签化网络信息服务生成及应用方法、装置、设备、介质
CN115271889B (zh) * 2022-09-26 2022-11-29 深圳永贵技术有限公司 智能化标签自动联动生成方法、装置、设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001035346A2 (en) * 1999-11-10 2001-05-17 Neopost Inc. System and method of printing labels
WO2005029265A2 (en) * 2003-09-19 2005-03-31 Pitney Bowes, Inc. System and method for preventing duplicate printing in a web browser
DE102004046051A1 (de) * 2004-09-21 2006-03-30 Deutsche Post Ag Verfahren und Vorrichtung zum Frankieren von Postsendungen

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5771289A (en) * 1995-06-06 1998-06-23 Intel Corporation Method and apparatus for transmitting electronic data using attached electronic credits to pay for the transmission
US6671813B2 (en) * 1995-06-07 2003-12-30 Stamps.Com, Inc. Secure on-line PC postage metering system
US20020023057A1 (en) * 1999-06-01 2002-02-21 Goodwin Johnathan David Web-enabled value bearing item printing
US20030074324A1 (en) * 2000-02-11 2003-04-17 Kresina Roman P. Apparatus and method for providing postal services
DE10020402C2 (de) * 2000-04-27 2002-03-14 Deutsche Post Ag Verfahren zum Versehen von Postsendungen mit Freimachungsvermerken
WO2002003189A1 (en) * 2000-06-30 2002-01-10 Zinio Systems, Inc. System and method for encrypting, distributing and viewing electronic documents
US7103578B2 (en) * 2001-05-25 2006-09-05 Roche Diagnostics Operations, Inc. Remote medical device access
US20020182578A1 (en) * 2001-06-01 2002-12-05 Rachman Bruce A. Online course support method and system
US20030172354A1 (en) * 2002-03-08 2003-09-11 Rafael Antonio Martinez Ponce Administration of customized document production system and method
US7319989B2 (en) * 2003-03-04 2008-01-15 Pitney Bowes Inc. Method and system for protection against replay of an indicium message in a closed system meter
US20050138469A1 (en) * 2003-09-19 2005-06-23 Pitney Bowes Inc. Fraud detection in a postage system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001035346A2 (en) * 1999-11-10 2001-05-17 Neopost Inc. System and method of printing labels
WO2005029265A2 (en) * 2003-09-19 2005-03-31 Pitney Bowes, Inc. System and method for preventing duplicate printing in a web browser
DE102004046051A1 (de) * 2004-09-21 2006-03-30 Deutsche Post Ag Verfahren und Vorrichtung zum Frankieren von Postsendungen

Also Published As

Publication number Publication date
US8477345B2 (en) 2013-07-02
EP2800065B1 (de) 2017-05-10
EP1916627A1 (de) 2008-04-30
US20100067041A1 (en) 2010-03-18
EP2800065A1 (de) 2014-11-05

Similar Documents

Publication Publication Date Title
EP2800065B1 (de) Verfahren zum Erzeugen eines Labels, Computerprogrammprodukt und System zur Durchführung des Verfahrens
DE60015178T2 (de) System und verfahren zum verwalten von mehreren postalischen funktionen in einem einzigen konto
DE60018217T2 (de) Techniken zur ausgabe von postwertzeichen über ein netzwerk
EP1916620A1 (de) Verfahren zum Erzeugen eines Labels sowie Vorrichtung zur Durchführung des Verfahrens
US7941744B2 (en) System and method for electronic document generation and delivery
DE60005335T2 (de) Systeme und verfahren zum internetgesteuerten pakettransport
US7149726B1 (en) Online value bearing item printing
US7395225B2 (en) Custom-made product sales system and method
EP1916628B1 (de) Verfahren zum Erzeugen eines intelligenten Dokuments und Vorrichtung zur Durchführung des Verfahrens
US20080086369A1 (en) Method and apparatus for message campaigns
US20040088271A1 (en) Media type identification
DE10131254A1 (de) Verfahren zum Überprüfen der Gültigkeit von digitalen Freimachungsvermerken
WO2009007100A1 (de) Verfahren, vorrichtung und logistiksystem zum befördern einer postsendung
EP2595104B1 (de) Elektronisches Transaktionsverfahren
WO2007042136A1 (de) Warenauslieferungssystem, verfahren zur auslieferung von waren, versandkomponente und ausgabestelle für waren
DE10324539A1 (de) Verfahren und System zur Beauftragung und Durchführung von Druckdienstleistungen und postalischen Leistungen
DE60002546T2 (de) System und verfahren zur automatischen feststellung der medienart im papierfach eines druckers
DE102004046051A1 (de) Verfahren und Vorrichtung zum Frankieren von Postsendungen
WO2002039390A1 (de) Verfahren zum versehen von postsendungen mit frankierungsvermerken
JP2020017140A (ja) 情報処理装置、プログラム、及び情報処理システム
EP1779333B1 (de) Verfahren und vorrichtungsanordnung zur digitalen freimachung von postsendungen
WO2008125187A1 (de) Verfahren und vorrichtungen zur frankierung einer postsendung mit speicherung der kennungsinformation der postsendung in einer positivliste
WO2000073963A2 (en) Online value bearing item printing
EP1671278A1 (de) Verfahren und vorrichtung zum erstellen einer postsendung
WO2008040471A1 (de) Anwendungsarchitektur zum bereitstellen von diensten auf internetmarktplätzen

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07819244

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 12447264

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 07819244

Country of ref document: EP

Kind code of ref document: A1