WO2001059682A1 - Systeme et procede pour la fourniture de services postaux - Google Patents

Systeme et procede pour la fourniture de services postaux Download PDF

Info

Publication number
WO2001059682A1
WO2001059682A1 PCT/US2001/004480 US0104480W WO0159682A1 WO 2001059682 A1 WO2001059682 A1 WO 2001059682A1 US 0104480 W US0104480 W US 0104480W WO 0159682 A1 WO0159682 A1 WO 0159682A1
Authority
WO
WIPO (PCT)
Prior art keywords
services
postal
remote
service
interface
Prior art date
Application number
PCT/US2001/004480
Other languages
English (en)
Other versions
WO2001059682A9 (fr
Inventor
Roman P. Kresina
Joseph D. Busch
Daniel P. Fearnley
Original Assignee
Ascom Hasler Mailing Systems, Inc.
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 Ascom Hasler Mailing Systems, Inc. filed Critical Ascom Hasler Mailing Systems, Inc.
Priority to AU2001236926A priority Critical patent/AU2001236926A1/en
Publication of WO2001059682A1 publication Critical patent/WO2001059682A1/fr
Publication of WO2001059682A9 publication Critical patent/WO2001059682A9/fr

Links

Classifications

    • 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
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00016—Relations between apparatus, e.g. franking machine at customer or apparatus at post office, in a franking system
    • G07B17/00024—Physical or organizational aspects of franking systems
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/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
    • 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/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/00153—Communication details outside or between apparatus for sending information
    • G07B2017/00161—Communication details outside or between apparatus for sending information from a central, non-user location, e.g. for updating rates or software, or for refilling funds
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B17/00—Franking apparatus
    • G07B17/00733—Cryptography or similar special procedures in a franking system
    • G07B2017/00846—Key management

Definitions

  • the present invention relates to apparatus and methods useful for providing postage metering services . More particularly, it relates to a system and method wherein a remote user can have access to a central infrastructure to take advantage of the services provided by that infrastructure.
  • the United States Postal Service has proposed an Information-Based Indicia Program (IBIP) to allow postage indicia to be printed in so called open systems by using, for example, a personal computer, and printer, or a small office mailing system. While this approach has a great deal of appeal in that relatively simple and low cost equipment can be used at a customer site, it would be even more advantageous if a broad range of services could be made available to the users of such equipment. For example, services such as software updates, postage rate updates, secure transfer- of funds and other important services would make such open systems, and closed systems as well, even more desirable.
  • IBIP Information-Based Indicia Program
  • the invention is directed to a system and method for providing postal services to a plurality of remote postal printing stations.
  • the system includes a communications facility for conducting communications between a number of services provided by the system to the remote stations when the remote stations access the system using communications facility.
  • the services include at least one of key management, funds telemetering, software updating, postal rate updating, address cleansing, account management, and recording postal statistics.
  • the communications facility may include an interface for Internet communication and an interface for modem communication.
  • the interface for Internet communication may include a remote access server and a plurality of application programming interfaces.
  • a monitor may be provided for determining when any service is being accessed, to providing a signal to all other services that additional services can be provided to the remote station. This monitor may be located in each remote station.
  • Data encryption facilities may be used, with a different level of security being provided by said facilities for different ones of said services.
  • Fig. 1 is a block diagram of a system in accordance with the invention.
  • Fig. 2 is a simplified and more general block diagram of a system in accordance with the invention.
  • Fig. 3 is a simplified diagram of an Internet communications protocol used in the system of Fig. 1 and Fig. 2.
  • Fig. 4 is a diagram illustrating the relationship between various communications classes used in the protocol illustrated in Fig. 3.
  • Fig. 5 illustrated a typical data flow between a user and a front-end server of the system of Fig. 1 and Fig. 2.
  • Fig. 6 illustrates the class of communications on the services router of the system of Fig. 1 and Fig. 2.
  • Fig. 7 is a flow diagram which illustrates the normal flow of messages as they arrive from the client and are sent to the server, and messages as they arrive from the server and are sent to the client.
  • FIG. 1 there is shown a block diagram of a system 12 incorporating features of the present invention.
  • the present invention will be described with reference to the embodiments shown in the drawings, it should be understood that the present invention can be embodied in many alternate forms of embodiments. In addition, any suitable type of elements or materials could be used.
  • System 12 includes a postal system infrastructure 14 which is preferably housed in a secure location or room 16 which only authorized personnel may enter.
  • infrastructure 14 communicates with a plurality of postage printing host systems 18, which may be of the open system variety, including a personal computer 20 and an appropriate Postal Security Device (PSD) 22 for securely storing the value of funds to be expended when postage is printed.
  • PSD Postal Security Device
  • Infrastructure 14 may also communicate with a plurality of PSD's, as represented by PSD 23 of a number of so called closed systems 25, as more fully described below.
  • Infrastructure 14 may also communicate with a data processing system 24, such as for example an IBM AS 400 system to handle data processing needs. Through this system the customer can place orders for new PSD(s), return PSD(s) no longer needed and report lost or stolen PSD(s).
  • PSDs will also track PSDs through its life cycle. While data processing system 24 is shown as being external to room 16, it will be understood that there is nothing to prevent it from being located therein. A connection may also be made between infrastructure 14 and a factory production computer system 28 in a factory secure area of room 30 so that functions such as PSD encryption and key management can be carried out when new PSD's 32 are produced, or when they are serviced in a factory setting.
  • Infrastructure 14 may include, among other service providing systems a key management system 34 in including a Key Management System Station (such as an NT station) 36, which includes a plurality of security devices (SD)38 as well as a database server 40.
  • Infrastructure 14 may also include a TMS system 42 for interfacing with a plurality of postage printing stations 44 and 46 of various kinds by a bank of conventional modems 48A to 48N.
  • services and Internet server 50 that communicates with a number of stations 20 and 25 by using TCP/IP Internet protocol sockets on the Internet or by using modems 52, and preferably the same protocol as more fully explained below.
  • the host or remote station 10 and PSD systems are located at a customers' facilities. Access to these systems are restricted according to the needs of each customer.
  • the primary function of the server 50 of Fig. 1 is to act as a router between the Postal Security Devices, connecting in from customer sites, and the TMS system 42 and KMS system 34. Physical connection to the server 50 is made either via a dial-up modem or via the Internet. In either case, the connection is made through a specific TCP/IP address and socket port number. There are two port numbers available for connection. Depending upon which port is specified, the server 50 will establish a virtual connection between the PSD and either the TMS System or the KMS System.
  • a server 50 may be used to encrypt and decrypt data being transferred between infrastructure systems and the host systems .
  • KMS 34 The primary function of the Key Management System 34 is to provide software that will manage the usage of public and private keys for the Postal Security Device . Additionally, KMS 34 will provide all of the ancillary services to the PSD while it is in the manufacturing facility, including the manufacture, configuration, the removal from service and the reinstatement to service for a new customer. KMS deals with a few external interfaces. They include the server 50, the PSD (via the Ascom Host System) , the USPS Certificate Authority, the Tele- Metering System (TMS) , and the Order Processing and Meter Tracking System or data processing system 24.
  • TMS Tele- Metering System
  • KMS manages the keys and certificates that are stored in the PSD and in the Ascom KMS database. KMS is responsible to emulate the current "Check In/Check Out” process of the USPS. Additionally, KMS acts as the main tool to diagnosis problems that may occur in the PSD while it is in the field. The diagnostic capability allows technicians the ability to view the PSD's log files discussed below.
  • the primary function of the TMS system 34 is to manage customer funds and audit information concerning the use of the funds.
  • the TMS System is given the identity and encryption key of a PSD during the manufacturing process.
  • the PSD is assigned to a customer, the correlation between the PSD and customer account number is created. From then on, any time funds are to be loaded into the PSD, it is the TMS's responsibility to insure they are taken from the correct customer account.
  • the PSD returns audit information back to the TMS.
  • the TMS verifies and stores this information under the appropriate customer's account.
  • the TMS sends the PSD's control total data to the KMS System.
  • the Host system or remote stations include a client/server software product that provides the capability to print addresses and indicium on mail pieces.
  • the client side components provide the addressing application while the server side components provide the indicia generation.
  • the Host System utilizes one or more standard personal computer (s) with printers.
  • the PC(s) may have attached one or more physical Postal Security Device (s) (PSD) through serial ports.
  • PSD Postal Security Device
  • the combination of PC(s) , printers and PSD(s) may be distributed over local (LAN) or wide area (WAN) networks.
  • the server portion of the product may to be incorporated into third party products or used as an embedded control for Microsoft's Office products in order to provide address cleansing and indicia generation.
  • the product performs IBIP printing in addition to the functions of address list selection, cleansing of addresses and finally printing of the addresses.
  • the software also manages all of the ' communications between the PSD and the infrastructure; namely, the TMS 42 and Key Management System (KMS) 34 for the purposes of postage refills, parameterization, encryption key generation, or software updates.
  • KMS Key Management System
  • the Postal Security Device product is a specific implementation of the USPS-defined IBIP (Information Based Indicia Program) technology.
  • the PSD is a secure device that is attached to the host system via an RS-232 serial port . It contains funds that are used to frank mailpieces. The funds are securely added to the PSD by connecting to the TMS System. The TMS System downloads the funds, via the host System or remote station software, to the PSD. The PSD subsequently uploads audit information back to the TMS. Once the PSD has funds available, it is able to generate Indicia Data for evidencing postage payment including computation of any cryptographic data. During its life cycle the PSD maintains accurate postal accounting registers and transaction history.
  • the PSD also communicates to the KMS System via the host system software.
  • the PSD and KMS cooperate to generate the indicia by insuring that an active indicia certificate exists for the PSD.
  • the PSD can get new keys when the keys or certificates are about to expire via calling into the KMS System.
  • the KMS System may also used for the parameterization and authorization of the PSD while the device is in the field.
  • Fig. 2 illustrates a simplified and generalized system in accordance with Fig. 1 which may utilize the communication protocol of Fig. 3. It is meant to conceptually illustrate a system supplying services broadly.
  • Fig. 2 uses the same reference numerals as Fig. 1 for elements already described with respect to Fig. 1, which description will not be repeated. However, additional elements are described below.
  • a postal rate update system 52 may be provided from a postal rate update system 52, a host software update system 54, and a postal statistics server or PSS 56.
  • the later may be used to upload postal log data. As more fully described below. This data can then be sent to the United States Postal Service 58 by modem over via the Internet .
  • Other services may include a package tracking application or service system 60. Individuals or business awaiting a package shipped with postage or the indicia of other services entered at hosts or remote locations 18, may determine the time and date on which a package was shipped, if provided with the proper software and passwords needed to communicate with infrastructure 14".
  • a central address cleansing system 62 may provide address cleansing for addresses entered at remote stations 18.
  • a miscellaneous service system 64 may be used to provide any one of a number of different services not necessary tied into postal functions. For example, this system may be used to enable printing of tickets to entertainment events, with a PSD like security feature, so that payment is verified before a ticket is printed. Alternatively, it may be used to print lottery tickets.
  • remote stations 18 can be used for a variety of functions, limited only by infrastructure 14 and appropriate . software being available in each host or remote station 18.
  • each one is represented by a module 66 , which will have a corresponding socket, as described below.
  • a separate software module in the form of a monitor module 68, checks for operation of any of the other modules 68. If a connection is made to the infrastructure to obtain any service, module 68 provides an appropriate signal to the other modules 66 to notify the other modules that a connection has been made, and to give these other modules an opportunity to receive corresponding services from the appropriate system in infrastructure 14.
  • each host or remote station is connected to infrastructure 14 by means of a modem 70, or via the Internet by means of an ISP 72 as- more fully discussed below.
  • the infrastructure provides a standardized backbone of communications to current systems as well as any future systems.
  • the physical connection may be a direct telephone connection or via the Internet through some internet service provider (ISP) .
  • ISP internet service provider
  • the TCP/IP protocol is an .industry standard, which allows multiple concurrent connections allowing a connected system to communicate with multiple entities within the infrastructure. Each entity within the infrastructure may have a different application level protocol but all will utilize the same session layer protocol.
  • the Sockets API is used to access the functionality of TCP/IP. Therefore, the remainder of this document is written from that standpoint. It is also assumed that the Sockets API will be provided by the Operating System.
  • the infrastructure contains one main connection entity called s services router. This router is comprised of multiple Socket Servers, where each Socket Server is accepting connections on a particular Socket Port. Each Socket Port is representative of some service such as the TMS or KMS. The router then routes these service connections to the individual entities within the Infrastructure (e.g. TMS, KMS) .
  • Fig. 3 depicts the connections between a product and the. Ascom Services Infrastructure.
  • the product side of the connection is always a Socket Client. For each Service that is to be connected, one must create a Socket Client connection to each Service. Since all of the Services are routed through one Service Router, only one IP address is necessary and while the Socket Port number distinguishes each service. If for example, the product was to connect to the TMS and KMS, it would connect to the two different Socket Port numbers representing those two entities.
  • the Socket Clients (product side) establish connections by connecting to the Socket Server (Services Router) .
  • Socket Server Services Router
  • the session layer uses a Transmission header that describes the data.
  • the Transmission header is always sent before the actual data.
  • the data may be encrypted or non-encrypted, this is indicated by a flag in the header It is up to the application layer to indicate whether the data should be encrypted before transmission.
  • the receiving side will examine the encryption flag in the Transmission header and decrypt the data if need be.
  • the streaming Socket protocol is such that transmission may be broken up at the will of the Socket layer. For example, if a "send" is posted for 100 bytes, the call may come back to the requesting code with the indication that only 37 bytes were sent . The requesting code must then make another request to send the rest of the 63 bytes and repeat the procedure if necessary. The same is true for receiving side; reading is continued until the desired amount has been collected.
  • the Session layer does not support "log-out” but rather a connection is released by simply closing the socket connection.
  • the Session layer timeouts vary depending on the connection medium. Direct phone connections are quite fast and reasonably predictable, while Internet connections can run into significant and unpredictable delays. As an estimate, 50-second timeouts are uses for phone connections and 140 seconds are used for Internet connections.
  • the services and Internet server 50 is designed to run on any Win32 platform, i.e., Windows-95, Windows-98 and Windows NT. It is preferably a multi-threaded server, which uses the ATL free threading model . It provides the communication between Front End Server (FES) and PSD Agent through modem or Internet.
  • FES Front End Server
  • PSD Agent will create the instance of the object, which launches the Server.
  • the Server is implemented as a process (exe) server because it is placed on the machine that can connect to the FES via Internet or Modem. It keeps the counter of the number of open connections. When it reaches zero, it gets disconnected from the FES.
  • the public interfaces can be found in the server component's IDL file (AGServer. IDL) . Operation is as follows .
  • the Client will request for the "OpenConnection" for TMS or KMS. Client will wait until it timeout or connected successfully to FES. If the open connection fails through one of the method (Modem or Internet) then it will try another method. If both of them fail then it will return the error code to the client. On successful connection to the FES, it will increment the counter of the m_nConnection of the CAGServerModule . Therefore, for the next OpenConnection request it does not have to dial again. It can use already established communication link. In addition, it will go through all Waiting Object and Set all of them, which will release all WaitForOpenConnection requests.
  • SendMessageSync will wait until it gets acknowledgement or timeout takes place.
  • SendMessageAsync will return promptly. It will send the size of the message buffer and message buffer pointer.
  • ReceiveiveMessage will wait for the data. It will return on the receiving of the data or timeout.
  • CSocketMgr is going to maintain the queue for the received messages.
  • the parameter for the ReceiveMessage is the pointer for the size of the message buffer and pointer to the messages buffer pointer.
  • the server will decide how to be connected with the FES. If the CommunicationMethods allows only modem connection, then it will try to be connected through modem only and vice versa. However, if it allows both methods, then it will look for the value of CommunicationPreference and it will decide how to be connected with the FES.
  • IPAdr Where the particular service related Services Router is located (FES) PortAdr - With which Port to talk
  • ModemTimeoutSec If connected through Modem what will be the timeout .
  • the server gateway is comprised of the classes depicted in Fig. 4.
  • CCommunicate Class Header File: Communicate.h This is the server's COM class. It is a free threaded COM object, which provides the methods to connection to FES, Send/Receive data and Wait and Release for open connection.
  • the member variable m_hEvent is the Event object used for the synchronization purpose. The data member m_hEvent will be created in the constructor of the CCommunicate. In addition, it will be copied into the HANDLEVECTOR maintained by CAGServerModule.
  • CAGServerModule Module File: Agserver.cpp
  • the common Server data and methods are placed in COM' s static global class CAGServer named _Module.
  • the data member m_nOpenConnection will keep the track of the number of open connections. When it reaches zero. It will break the connection between FES and server.
  • Fig. 5 shows the primary data flows for the server. Open Connection Request from the user.
  • Fig. 5 shows a typical data flow for an OpenConnection request from the User to the FES. Other request like CloseConnection, SendMessage, ReceiveMessage are going to use nearly the same sequence .
  • the Server is launched by the PSD Agent Server's CoCreatelnstantanceEx () for an COM object.
  • the Server's main thread then initiates any common internal processing by calling the Startup () method in _Module .
  • the Server automatically shuts down when the last COM object is released.
  • the Server's main thread will call the Shutdown () method in _Module to disconnect from the FES.
  • the SR acts as a firewall and router for the various systems within the infrastructure which provides some sort of service to products in the field.
  • the SR is designed in such a fashion as to remain running on an indefinite basis.
  • the SR shall provide support for multiple Socket ports to be routed.
  • the routing configuration information is to be maintained in the system Registry.
  • the SR maintains and displays statistics on the connection times of clients.
  • the SR shall run on a Windows-NT-Server and may therefore take advantage of its functionality.
  • Fig. 6 depicts the classes that comprise the SR. the are set forth below:
  • CServicesRouterView The view class of the SR is derived from CFormView and is used as the container for the dialog. There is one dialog displayed which contains a CPropertySheet . When the view is created, it reads the Registry to determine which services it is to route to which servers. It will then create a tab for each service. The tab contains a property page (CServicePage) described below.
  • CServicePage a property page described below.
  • CServicePage This class provides the property page for each tab of the property sheet. It is also the container for the CSocketPipelineServer object whose job it is to receive connections from Socket Clients.
  • the CServicePage object creates a CSocketPipelineClient object by which it connects to the host providing a service. Subsequently, any messages that are received from the Client are routed to the service host via the CSocketPipelineClient object. Any messages that are received from the Service host via the CSocketPipelineClient object are sent to the Client via the CSocketPipelineServer object.
  • CSocketPipelineServer This class provides a complete, asynchronous message delivery mechanism for connecting Socket Clients.
  • the client code may specify the maximum number of clients that may be accepted. Messages are delivered to and received from the CSocketPipelineServer via the CSocketPipelineMessage object. Messages to be sent out may be sent at will because they will be internally queued. Once a message has been successfully sent, then the client code will be notified with a status message. If the "pipeline" broke and the message was not sent successfully then the client code is also informed.
  • CSocketPipelineClient This class provides a complete, asynchronous message delivery mechanism for connecting with a Socket Servers. Messages are delivered to and received from the CSocketPipelineClient via the CSocketPipelineMessage object. Messages to be sent out may be sent at will because they will be internally queued. Once a message has been successfully sent, then the client code will be notified with a status message. If the "pipeline" broke and the message was not sent successfully then the client code is also informed.
  • CSocketServerEngine This class provides basic threading mechanisms for accepting Socket Client connections, sending messages and receiving messages.
  • CSocketClientEngine This class provides basic threading mechanisms for connecting to a Socket Server, sending messages and receiving messages.
  • CSocketServer This class provides basic primitive functions for a Socket Server.
  • CSocketClient This class provides basic primitive functions for a Socket Client.
  • CSocketPipelineMessage This class defines a basic container object for messages being sent and received.
  • This class is a container for receiving status from the CSocketPipelineServer or CSocketPipelineClient objects.
  • CThreadSafeQueue This class is a thread safe queuing class allowing the passing of objects between threads.
  • CUlongToPntrMap A thread safe utility class that stores pointers to anything. The pointers can be retrieved via a Unsigned long value.
  • CRegistryUtility A utility class for accessing the registry.
  • Fig. 7 illustrates the normal flow of both, messages as they arrive from the client and are sent to the server, and messages as they arrive from the server and are sent to the client.
  • the registry is read to determine which services need routing. For each service, the registry will contain Service Host and port information which will ultimately be used by the CSocketPipelineServer and CSocketPipelineClient objects. For each service that is defined, a property page object is created in the property sheet and initialized with the routing information.
  • Expected errors are those resulting from Socket breakage. These errors are programmatically handled to gracefully clean up the rest of the connection to the Server or Client as appropriate.
  • PSD Log Management System
  • PSS PSS 56
  • Fig. 2 Log Management System
  • the USPS currently requires PSD Indicia Logs to be uploaded to a manufacture's infrastructure with every connection.
  • the manufacturer may also keeps a Summary Log which contains PSD usage information .
  • a record contains the PSD's postal serial number, total postage, piece count by date and rate category.
  • the Host creates one PSD Log and one Summary Log for all PSD's configured in the system.
  • the USPS may drop the requirement for the Indicia Log. However, the manufacturer may continue and may even expand the use of the Summary Log. Therefore the Indicia Log, if upload may be disabled, will be truncated automatically once summary records have been created.
  • a common message header is used for messages between the Host and LMS as shown below.
  • the messages are described in the following section.
  • the messages consist of a Host login to the LMS, a LMS logout message to terminate the connection with the Host, and a set of LMS commands and Host responses to upload and manage the Host ' s PSD logs .
  • the Host sends a login to the LMS specifying the number of indicia records available for upload.
  • the LMS accepts the login and begins uploading commands, or rejects it and terminates the connection.
  • the login message identifies the
  • LoginForPsdLogsResponse Function The LMS either accepts the Host login, which places the Host in a wait state for an LMS command, or rejects the Host login, which terminates the connection.
  • the LMS ends a Host connection by sending the Logout command. Both the LMS and Host terminate the connection. There is no Host reply message.
  • the LMS sends the Logout message to the Host to terminate the connection.
  • the LMS begins an Indicia Log upload by sending the SendlndiciaLog command.
  • the Host sends SendlndiciaLogResponse messages until the file has been transmitted.
  • Target System Host Data Definition: None.
  • Each response contains an end-of-file flag and one or more fixed length Indicia Log records.
  • the maximum message data size is 512 bytes. Messages are sent till end-of-file.
  • the LMS begins a Summary Log upload by sending the SendSummaryLog command.
  • the Host sends SendSummaryLogResponse messages until the file has been transmitted.
  • Each response contains an end-of-file flag and one or more fixed length
  • the maximum message data size will be 512 bytes.
  • the LMS controls the Host's PSD Indicia logging by sending the SetLogging command. Logging is turned on or off for all PSD Indicia Logs.
  • the Host informs the LMS of the new logging state.
  • ClearPsdLogResponse Function The Host informs the LMS the result of the ClearPsdLog command.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un système et un procédé pour la fourniture de services postaux à plusieurs stations postales d'impression distantes, comprenant une unité qui assure les communications entre un certain nombre de services fournis par le système aux stations distantes lorsque celles-ci accèdent au système. La palette des services comprend au moins l'un des services suivants: gestion de clés, télégestion de fonds, mise à jour de logiciel, mise à jour de tarif postal (52), épuration d'adresse (62), gestion de compte, et enregistrement de statistiques postales. L'unité de communication peut comprendre une interface pour les connexions Internet et une interface pour les liaisons de modem. La première interface peut assurer la liaison avec un serveur d'accès distant et une pluralité d'interfaces de programmation d'application. Un dispositif de contrôle peut être inclus pour déterminer l'accès à tel ou tel service, et transmettre un signal à tous les autres services indiquant que des services additionnels peuvent être fournis à la station distante.
PCT/US2001/004480 2000-02-11 2001-02-12 Systeme et procede pour la fourniture de services postaux WO2001059682A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001236926A AU2001236926A1 (en) 2000-02-11 2001-02-12 Apparatus and method for providing postal services

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US18175700P 2000-02-11 2000-02-11
US60/181,757 2000-02-11

Publications (2)

Publication Number Publication Date
WO2001059682A1 true WO2001059682A1 (fr) 2001-08-16
WO2001059682A9 WO2001059682A9 (fr) 2002-10-24

Family

ID=22665659

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/004480 WO2001059682A1 (fr) 2000-02-11 2001-02-12 Systeme et procede pour la fourniture de services postaux

Country Status (2)

Country Link
AU (1) AU2001236926A1 (fr)
WO (1) WO2001059682A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5712787A (en) * 1995-07-10 1998-01-27 Canada Post Corporation Electronic postal counter
US6175827B1 (en) * 1998-03-31 2001-01-16 Pitney Bowes Inc. Robus digital token generation and verification system accommodating token verification where addressee information cannot be recreated automated mail processing

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5712787A (en) * 1995-07-10 1998-01-27 Canada Post Corporation Electronic postal counter
US6175827B1 (en) * 1998-03-31 2001-01-16 Pitney Bowes Inc. Robus digital token generation and verification system accommodating token verification where addressee information cannot be recreated automated mail processing

Also Published As

Publication number Publication date
AU2001236926A1 (en) 2001-08-20
WO2001059682A9 (fr) 2002-10-24

Similar Documents

Publication Publication Date Title
US20030074324A1 (en) Apparatus and method for providing postal services
US7937333B2 (en) System and method for facilitating refunds of unused postage
US6442571B1 (en) Methods and apparatus for secure electronic, certified, restricted delivery mail systems
EP0717376B1 (fr) Dispositif de machine à affranchir et système et procédé pour communiquer avec des machines à affranchir
US6567794B1 (en) Method for access control in a virtual postage metering system
CA2263434C (fr) Procede de controle d'acces dans un systeme d'affranchissement virtuel
EP0927963B1 (fr) Machine à affranchir virtuelle avec système fermé
US7778924B1 (en) System and method for transferring items having value
US7149726B1 (en) Online value bearing item printing
WO2002007104A1 (fr) Impression d'articles a valeur affichee activee par le web
US7555467B2 (en) System and method for reliable transfer of virtual stamps
EP1934802A2 (fr) Gestion de fonds d'affranchissement destines a etre utilises par plusieurs machines a affranchir
JP2002518747A (ja) メーリングシステムのシステム構成を安全にする技術
US7113928B1 (en) Franking machine and operating method thereof
WO2001059682A1 (fr) Systeme et procede pour la fourniture de services postaux
EP3287989B1 (fr) Impression d'affranchissements à distance au moyen d'un équilibrage de charge efficace des demandes d'affranchissement

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

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

AL Designated countries for regional patents

Kind code of ref document: A1

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

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: C2

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

AL Designated countries for regional patents

Kind code of ref document: C2

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

COP Corrected version of pamphlet

Free format text: PAGES 1/7-7/7, DRAWINGS, REPLACED BY NEW PAGES 1/7-7/7; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP