WO2002092351A2

WO2002092351A2 - Method and system for providing stamps by kiosk

Info

Publication number: WO2002092351A2
Application number: PCT/US2002/015080
Authority: WO
Inventors: James D.L. Martin; J.P. Leon; L. Carlton Brown, Jr.
Original assignee: Neopost Inc.
Priority date: 2001-05-11
Filing date: 2002-05-10
Publication date: 2002-11-21
Also published as: CA2446524A1; WO2002092351A3; EP1390206A2

Abstract

Techniques for dispensing postage from a kiosk (104) using a communications network (108). A method for obtaining a postage stamp at a kiosk (104), where the kiosk (104) includes a computer system (300) and a printer (310), includes a user inputting a request for the postage stamp into the kiosk (104). The request is sent to a server (102) via a communications network (108). The kiosk then receives a markup language response back from the server (102), and processes the markup language response to obtain an indicium. The printer (31) prints the indicium on a label (400), where the label (400) includes one or more security features, thereby providing the postage stamp.

Description

METHOD AND SYSTEM FOR PROVIDING STAMPS BY KIOSK

CROSS-REFERENCES TO RELATED APPLICATIONS

This application claims priority from and incorporates by reference in their entirety the following U.S. Patent Applications:

U.S. Patent Application No. 10/109,539, filed March 26, 2002, titled "Techniques for Dispensing Postage Using a Communications Network," by J.P. Leon; U.S. Patent Application No. 09/902,480, filed July 9, 2001, titled "Method and

System for Providing Stamps by Kiosk," by James D.L. Martin et al.; and

U.S. Provisional Patent Application No. 60/290,563, filed May 11, 2001, titled "A Method and System for Providing Stamps by Kiosk," by J.P. Leon et. al.

BACKGROUND OF THE INVENTION

The present invention relates generally to postage dispensing systems, and more particularly to techniques for dispensing postage from a kiosk using a communication network.

Traditionally, consumers could purchase postage or stamps only from special locations designated by a postal authority. For example, in the U.S., consumers could buy postage only from post offices or other centers specifically authorized by the United States Postal Service (USPS) to sell postage. A disadvantage of this traditional postage buying method is that a consumer has to spend the time and make the effort to physically travel to the post office to buy postage. In order to alleviate the inconveniences associated with traditional techniques described above, postal authorities such as the USPS, now allow postage to be printed by electromechanical postage meters which can be placed at the consumers' or users' premises. Such postage meters can be leased, rented, or purchased where allowed, from the postal authority or from vendors, such as Neopost Inc., have been authorized by the postal authority to sell the meters. Typically, the user purchases a fixed amount of postage value beforehand and the meter is programmed with this amount. Subsequently, the user is allowed to print postage up to the programmed amount. The meter typically includes a print mechanism and mechanical arrangements and/or electronic control circuitry that direct the operation of the print mechanism.

Because the meter is capable of printing postage having a value, the postal authority generally mandates that, in order to maintain security of the postal funds, the postage meters be acquired and used/handled according to strict, complex, and often bureaucratic regulations imposed by the postal authority. For example, a special meter agreement has to be signed between the meter vendor and the user before the meter can be rented or leased by the user. The user also has to secure a postal license number from a postal authority and the meter has to be seeded with the postal license number. A postal license number is usually associated with a geographical address of a user and is used by the postal authority to track the location of the postage meter and its user. A user using postage meters at multiple geographical addresses has to secure multiple postal licenses, one for each address. Additionally, before a new meter is put into service, the meter has to be inspected and sealed by postal authority personnel. Once in service, each meter has to be periodically inspected by postal authority representatives. Further, postal regulations mandate that the postage meter itself incorporate a variety of security features thereby increasing the costs associated with acquiring and using the meter. As a result, renting or leasing, and subsequently using a postal meter can often be expensive, inconvenient, and involve many bureaucratic hurdles. Consequently, it is quite impractical for individual users to use postage meters.

With a view towards alleviating some of the above-mentioned problems and making use of advances in electronics and communications, the United States Postal Service (USPS) has promulgated specifications for its Information Based Indicia Program (IBIP). The IBIP program supports new methods of applying postage in lieu of conventional approaches that typically rely on the use of a postage meter mechanically printing the indicium on mail pieces.

The IBIP program contemplates postal indicia printed by conventional printers (e.g., thermal, inkjet, or laser) and including human-readable and machine-readable portions. An indicium refers to the imprinted designation or a postage mark used on mail pieces denoting evidence of postage payment. The machine-readable portion was initially specified to be a two-dimensional barcode symbology known as PDF417. The indicium content is specified to include a digital signature for security reasons (to preclude forgery). There are separate specifications for open and closed systems. An open system is defined as a general purpose computer used for printing information-based indicia, but not dedicated to the printing of those indicia. A closed system is defined as a system whose basic components are dedicated to the production of information-based indicia and related functions, that is, a device dedicated to creating indicia similar to an existing, traditional postage meter. A closed system may be a proprietary device used alone or in conjunction with other closely related, specialized equipment, and includes the indicium print mechanism.

The IBIP program specifies a postal security device (PSD) that manages the secure postage registers and performs the cryptographic operations of creating and verifying digital signatures. The open system specification describes a host system (a computer or postage meter) connected to an unsecured printer (e.g., a laser printer or the like) and a PSD. The host system also provides communication facilities that allow the PSD's vendor and/or the USPS to establish communications with the PSD. Communications supported include troubleshooting, accounting transactions, and the like. The PSD and host cooperate to provide an indicium, which is then transmitted to and printed by the unsecured printer. The specified indicium allows the use of an unsecured printer (e.g., thermal, inkjet, or laser) by using a digital signature, which also supports authentication of the mail piece. The indicium includes human-readable information and machine-readable information (initially specified as a PDF417 two-dimensional bar code). Each PSD is a unique security device, having core security functions such as digital signature generation and verification and secure management of information (e.g., descending and ascending registers).

BRIEF SUMMARY OF THE INVENTION The present invention provides a method, system, and code to obtain postage stamps from an electronic kiosk over a communications network. An embodiment of the present invention provides a method for obtaining a postage stamp at a kiosk, where the kiosk includes a computer system and a printer. According to the method, a user inputs a request for the postage stamp and payment information into the kiosk. The request and the payment information are sent to a server via a communications network, and the kiosk receives a markup language response back from the server. The markup language response is processed to obtain an indicium, which may include a digital signature, and the printer prints the indicium on a label to produce the postage stamp. The label may include security features. The markup language may be, for example, one or more of the following: the eXentsible Markup Language (XML), the Hypertext Markup Language (HTML) or the Standard Generalized Markup Language (SGML).

The above method may further include the server receiving a markup language request including the request and the payment information, the server processing the markup language request to obtain the request and the payment information, the server validating the payment information and upon validation, and the server generating the indicium based on the request.

Another embodiment of the present invention provides an electronic kiosk for a user obtaining a postage stamp from a central server via a communications network. The electronic lciosk includes a housing, on or in which are disposed: user interface elements for receiving a user request for a stamp; a processor operating on software stored in a memory; a printer coupled to the processor; and network interface circuitry (NIC) connecting the processor to the communications network. The software includes an XML processor for reading an XML document including an indicium, the NIC receives the XML document, and the printer prints the stamp using the indicium.

An alternative embodiment of the present invention provides a method for obtaining a postage stamp at a kiosk where the kiosk includes a processor, a magnetic card reader, a touch screen display, and a printer. In this method, the kiosk receives a request for the postage stamp via the touch screen display and receives payment information from the magnetic card reader. The kiosk then forms an XML request including the request and the payment information, and the XML request is sent to a server via a communications network. The server validates the XML request using a request DTD and obtains the request and the payment information, then validates the payment information, and upon validation, generates an indicium based on the request. The indicium typically includes a digital signature or other unique identifier. The server forms an XML response including the indicium, and sends it to the kiosk. The kiosk validates the XML response using a response DTD and obtains the indicium and the printer prints the indicium on a label, where the label includes security features. Optionally, when the printer is printing the indicium on the label, a portion of a video clip is shown on the touch screen display. In some implementations, the indicia do not include any cryptographic identifiers such as a digital signature. Rather, security can be provided by ensuring that each indicium is unique, and storing the indicium information in a database, typically at the server. Verification occurs by accessing the database and comparing the relevant indicium elements with the database counterparts to make sure the indicium was validly issued. A further understanding of the nature and advantages of the present invention may be realized by reference to the remaining portions of the specification and the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a simplified block diagram of a distributed computer network which may incorporate an embodiment of the present invention;

Fig. 2 a simplified block diagram of a ldosk of an embodiment of the present invention;

Fig. 3 is a simplified block diagram showing additional details of an exemplary computer system of a kiosk according to an embodiment of the present invention; Fig. 4 shows an example of four printed stamps on a label sheet of an embodiment of the present invention;

Fig. 5 shows an example of icons and images on a touch screen of an embodiment of the present invention; Fig. 6 is a flowchart of an initialization routine for the kiosk of an embodiment of the present invention;

Fig. 7 shows a display window on a kiosk flat panel display for purchasing stamps in one embodiment of the present invention;

Fig. 8 shows a display window of a kiosk for selecting different amounts of postage to purchase;

Fig. 9 shows a display window having a moving hand swiping a credit card through a credit card slot in a ldosk;

Fig. 10 is a flow chart showing the process of a user obtaining a stamp from a kiosk of one embodiment of the present invention; Fig. 11 shows a window for purchase same stamps from a kiosk of a second embodiment of the present invention;

Fig. 12 shows a window having an area for showing a video clip while of the stamps are being printed;

Fig. 13 is a flow chart showing a user obtaining stamps for a second embodiment of the present invention;

Fig. 14 is a simplified high-level flowchart showing processing performed by ldosk and PVS for dispensing postage according to an embodiment of the present invention;

Fig. 15 depicts an expanded block diagram of PVS according to an embodiment of the present invention; Fig. 16 is a simplified flow chart showing the processing by the PVS of an indicium request; and

Fig. 17 is a flowchart expanding on the check request validity of Fig. 16 of an embodiment of the present invention.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS

Kiosk Overview

Fig. 1 is a simplified block diagram of a distributed computer network 100 that may incorporate an embodiment of the present invention. Computer network 100 includes one or more kiosk systems 104-1 and 104-2 (herein a kiosk system is referred to either as a "kiosk system" or just as a "kiosk"), at least one postage vendor system (PVS) 102, and a postal authority system (PAS) 106 coupled to a communications network 108 via a plurality of communication links 110. One or more other user systems 104' may also be deployed. Communications network 108 provides a mechanism for allowing the various components of distributed network 100 to communicate and exchange information with each other.

Communications network 108 may itself comprise many interconnected computer systems and communication links. Communication links may be hardwire links, optical links, satellite or other wireless communication links, wave propagation links, or any other mechanisms for communication of information. While in one embodiment communications network 108 is the Internet, in other embodiments, communications network 108 may be any suitable computer network. Distributed computer network 100 depicted in Fig. 1 is merely illustrative of an embodiment incorporating the present invention and does not limit the scope of the invention as recited in the claims. One skilled in the art would recognize other variations, modifications, and alternatives. For example, more than one PVS 102 may be coupled to communications network 108.

Kiosks 104 allow users of the present invention, for example, postage consumers, to interact with and buy postage from PVS 102. Various different types of interactions with PVS 102 are facilitated by kiosks 104. For example, users may use kiosks 104 to configure requests to purchase postage from PVS 102. These user purchase requests are then communicated from kiosks 104 to PVS 102 via communications network 108. In response to the user requests, kiosk 104 may receive information for printing indicia (or a single indicium) from PVS 102. A user may then use kiosk 104 to print the indicia using a printer device, where the printer device is part of the kiosk 104. The indicia may be printed on labels, on paper, on the mail pieces themselves, or on other like media. The labels may have one or more security features, which may include one or more of a serial number unique to the label or a sheet of such labels, serrated edges, a microprint stripe, a color fiber, taggants, a watermark, a hologram, color fibers, or a fluorescent stripe. In alternative embodiments of the present invention, a user using kiosk 104 may store the information for printing indicia received from PVS 102 on a storage medium, such as a computer disk, for subsequent printing of the indicia.

Users may also use kiosks 104 to perform other activities such as browse web- pages stored by PVS 102, register as users of services provided by PVS 102, provide financial and 'credit information for consummating commercial transactions with PVS 102, review status of user accounts maintained by PVS 102, review postage purchase history, access help or customer services provided by PVS 102, and to perform other like activities. Accordingly, in a client-server environment, kiosk 104 typically operates as a client requesting information from PVS 102, which operates as a server that performs processing in response to the client request and provides the requested information to the client systems. It should be however apparent that a particular kiosk 104 may act both as a client and a server depending on whether the kiosk is requesting or providing information. In an alternative embodiment, ldosk 104 may be operated as a stand-alone device, which is connected to a communications network at a different time and optionally, a different location, to exchange information with the PVS 102.

According to the aspects of the present invention, PVS 102 is responsible for dispensing postage in response to postage purchase requests received from kiosks 104. As shown in Fig. 1, PVS 102 may itself comprise multiple interconnected computer and server systems 114 and communication links, as will be described below. PVS 102 may be configured to receive postage requests from kiosks 104, validate the postage requests, generate information for printing indicia in response to the postage requests, perform security functions related to the postage transactions, manage funds related to the postage transactions, communicate the information for printing the indicia to the requesting kiosks 104, maintain and manage user accounts, and several other functions. These functions are generally performed by software code modules executed by PVS 102. However, it should be apparent that these functions may be also performed by software modules or hardware modules of PVS 102, or combinations thereof.

According to an embodiment of the present invention, the information for printing indicia generated by PVS 102 is generally along the lines specified by the IBIP specifications published by the United States Postal Service (USPS). According to aspects of the present invention, the security-critical functions performed by PVS 102 as part of generating the information for printing the indicia comply with the security-critical functions performed by the Postal Security Device (PSD) described in the IBIP specifications. PVS 102 may also be configured to perform functions performed by the Host System described in the IBIP specifications.

Referring back to Fig. 1, postal authority system (PAS) 106 may comprise one or more computer systems managed by a postal authority authorized to regulate and control postal matters. Examples of postal authorities include the United States Postal Service (USPS), France's La Poste, the United Kingdom's Royal Mail, and others. In most instances, the postal authority is a governmental or quasi-governmental agency authorized to oversee postal matters. PAS 106 may be coupled to PVS 102 via communications network 108 or directly via some other communication link 110. The information exchanged between PVS 102 and PAS 106 may include finance information, information required by the postal authority for audit purposes, status information, security information, and other like information. The information required by the postal authority for audit purposes may include information identifying the postage buyers, the postage value and amount purchased by the buyers, and other information. PVS 102 may be configured to download information to PAS 106 on a periodic basis using batch processing, or upon the occurrence of certain events. PVS 102 may also be configured to purchase postage from PAS 106.

In one preferred embodiment, a kiosk 104 is a single housing that includes a computer, a display, an input device, and a printer. The computer includes a processor, memory, and a network connection. The network connection is for connection to a PVS 102 via a communications network, for example, the Internet. The display and input device are combined in a touch screen flat panel display. In an alternative embodiment the display may be a LCD or CRT display with a separate keypad included as part of the single housing. While the kiosk may have multiple printers (including, for example, a receipt printer), there is at least one printer dedicated to printing postage stamps on labels having security fe.atures. The kiosk is typically located in a place readily accessible to the public, for example, a store, supermarket, gas station, restaurant, a post office, on the side of a building, a bank, government building, airport, bus station, subway station, train station, apartment complex, resort, hotel, motel, and so forth. The kiosk neither accepts nor dispenses cash, but uses an electronic form of payment using, for example, a credit card, club card, ATM card, or smart card. And while one of the primary purposes of the kiosk of the preferred embodiment is to dispense postage stamps, other uses, such as electronic commerce, sending/reading email, banking, buying tickets, paying bills, searching the Internet, video teleconferencing, viewing advertisements, movie clips, or just browsing the Web, may be done by the user. Fig. 2 a simplified block diagram of a kiosk 104 of an embodiment of the present invention. The kiosk components are preferably located within one secure housing with, for example, a lock 126. Kiosk 104 includes a touch screen 122, a card reader slot 124, a computer system 300 located in an area 200, a printer outlet 210-1 and a second optional second printer outlet 210-2. The labels or, for example, any printed item with an associated monetary value, such as a ticket, are sent by printer(s) 210 in Fig. 3 through printer outlets 210-1 and 210-2. Card reader slot 124 is to read , for example, a credit card, smart card, bank card, or ATM card. Kiosk 104 is connected to the communications network 108.

Fig. 3 is a simplified block diagram showing additional details of an exemplary computer system 300 of kiosk 104 according to an embodiment of the present invention. Computer system 300 typically includes at least one processor 304, which communicates with a number of internal devices via a bus subsystem 302. These internal devices typically include a storage subsystem 312, comprising a memory subsystem 314 and a file storage subsystem 320, and a network interface subsystem 306. Computer system 300 is connected to several peripheral devices, for example, one or more printers 310 located behind printer slot(s) 210, a card reader 311 coupled to card reader slot 124, and touch screen 122. The input and output devices allow user interaction with computer system 300. A network interface subsystem 306 provides an interface to outside networks, including an interface to communications network 108, for example, the Internet. The network interface circuitry may be disposed on a separate card or may share a circuit board with other systems components. Storage subsystem 312 stores the basic programming and data constructs that provide the functionality of the kiosk. These software modules are generally executed by processor(s) 304. Storage subsystem 312 may optionally provide a repository for storing the various databases that maintain information regarding kiosk transactions. Storage subsystem 312 typically comprises a memory subsystem 314 and a file storage subsystem 320. Memory subsystem 314 typically includes a number of memories including a main random access memory (RAM) 318 for storage of instructions and data during program execution and a read only memory (ROM) 316 in which fixed instructions are stored. File storage subsystem 320 provides persistent (non-volatile) storage for program and data files, and may include a hard disk drive, a floppy disk drive along with associated removable media, a Compact Digital Read Only Memory (CD-ROM) drive, an optical drive, removable media cartridges, and other like storage media. One or more of the drives may be located at remote locations on other connected computers at another site on communications network 108. Information stored according to aspects of the present invention may also be stored by file storage subsystem 320.

Bus subsystem 302 provides a mechanism for letting the various components and subsystems of computer system 300 communicate with each other as intended. The various subsystems and components of computer system 300 need not be at the same physical location but may be distributed at various locations within distributed communications network 108. Although the bus subsystem 302 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple busses.

Fig. 4 shows an example of four printed stamps on a label sheet 400 of an embodiment of the present invention. Label sheet 400 shows stamps 402, 404, 406, and 420, where stamp 420 has been removed from location 406. Stamp 420 includes a microprint strip 410, a fluorescent strip 412 having serrated edges, a logo 414, e.g., the U.S. Post Office Eagle, the postage amount "$0.34" 424, the meter serial No., "046N0009219" 426, the text "U. S. POSTAGE" 428, a data matrix 432, which may include a digital signature, and a company Web address 430, for example, "simplypostage.com". Stamp 420 is printed on a label that initially includes microprint strip 410, the fluorescent strip 412 and logo 414. The same is also holds for the three other labels before a stamp is printed on them in label sheet 400 above. The label sheet is stored in the kiosk area 200 which has printer 310 coupled with printer slot 210-1. The label sheet has initially four preprinted labels, each with microprint 410, fluorescence strip 412, and logo 414. As seen below in Fig. 14, after the XML request for postage is sent from the kiosk to the PVS and the PVS sends an XML response having the four indicia, the printer 210 prints the four stamps on the label sheet 400 and outputs the printed stamps to the user via printer slot 210-1.

Kiosk Use and Interactions

Fig. 5 shows an example of icons and images on touch screen 122 of an embodiment of the present invention. Touch screen 122 shows three icons 510, 512, and a kiosk stamp icon 514. Kiosk stamp icon 514, when selected, expands to show a browser window 516 filing the entire touch screen 122-2. In alternative embodiments when kiosk stamp icon 514 is selected the browser window 516 fills only a part of the whole touch screen. The browser window 516 may show, for example, window 710 in Fig. 7, window 720 in Fig. 8, window 740 in Fig. 9, window 810 in Fig. 11, and window 830 in Fig. 12.

Fig. 6 is a flowchart of an initialization routine for the kiosk 104 of an embodiment of the present invention. At a step 610 the Internet browser is started. For example kiosk stamp icon 514 is selected and expanded either automatically or manually as in Fig. 5. At a step 612 the browser loads the kiosk web pages from the web server at the PVS 102. At a step 614 the kiosk processor 304 gets the kiosk ID from the Windows Registry stored in the storage subsystem 312. The kiosk then verifies this kiosk ID with the PVS 102. If the verification fails then the kiosk reports an error (step 622). If the kiosk ID is verified, the kiosk is ready to process a request for stamps (step 624). In another embodiment the Media Access Control (MAC) address of the kiosk's network interface circuitry (NIC) 306 is used as the kiosk ID, and the PVS maintains a listing of the valid NIC MAC addresses.

Fig. 7 shows a display window 710 on a kiosk display for purchasing stamps in one embodiment of the present invention. The display window 710 includes an image of a ldosk 712.

Fig. 8 shows a display window 720 of a kiosk for selecting different amounts of postage to purchase. There are five selections shown, where each selection has a different number of stamps. There are four stamps 722, 8 stamps 724, 12 stamps 726, 16 stamps 728, and 20 stamps 730, that a user may select for purchase. Fig. 9 shows a display window 740 having a moving hand 745 swiping a credit card 746 through a credit card slot 747 in a kiosk 748. The movement of the hand is accomplished via MPEG images or a video clip.

Fig. 10 is a flowchart showing the process of a user obtaining a stamp from a kiosk of one embodiment of the present invention. At a step 760 the user selects the kiosk stamp icon 514 on touch screen 122. The Internet browser opens showing the kiosk stamp information, for example display window 710 of the Fig. 7, on the entire touch screen (step 762). At a step 764 the user makes a postage purchase selection by selecting one of the five numbers of stamps 722, 724, 726, 728 or 730 in window 720 of Fig. 8. At a step 766 the user swipes a credit card through the card reader slot 124. While the postage is being printed, the user may watch a still or a moving picture (step 768). At step a 770 the user takes the stamps, for example, the printed label sheet 400 in Fig. 4, from the printer slot 210-1.

Fig. 11 shows display window 810 for purchase same stamps from a kiosk of a second embodiment of the present invention. Display window 810 includes an image of a receipt 812 which has a five digit stamp code 814 located at the bottom of receipt 812, an input area 816 to enter the five-digit code, and an image of a keypad, for example, numeric keys 818-1, 818-2, 818-6, 818-8, and enter key 820. In one embodiment enter key 820 is not visible until the five digits have been entered in input area 816. At that time, pressing enter key 820 causes validation of the five-digit stamp code. In other embodiments, there may be more or fewer than five digits, and/or the enter key may always be visible.

Fig. 12 illustrates a display window 830 having an area 832 for showing a video clip or MPEG images or streaming video or graphic images or animation, while the stamps are being printed. This allows the user to be informed or entertained while waiting for the kiosk to process and print the selected stamps. Fig. 13 is a flow chart showing a user obtaining stamps in a second embodiment of the present invention. At a step 850 the user pays for the stamps at the store cash register. The user then activates the Internet browser on the kiosk touch screen at a step 852. At a step 854 the user either enters the stamp code on the receipt using, for example, field 816 in Fig. 11 or the user scans the bar code (not shown). At step 856 while the postage is being printed, the user watches a video clip with optional audio as shown in Fig. 12. At a step 858 the user takes the stamps from the printer slot 210-1.

Fig. 14 is a simplified high-level flowchart 900 showing processing performed by kiosk 104 and PVS 102 for dispensing postage according to an embodiment of the present invention. As shown in Fig. 14, processing is generally initiated when a user accesses a web page provided by PVS 102 using kiosk 104 (step 902). As described above, the user may access the web pages by providing URL information corresponding to the web pages to a browser executing on kiosk 104. Using the web page(s), the user may then configure a request to buy postage from PVS 102 (step 904). For example, the user may request purchase of one or more $0.34 stamps. The user request to purchase postage may include information identifying the user, credit-card, ATM, bank account, club card, smart card, or other like information which will be used by PVS 102 to bill for the purchased postage, the amount and value/denomination of the postage which the user wishes to purchase, and other like information which may be used by PVS 102 to process the request. In an alternative embodiment the user may pay for the stamps at a checkout counter in a store and get a code number to be entered into the kiosk's touch screen. A user may request purchase of one or more stamps.

Kiosk 104 then communicates the user's request to purchase postage to PVS 102 via communications network 108 (step 906). According to an embodiment, a secure socket layer (SSL) connection may be established between kiosk 104 and PVS 102 to facilitate communication of information between user system 104 and PVS 102. The postage request is sent using the eXenstible Markup Language (XML). In an alternative embodiment the Standard Generalized Marlcup Language (SGML) may be used instead of XML. SGML is a language for describing languages, i.e., a meta-language. XML is a subset of SGML. In another embodiment HTML is used. Yet another embodiment uses a marlcup language in which the logical structure has customizable constraints. Other embodiments use a combination of one or more of HTML, SGML, or XML.

Each XML document has both a logical and a physical structure. Physically, the document is composed of storage units called entities. An entity may be nested in another entity. Logically, the document includes declarations, elements, comments, character references, and processing instructions, all of which are indicated in the document by explicit marlcup. XML provides a mechanism, the document type declaration (DTD) , to define constraints on the logical structure and to support the use of entities. The DTD contains or points to markup declarations, i.e., element type declarations, that provide a grammar for a class of documents. A software module called an XML processor is used to read "XML documents and provide access to their content and structure.

PVS 102 then receives the user request to purchase postage from ldosk 104 (step 908). PVS 102 may then validate the user request (step 910). For example, PVS 102 may determine if the credit-card information provided by the user is valid. PVS 102 may use services provided by companies such as Cybercash and Cybersource to perform the credit- card information validation. If the request is from a registered user who has a pre-funded account, PVS 102 may determine if the user has sufficient funds in the user's account maintained by PVS 102 to satisfy the postage request. Alternatively, PVS 102 may determine if the credit-card information for the registered user is stored by PVS 102 or provided to PVS 102 by the user request. PVS 102 may also validate other information such as the identity of the user requesting the purchase, the type of postage requested by the user, and the like. If the validation process fails for any reason (step 912), the user's request may be terminated and a message may be communicated to the requesting kiosk 104 indicating that validation of the user request was not successful (step 914). A reason why the validation failed may also be provided.

If validation is successful, PVS 102 then generates information for printing an indicium for each stamp requested in the user postage request (step 916). According to an embodiment of the present invention, the information for printing the indicium generated by PVS 102 is along the lines specified in the IBIP specifications published by the USPS. For each indicium, the information for printing the indicium may include a bitmap of the indicium, a graphical image of the indicium, data representing the indicium, raw data corresponding to the indicium, or other information which facilitates printing of the indicium. The information for printing the indicium in a markup language format, e.g., an XML format, is then communicated from PVS 102 to the requesting the kiosk via communications network 108 (step 918). In an alternative embodiment SGML may be used instead of XML. In another embodiment HTML is used. Yet another embodiment uses a marlcup language format in which the logical structure has customizable constraints. Other embodiments use a combination of one or more of HTML, SGML, or XML. The requesting kiosk 104 then receives the information for printing the indicium (or indicia) from PVS 102 (step 920). The information received in step 920 may then be used to print the indicium (step 924). A printer device as part of the kiosk is used to print the indicium (or indicia). According to an embodiment of the present invention, user system 104 may process the information received from PVS 102 before printing the indicium according to step 924. The indicium may be printed on any suitable medium such as a label, paper, sheet of labels, envelopes, cards, directly on the mail piece/package, or other like media. One or more indicia may be printed at a time. In alternative embodiments of the present invention, the user may store the information for printing the indicia on a storage medium, such as a memory disk, for subsequent printing. In order to reduce fraudulent imprinting of the indicium, the medium on which the indicium is printed may be configured to possess special features which provide enhanced security against fraudulent misuse. For example, the indicium may be printed on labels which may contain any or all of a variety of security features, such as bar-coding, micro- printing, watermarking, use of fluorescent strips, serrated edges, taggants, and the like. The indicium or indicia may then be printed on one or more labels which may then be affixed onto the mail piece/package (just like an ordinary stamp purchased from the post office).

For an embodiment of the present invention, the program used in printing the indicium (or indicia) according to step 924 may include, for example, OCX, a Java applet, a VBScript, a Java Script, ActiveX controls, a C++ program, a C program, a Java program, etc.

PVS Details

Fig. 15 is an expanded block diagram of PVS 102 according to an embodiment of the present invention. As shown in Fig. 15, PVS 102 may comprise one or more web servers 1002, one or more postal security device module (PSDM) servers 1004 (with associated cryptographic modules 1006), and a database 1008 coupled to a local communications network 1010 via a plurality of communication links 1012. Local communications network 1010 provides a mechanism for allowing the various components of PVS 102 to communicate and exchange information with each other. Local communications network 1010 may itself be comprised of many interconnected computer systems and communication links. Communication links 1012 may be hardwire links, optical links, satellite or other wireless communication links, wave propagation links, or any other mechanisms for communication of information. The configuration of PVS 102 depicted in Fig. 15 is merely illustrative of an embodiment incorporating the present invention and does not limit the scope of the invention as recited in the claims. One skilled in the art would recognize other variations, modifications, and alternatives.

Web server(s) 1002 may host the postage vendor's web site and store web pages provided by the postage vendor. Web server 1002 is responsible for receiving URL requests from user systems 104 and for forwarding web pages corresponding to the URL requests to the requesting user systems 104. As previously stated, these web pages allow a user to interact with PVS 102. e.g. to configure a request to purchase postage from PVS 102. When user system 104 requests communication with PVS 102, the web server may be configured to establish a communication link between kiosk 104 and PVS 102. For example, web server 1002 may establish a secure Internet socket link. e.g. a SSL 2.0 link, between PVS 102 and ldosk 104. The information communicated between user system 104 and PVS 102 may be SSL encrypted using various encryption levels, e.g. 40-bit encryption, 128-bit encryption, and the like. Web server 1002 may also incorporate a firewall which shields the internal PVS network from communications network 108 and kiosks 104 and other resources coupled to communications network 108. According to an embodiment of the present invention, web server 1002 is responsible for receiving requests from kiosks 104 to purchase stamps and for performing load distribution and fail-over processing associated with the requests. Web server 1002 may also be configured to control the downloading of printer control programs from PVS 102 to kiosk 104.

Each PSDM server 1004, in conjunction with one or more cryptographic modules 1006 coupled to the PSDM server, is responsible for generating the indicium or indicia. According to an embodiment of the present invention, functions performed by PSDM server 1004 include functions performed by a postal security device (PSD) as described in the IBIP specifications published by the USPS. For example, functions performed by PSDM server 1004 include initialization and creation of PSD resources, digital signature generation, management of funds related to the postage dispensed by PVS 102, generation of information for printing the indicia, key handling, and other functions. PSDM servers 1004 are designed to operate in a clustered environment to allow for expandability to meet the needs of a rapidly growing user base. According to an embodiment of the present invention, PSDM server 1004 communicates with web server 1002 using a DCOM (Microsoft's Distributed Component Object Model) interface.

Each PSDM server 1004 may comprise one or more cryptographic modules 1006 for performing cryptographic functions and for generating digital signatures. Various keys for performing security-critical functions such as digital signature generation, hashing, encryption, etc. are stored by cryptographic module 1006. According to an embodiment of the present invention, cryptographic module 1006 is an nCipher nFast/CA module which is validated to FIPS 140-1 Level 3 security.

According to aspects of the present invention, PSDM server 1004 uses PSD resources to generate information for printing indicia and to track monetary amounts related to the postage dispensed by PVS 102. In order to increase the indicia generation throughput, a plurality of shared PSD resources may be used by PSDM servers 1004 to generate the indicia. By using a plurality of PSD resources, multiple PSDM servers 1004 can run concurrently, producing indicia in parallel without the bottleneck of sharing a single PSD resource. According to an embodiment of the present invention, each PSD resource comprises a unique PSD identifier (e.g. a 4-byte identifier), a descending register (DR) value (e.g. a four-byte value), an ascending register (AR) value (e.g. a five-byte value), and a control code (e.g. a 20-byte value). The PSD identifier uniquely identifies each PSD resource. The ascending register (AR) value represents the total monetary value of all indicia ever produced by the PSD during its life cycle. The descending register (DR) value indicates the available funds assigned to the PSD resource which may be used to dispense postage. According to an embodiment of the present invention, the monetary values stored by the AR and DR values are measured in 1/10 of 1-cent increments as specified in the IBIP specifications. The control code is a secure hash of the PSD identifier, the PSD AR value, and the PSD DR value. According to an embodiment of the present invention, the control code is generated using HMAC-with-SHAl (RFC 2104) using a secret HMAC key stored by cryptographic module 1006.

In a specific embodiment of PVS 102, monetary amounts related to the postage dispensed by PVS 102 are tracked using a global PSD (GPSD) resource and a pool of PSD resources referred to as mini-PSDs (or MPSDs) stored by PVS 102. According to an embodiment, eight MPSD resources may be used by a single cryptographic module 1006 associated with PSDM server 1004 to concurrently generate information for printing indicia. The sum of the AR value and the DR value of the GPSD resource represents the total amount of postage bought from the postal authority, for example, from the USPS, by the postage vendor provider (e.g. Neopost Inc.) of PVS 102. The sum totals of the AR and DR values of the MPSD resources matches the AR and DR values of the GPSD resource. Information related to the GPSD resource and MPSD resources may be stored in database 1008.

According to an embodiment of the present invention, each MPSD resource may be assigned a unique number by the postage vendor. A number assigned to a particular MPSD may be included in the information for printing an indicium generated by the particular MPSD and printed as part of the indicium. For example, the number "046N60009219" (reference 426 in Fig. 4) uniquely identifies the MPSD resource which was used for generating the information for printing the indicium depicted in Fig. 4. This MPSD serial number is like a meter number and may be used to track the MPSD resource responsible for generating information for printing the indicium.

Database 1008 acts as a repository for storing information related to the postage dispensing process. For example, database 1008 may store information related to the PSD resources (both GPSD and MPSDs), information used for generation of digital signatures, and other like information. Database 1008 may also store the postal license number assigned to PVS 102 by the postal authority. Other information related to the dispensing of postage may also be stored by database 1008. The term "database" as used in this application may refer to a single database or to a plurality of databases coupled to local communications network 1010. Further, database 1008 may be a relational database, an object-oriented database, a flat file, or any other way of storing information. According to an embodiment, database 1008 is coupled to web server 1002 and to PSDM server 1004 via an ODBC interface.

PVS Request Processing

Fig. 16 is a simplified flow chart showing the processing by PVS 102 of an indicium request. PVS 102 gets a XML request from the kiosk at a step 1110. At a step 1112 the XML request is parsed to make sure that it is a well-formed XML document and it is validated against the Request Document Type Definition (DTD). At a step 1114 the kiosk's credentials are validated. At step 1116 the transaction type is determined. If the transaction type is a "Reget" transaction 1118, then at step 1124 the indicium or indicia of a previous transaction is returned. Then from step 1124, at step 1150 a response is created and at step 1150 the response is returned to the kiosk. If the transaction type is a "Lookup" transaction 1120, then the billing information is retrieved for a previously generated transaction, and the billing type at step 1130 is determined. If the transaction type is a "Standard" transaction 1122, then at step 1130 the billing type is determined. If the billing type is a credit card (CC) method of payment 1132, then at step 1134 the credit card must be authorized. An error results if the CC is not authorized. At step 1136 the PSDM server 1004 is called, and at step 1150 a response message to the kiosk is created. If the billing type is a bill-to-account or an ME, then at step 1142 the ME must be authorized, otherwise an error occurs. At step 1144 the PSDM server 1004 is called, and at step 1150 a response message to the kiosk is created. The response message typically created at step 1150 is a response XML message including one or more indicia. This response XML message is then sent to the kiosk 104 by the PVS 102. The kiosk 104 uses the Response DTD to validate and process this XML response message. One or more indicia are extracted and used to print the stamp(s) on printer 210, for example Fig. 4.

There are several types of XML messages that are passed between the kiosk 104 and the server or PVS 102. First, there must be a request DTD (Document Type Definition) specifying the format and building blocks of the XML request documents from the user or kiosk to the server or PVS. Then there must also be a Response DTD specifying the format of the response from the server or PVS to the user or kiosk. There are three types of XML requests, standard, lookup, and reget, and one type of XML response. While this XML format is described for use with a PVS and a kiosk, it is not so limited. The DTDs and XML requests and responses may be used in other embodiments with any user, for example other user system 104' in Fig. 1, connected to a PVS 102, as described in U.S. Patent Application No. 09/708,883, entitled "Techniques For Dispensing Postage Using A Communication Network," which is herein incorporated by reference.

The XML message includes several types: one for a primary request to the PVS, two for secondary requests to the PVS, and one for a response from the PVS. The request transactions are:

<StandardTransaction> - This is a standard indicia request with Credit Card or bill-to account code (ME). This is the primary method of creating indicia. <LookupTransaction> - This secondary transaction looks for a previously generated transaction and retrieves that transaction's billing information. It then generates more indicia using the same Customer Transaction ID (CTID) as the previous indicia. This is used, for example, when postage is due (e.g. postage was insufficient for package weight and customer is not available to retrieve billing information).

<RegetTransaction> - This secondary transaction gets the indicia or indicium of a previous transaction (specified by CTID or TID). This is useful, for example, if a problem occurred in receiving the original reply, (e.g. paper jam while printing or power loss while receiving transaction). Responses look the same, however; they are successful or unsuccessful, as specified by:

Success:

<Indicia>...</Indicia> or Failure:

<ReturnCode> <Code>a non-zero value</Code>

< ReturnCode>

The following are annotated examples of the three requests and one response. A typical primary request includes a user's credit card information for payment and request one or more groups of four stamps. Here for illustration purposes only, two stamps are requested. The annotations are in brackets: [ ]

Required preamble for properly formatted* XML <?xml vereion=" 1.0" encodings "UTF- 8" standalone="no" ?> <! DOCTYPE request SYSTEM "request.dtd"> <Request>

<CustomerID>USPS</UserID> <Password>USPSPassword</Password> </Customer> <StandardTransaction>

<BillingTypeCC/> [Other types include : <BiIlingTypeME/> which is for billing a pre-established account] <CTID>38974589739879857589372334</CTID> [User or kiosk supplies CTID which uniquely identifies this transaction to that user or kiosk. Examples: may be Waybill # or tracking ID up to 36 alphanumeric digits. CTID is unique and fixed for a preset M days, for example 60 days. The CTID may be, for example, 36 characters long. The reason for the unique 60 day CTID is to prevent re-use of a CTID in the event of a lost transaction or to re-bill a customer for additional postage if customer is no longer available. The CTID is incorporated into the indicium as part of the digital signature for validation. Examples of use of the CTID include, invoice number for purchased postage, batch label ID, waybill number for GXG, tracking number on priority mail, or a GUED.] <CreditCard>

<CleansingLevelLow/> [ the cleansing level sets the expectations on how rigidly a credit card is validated. Other options are CleansingLevelMedium and CleansingLevelHigh. Each of these options modifies the behavior of the PVS's rejection or acceptance of a credit card based on a credit-risk rating.] <CCExpMonth>10</CCExpMonth>

<CCExpYear>2001< CCExpYear> <CCNumber>41111111111111 l</CCNumber> <CCType>Visa</CCType> <FirstName>Phil</FirstName> <LastName>Connors< LastName>

<Phone>800.222.3333</Phone> [optional on low] <Email>none @ mail.com</Email> [optional] <Street>33175 PALMETTO DR </Street> [optional on low ] <City>UNION CITY</City> [optional on low]

<State>CA</State> [optional on low] <Zip>94587</Zip> [optional on low] <Country>USA</Country> [optional on low] </CreditCard> <Indicia id= "1">

<PostageType>GXG</PostageType> [Global express Guaranteed (GXG). In one embodiment, when this option is selected, the CTID is used as an universal tracking number from origin to destination of the mailpiece. For example, a package may start at location A, where the stamps are affixed. It may then go by a commercial carrier, such as FedEx to location B, then by another commercial carrier, such as DHL to location B, and finally by USPS Express mail to location C. The GXG option uses the CTID as one number to track the package through the various carriers.]

<Amount>0.34</Amount> [Up to 999.999. Up to 3 decimal places (e.g. 0.235 for discounted postage). The entire transaction should add-up to a whole penny amount, otherwise the transaction is rejected. For example, if the customer purchases two 23.5 cent stamps, the PVS will return 2 indicia and bill 47 cents.]

<IBIPData/> [optional, IBIP Data is returned formatted to the IBIP specification - base64] <PlainTextData/> [optional, plain text data is the IBIP information in human- readable format.]

</Indicia> <Indicia id= "2">

<Bitmap> [optional, bitmap is a 'type' of indicia in a Datamatrix bitmap format - base64 encoded. <Bitmap> may be replaced by <FormatRLE/>]

<Height>200</Height> [Size of bitmap, in pixels]

An example of a first secondary request transaction (<LookupTransaction> ) requests more indicia from the PVS using billing information from previously created indicia. A Transaction ID (TID) uniquely identifies a single indicium and may be, for example, 26 characters long. The TID or CTID, and stamp amount for a new stamp is sent to the PVS. Then the PVS retrieves previous billing information, generates new stamps, and bills according to the previous billing information. The transaction will be marked with the same CTID as previous transaction. The following is an example of the < LookupTransaction >:

<?xml versions" 1.0" encoding="UTF-8" standalone="no" ?> <! DOCTYPE request SYSTEM "request.dtd"> <Request>

<CustomerID>USPS</UserID> <Password>USPSPassword</Password>

</Customer> <LookupTrans action>

</Indicia> <Indicia id= "2">

</Request>

An example of a second secondary request transaction ( <RegetTransaction> ) returns one or more indicia of a previously generated transaction request. This is useful if you lost the transaction due to a power outage or other corruption in the data stream. Either a CTID or TID is used to return the original indicium or indicia. If a TID is passed, only one indicium is returned. If a CTID is passed, all indicia ever generated for that CTID are returned, (i.e. if the original CTID had 10 stamps, all 10 will be returned. If additional indicia are created (via LookupTransaction), those will be returned also). In one embodiment all indicia are returned uniformly. In a <StandardTransaction> request, indicia can have several indicia in different formats. <RegetTransaction> returns all indicia in one format, (e.g. in this example, all indicia are returned with the same <IBIPData> and <Bitmap>). The following is an example of the <RegetTransaction>:

<?xml versions" 1.0" encoding="UTF-8" standalone="no" ?> < ! DOCTYPE request SYSTEM "request.dtd">

<CustomerID>USPS</UserID> <Password>USPSPassword</Password> </Customer>

There is one type of <Response> which is an XML response by the PVS to the XML request sent by the user or kiosk. The <ReturnCode> indicates whether indicia or an error code is returned to the customer. The <RetumCode> includes the following: <Code> - 0 (zero) - transaction successful. - Anything other than zero, see Response Codes section

<Description> Troubleshooting information. Variable format. <SubCode> Used to pass additional information that may yield / extend troubleshooting ability in future releases.

The first response example is of a success: <?xml versions" 1.0" encoding="UTF-8" standalone="no" ?>

<! DOCTYPE response SYSTEM "Response.dtd"> <Response> <ReturnCode>

<TID>123843843897847897348773</TID> <IBIPData> VOvwP+jzOD/y/wQG2urxewweweIOzWUAaBdddfsdfABVGuvw//sdfffLwLOvwHOr< IBI PData>

</PIainTextData> </Lιdicia> <Indicia id= "2">

<TID>123843843897847897348774</TID> [The Transaction ID (TID) is returned as part of a response within the <indicia>. TJJD uniquely identifies a single indicium and is typically received by the PVS as part of a Reget or Lookup request. When used in REGET and LOOKUP transactions, the TID originally assigned by the PVS is used by the PVS to re-retrieve or bill that transaction.]

<BitmapData> VOvwP+jz0D/y/wQG2urxIOjzWUAaBgAAGQEtADEPAABVGuvw//LwLO vwHOjzoPr0Bw/r8Pbx6vFK5/QEOuvwROvwAQBUMQHo84Dy8UUPVw/y8eD7LQHq8W jq5/QP6/BU6/ACAFSFGOvwPN/8jAGMAeblAa6RAgAAAyoEBevwBqιτ8Afr8Ajr8Anr8A _qq6/AL6/AM6/AN6/AO6uvwk+P4L8ACVQEB+QG6Ad8BAgBiAQDV/gOSARMWAhMW A2JPAAD+hbgE6vGJABP/MHoUrlcfheoSlP7YDQOblvwECOBMQQJECSBYWFTIQIRdr EgNXFq4WEwRiAhUUBYEWBiqBFgeBFgilEYa8BOrxAVUAFLIK7BgNHoIaKxefFCQU Fa4Sh8AE6v </BitmapData> </Indicia> </Response>

The second example is of a failure: <?xml versions" 1.0" encoding="UTF-8" standalone="no" ?>

<! DOCTYPE response SYSTEM "Response.dtd"> <Response> <ReturnCode>

<Code>0310< Code> <Description>Payment failure: CC failure</Description>

<SubCode>Decline due to incorrect CVVrequest_id = 979879879878</SubCode>

</ReturnCode> </Response> Fig. 17 is a flowchart expanding on the check request validity (step 1112) of

Fig. 16 of an embodiment of the present invention. At a step 1212 the XML request received from the user system is parsed to check if it is a well formed XML document. If it is not a well formed XML document, an error code so signifying is returned at a step 1214. If it is a well formed XML document, at a step 1216 the parsed XML document is validated against the request DTD. If it does not validate, an error code signifying that the XML is not valid is returned at a step 1218. If the XML document is valid, the bitmap is then checked to determine if it is correctly specified (step 1220). If the bitmap is incorrectly specified, an error code so signifying is returned at a step 1222. If the bitmap is correctly specified, at a step 1224 the postage type and amount are checked. If the indicium is incorrectly specified, an error code so signifying is returned at a step 1226. If the postage type and amount are correctly specified, at a step 1228 the number of indicia is checked. If too many indicia have been requested, an error code so signifying at a step 1230. If the number of indicia is valid, at a step 1232 the CTID is checked for a duplicate CTID within the 60-day window. If a duplicate CTID is found, an error code so signifying is returned at a step 1232. If there is no duplicate CTID, the request is considered to be a valid request (block 1234).

Conclusion

Although specific embodiments of the invention have been described, various modifications, alterations, alternative constructions, and equivalents are also encompassed within the scope of the invention. The described invention is not restricted to operation within certain specific data processing environments, but is free to operate within a plurality of data processing environments. Additionally, although the present invention has been described using a particular series of transactions and steps, it should be apparent to those skilled in the art that the scope of the present invention is not limited to the described series of transactions and steps. Further, while the present invention has been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of the present invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that additions, subtractions, deletions, and other modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims.

Claims

WHAT IS CLAIMED IS:

1. A method for obtaining a postage stamp at a kiosk, comprising a computer system and a printer, said method comprising: inputting by a user into said ldosk a request for said postage stamp; sending said request to a server via a communications network; receiving from said server a markup language response; processing said markup language response to obtain an indicium; and printing said indicium by said printer on a label to obtain said postage stamp.

2. The method of claim 1 wherein said indicium includes a digital signature.

3. The method of claim 1 wherein said markup language response comprises a . logical structure having customizable constraints.

4. The method of claim 3 wherein said customizable constraints include a Document Type Declaration (DTD).

5. The method of claim 1 further comprising validating said markup language request using a response marlcup language declaration.

6. The method of claim 5 wherein said markup language response declaration is an element type declaration in a Document Type Declaration (DTD).

7. The method of claim 1 wherein said markup language response is an extensible markup language (XML) response.

8. The method of claim 1 wherein said markup language response comprises a statement of a marlcup language selected from a group consisting of HTML, XML, or SGML.

9. The method of claim 1 wherein said markup language response is a Standard Generalized Markup Language (SGML) response.

10 . The method of claim wherein said markup language response includes a transaction identifier (TID).

11. The method of claim 1 wherein when said printer is printing said indicium on a label, displaying a moving image on a display.

12. The method of claim 1 wherein when said printer is printing said indicium on said label, displaying an image on a display.

13. A method for obtaining a postage stamp at a kiosk, comprising a computer system and a printer, said method comprising: inputting by a user into said kiosk a request for said postage stamp and payment information; sending said request and said payment information to a server via a communications network; receiving from said server an XML response; processing said XML response to obtain an indicium; and printing said indicium by said printer on a label to obtain said postage stamp, said label comprising one or more security features.

14. The method of claim 1 wherein said indicium includes a digital signature.

15. The method of claim 13 further comprising: said server receiving an XML request comprising said request and said payment information; processing said XML request to obtain said request and said payment information; validating said payment information; and responsive to said validating, generating said indicium based on said request.

16. The method of claim 15wherein said XML request further includes a GXG postage type.

17. The method of claim 15 wherein said XML request further includes a customer transaction identifier (CTID).

18. An electronic kiosk for a user obtaining a postage stamp from a central server via a communications network, said electronic kiosk comprising: a processor operating on software stored in a memory, said software comprising a markup language processor for reading a markup language document comprising an indicium; a housing having said display, said processor, and said memory; network interface circuitry (NIC) connecting said processor to said communications network, said NIC for receiving said markup language document; and a printer coupled to said memory for printing said stamp using said indicium.

19. The electronic kiosk of claim 18 wherein said markup language document is an XML document.

20. The electronic kiosk of claim 18 further comprising a display showing a browser window for postage stamps.

21. The electronic kiosk of claim 18 wherein said software further comprises a browser module and an ID module that validates a first kiosk ID at the kiosk with a second kiosk ID at said central server.

22. The electronic kiosk of claim 21 wherein said first kiosk ID is stored in a window ' s registry.

23. The electronic kiosk of claim 21 wherein said first kiosk ID is a MAC address of said NIC.

24. A method for obtaining a postage stamp at a kiosk, comprising a processor, a magnetic card reader, a touch screen display, and a printer, said method comprising: receiving a request for said postage stamp via said touch screen display; receiving payment information from said magnetic card reader; forming an XML request comprising said request and said payment information sending said XML request to a server via a communications network; said server validating said XML request using a request DTD; processing said XML request to obtain said request and said payment information; validating said payment information; responsive to said validating, generating an indicium based on said request; said indicium including a digital signature; forming an XML response comprising said indicium; receiving from said server said XML response; validating said XML response using a response DTD ; processing said XML response to obtain said indicium; and printing said indicium by said printer on a label, said label comprising security features.

25. The method of claim 24 wherein when said printer is printing said indicium on said label, displaying a portion of a video clip on said touch screen display.

26. The method of claim 24 wherein when said printer is printing said indicium on said label, displaying an image on said touch screen display.

27. A method of obtaining a postage stamp from a kiosk, said kiosk comprising a processor and a printer, said method comprising: obtaining a sequence of characters upon paying for said postage stamp at a cash register; inputting said sequence of characters into said kiosk; sending an XML request for said postage stamp to a server; receiving an XML response comprising an indicium; and printing said indicium, by said printer on a pre-processed label to obtain said postage stamp.

28. The method of claim 27 wherein said pre-processed label includes one or more security features.

29. A computer program product stored in a computer readable medium for obtaining a postage stamp at a kiosk, said kiosk, comprising a computer system and a printer, said computer program product comprising: code for receiving a request for said postage stamp; code for sending said request to a server via a communications network; code for receiving from said server a markup language response; code for processing said marlcup language response using a markup language response declaration to obtain an indicium representing said postage stamp, said indicium comprising a digital signature; and code for printing said indicium by said printer on a label.

30. The computer program product of claim 29 wherein said marlcup language response is an extensible markup language (XML) response.