Classifications

• • 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
• • 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
  • G07B2017/00048—Software architecture
  • G07B2017/00056—Client-server
• • G—PHYSICS
  • G07—CHECKING-DEVICES
  • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
  • G07B17/00—Franking apparatus
  • G07B17/00016—Relations between apparatus, e.g. franking machine at customer or apparatus at post office, in a franking system
  • G07B17/00024—Physical or organizational aspects of franking systems
  • G07B2017/00048—Software architecture
  • G07B2017/00056—Client-server
  • G07B2017/00064—Virtual meter, online stamp; PSD functions or indicia creation not at user's location
• • G—PHYSICS
  • G07—CHECKING-DEVICES
  • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
  • G07B17/00—Franking apparatus
  • G07B17/00016—Relations between apparatus, e.g. franking machine at customer or apparatus at post office, in a franking system
  • G07B17/0008—Communication details outside or between apparatus
  • G07B2017/00145—Communication details outside or between apparatus via the Internet
• • G—PHYSICS
  • G07—CHECKING-DEVICES
  • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
  • G07B17/00—Franking apparatus
  • G07B17/00185—Details internally of apparatus in a franking system, e.g. franking machine at customer or apparatus at post office
  • G07B17/00193—Constructional details of apparatus in a franking system
  • G07B2017/00201—Open franking system, i.e. the printer is not dedicated to franking only, e.g. PC (Personal Computer)
• • 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
  • G07B2017/0087—Key distribution
  • G07B2017/00887—Key distribution using look-up tables, also called master tables with pointers
• • 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/00959—Cryptographic modules, e.g. a PC encryption board
  • G07B2017/00967—PSD [Postal Security Device] as defined by the USPS [US Postal Service]

Definitions

• the present invention relates to secure printing of value-bearing items (VBI) preferably, such as postage, tickets, and coupons. More specifically, the invention relates to administration and commerce processing of users of an on-line postage system for validating and printing value-bearing items indicia in a Wide Area Network (WAN) environment.
• VBI value-bearing items
• WAN Wide Area Network
• Metered postage is generated by utilizing postage meters that print a special mark, also known as postal indicia, on mail pieces.
• Postage meters that print a special mark, also known as postal indicia
• printing postage and any VBI can be carried out by using mechanical meters or computer-based systems.
• IBIP Information-Based Indicia Program
• PSD Postal Security Device
• the USPS has published a number of documents describing the PSD specifications, the indicia specifications and other related and relevant information.
• security standards for printing other types of VBIs such as coupons, tickets, gift certificates, currency, voucher and the like.
• a significant drawback of existing hardware-based systems is that a new PSD must be locally provided to each new user, which involves significant cost. Furthermore, if the additional PSD breaks down, the PSD must be replaced or service calls must be made to the user location.
• a software-based system has been developed that does not require specialized hardware for each user.
• the software-based system meets the IBIP specifications for a PSD, using a centralized server-based implementation of PSDs utilizing one or more cryptographic modules.
• the system also includes a database for all users' information.
• the software-based system in turn, however, has brought about new challenges. These challenges include the need for effective and efficient user administration, commerce processing and management of the relatively large amount of data associated with the Internet Postage. A compelling reason for individuals and business to use Internet postage is for the great convenience it offers. Without robust and largely automated back office procedures, including user administration, commerce processing and database and information management, the advantages of
• the software-based system should be able to handle secure communications between users and the database.
• the software-based system should also be user friendly for the operators of the system as well as for customers, and should provide a postal system Intranet that allows effective process flow and operator interfaces, should provide for meter refunds and service withdrawals, should include misprint processing management, and should provide for quality assurance envelope management.
• the software-based system should also be feature rich and enabled to handle a variety of backroom commerce processing operations, such as payment processing, credit card processing,
• a secure central database in an on-line VBI system has been designed.
• the central database includes account balances and other information for all of the on-line value-bearing item system customers and is capable of preventing access by unauthorized users.
• a further aspect of the invention is a software-based system and method that is user friendly for the operators of the system as well as for customers, and should provide a postal system Intranet that allows effective process flow and operator interfaces, should provide for meter refunds and service withdrawals, should include misprint processing management, and should provide for quality assurance envelope management.
• the software-based system and method should also be feature rich and enabled to handle a variety of backroom commerce processing operations, such as payment processing, credit card processing, CMRS processing, and billing processing.
• the present invention is useful for printing not only postage, but any value bearing items, such as coupons, tickets, gift certificates, currency, voucher and the like.
• FIG. 1 is a block diagram for the client/server architecture of one embodiment of the invention
• FIG. 2 is a block diagram of one embodiment of postage servers
• FIG. 3 is a block diagram of servers, databases, and services provided by one embodiment of the invention.
• FIG. 4 is a block diagram of servers, databases, and services provided by one embodiment of the invention.
• FIG. 5 is a block diagram of a postal system intranet of the invention.
• FIG. 6 is a standard screen layout for the GUI
• FIG. 7 is a screen flow for a customer support department
• FIG. 8 is an exemplary customer support header
• FIG. 9 is a screen print of search results
• FIG. 10 is a customer detail screen
• FIG. 11 is a reset password process flow
• FIG. 12 is a screen print of the password recovery verification
• FIG. 13 is a postage transaction history screen print
• FIG. 14 is an account credit screen print
• FIG. 15 is an account credit verification screen print
• FIG. 16 is a License Detail screen print
• FIG. 17 is an Account Status History screen print
• FIG. 18 is an E-mail History Screen print
• FIG. 19 a screen print of an Account Statement History
• FIG. 20 is an Account Statement Details screen print
• FIG. 21 is a Convenience Fee Waive (or Suspense) screen print
• FIG. 22 is a Fee Waive Verification screen print
• FIG. 23 is a Convenience Fee Adjustment screen print
• FIG. 24 is a process flow for a Print Error Credit module
• FIG. 25 is a screen flow for CSR Managers
• FIG. 26 is a process flow for an Account Withdrawal/Close Account
• FIGS. 27 and 27A-27C are various reports pages Customer Support Home/Search portion of the Postal System Intranet;
• FIG. 28 is a screen flow showing the Meter Administration System
• FIG. 29 is a process flow for MA Account Withdrawal
• FIGS. 30 and 31 are process flows for administrative hold/suspend;
• FIGS. 30A-C are various screen prints for MA;
• FIG. 32 and 33 are two alternate routes to activate an accounts in the MA
• FIGS. 32A-B are screen prints of accounts activated and verified, respectively;
• FIG. 34 is a file transfer and download process;
• FIGS. 354A-F are various screen prints in the file transfer and download process
• FIG. 35 is a QA envelope manual entry process flow
• FIGS. 35A-B are QA envelope screens
• FIGS. 36A-E are various report screens in MA
• FIG. 37 is a payment administration process flow
• FIG. 37A is a screen print of the payment administration home page
• FIGS. 38A-B are process flows for ACH transaction processing
• FIGS 38C-E are various screen and tables for ACH transaction
• FIGS. 39A-L are various screen prints of reports in the Payment Administration process
• FIG. 40 is a process flow for Payment Administration Management
• FIG. 41 is a process flow for Payment Administration Manager screen flow
• FIG. 42 is an ACH Transaction Reversal process flow
• FIGS. 42A-D are various screen prints of the ACH Transaction Reversal process;
• FIG. 43 is a system configuration screen print;
• FIG. 44 is an Accounts Receivable screen flow
• FIG. 45 is Accounts Receivable process
• FIG. 46 is a Management screen flow
• FIG. 47 is a Home page of the Management screen flow
• FIG. 48 is a chart of Systems Metrics
• FIG. 49 is a screen print of a Refund/Withdrawal process flow
• FIG. 50 is a screen print of the Surrender Meter Confirmation
• FIG. 51 is a dialog box Meter Refund Confirmation
• FIG. 52 is a screen print of a Withdrawal Request Report
• FIG. 53 is a screen print of a Withdrawn Meters Report
• FIG. 54 is a screen print of the Withdrawal meter
• FIG. 55 is a screen print of a CS confirmation
• FIG. 56 is an error message
• FIG. 57 is a Refund/ Withdrawal Processing Flow Diagram
• FIG. 58 is a screen print of a Withdrawal Request Report
• FIG. 59 is a screen print of a Withdrawal Meters Report
• FIG. 60 is a table of the specifications for form PS 3601-C;
• FIGS. 61 and 62 is a table of refund indicia data;
• FIG. 63 shows the five places involved in the printing chain of events that can cause indicia to misprint or not print at all;
• FIG. 64 is a misprint refund process flow
• FIGS. 65-67 are screen prints for misprint processing
• FIGS. 68 and 69 are report screen prints for misprint processing
• FIG. 70 is a table listing three approaches to handling misprints.
• FIG. 71 is a chart of codes representing various envelope states for QA Envelope Management
• FIG. 72 is a process flow of a Scan Screen Flow ;
• FIG. 73 is a login screen of the Scan Screen flow;
• FIG. 74 is a QA Envelope 1406 a screen print
• FIG. 75 is a sample input screen for manual entry of the QA Envelope scanning
• FIGS. 76 and 77 are table of information associated with Commerce Processing
• FIG. 78 is a payment process flow
• FIGS. 79 and 80 are tables of credit card information
• FIG. 81 is a flowchart showing ACH batch processing
• FIG. 82 is a flowchart showing ACH meter resets processing
• FIG. 83 is a flowchart showing credit card processing
• FIG. 84 is a flowchart showing back-end processing
• FIG. 85 is a table of pricing plans
• FIG. 86 is a pricing plan selection process
• FIG. 87 is a flowchart showing the meter surrender and pricing plans
• FIG. 88 is a flowchart showing the monthly billing process
• FIG. 89 is a flowchart showing the disputed charge process
• FIG. 90 is a sample DTR/DBAR Fax
• FIG. 91 is a form for details for reconciling items on DBAR
• FIG. 92 is a table of definitions for DBAR for FIG. 90;
• FIG. 93 is a screen print of an interface for the payment administrator.
• FIG. 94 is screen print for an auto-refill feature of the commerce processing system.
• the unique features of the on-line postage system and method include a postal system intranet which provides for efficient information process flow, meter refund and withdrawal processing, misprint processing, Quality Assurance management, and commerce processing.
• An exemplary on-line postage system is described in U.S. patent Application No.09/163,993 filed September 15, 1998, the contents of which are hereby incorporated by reference.
• the on-line postage system includes an authentication protocol that operates in conjunction with the USPS.
• the system utilizes on-line postage system software comprising user code that resides on a client system and controller code that resides on a PSD server system.
• the on-line postage system allows a client to print a postal indicium at home, at the office, or any other desired place in a secure, convenient, inexpensive and fraud-free manner.
• the system comprises a user system electronically connected to a PSD server system, which in turn is connected to a USPS system.
• a USPS for purposes of explanation, the USPS is discussed. However, the system and method of the invention could be used with other postal authorities IBIP type of programs and systems.
• the server system is remotely located in a separate location from the client. All communications between the client and the server are preferably accomplished via the Internet.
• FIG. 1 illustrates a remote client system 220a connected to a server system 180 via the Internet 221.
• the client system includes a processor unit 223, a monitor 230, printer port 106, a mouse 225, a printer 235, and a keyboard 224.
• Server system 102 includes Postage servers 109, Database 111, and cryptographic modules 110.
• Postage servers 109 provide indicia creation, account maintenance, and revenue protection functionality for the on-line postage system.
• the Postage servers 109 include several physical servers in several distinct logical groupings, or services as described below.
• the individual Postage servers could be located within one facility, or in several facilities, physically separated by great distance but connected by secure communication links.
• Cryptographic modules 110 are responsible for creating PSDs and manipulating PSD data to protect sensitive information from disclosure, generating the cryptographic components of the digital indicia, and securely adjusting the customer registers. When a user wishes to print postage or purchase additional postage value, a user state is instantiated in the PSD implemented within one of the cryptographic modules 110.
• Database 111 includes all the data accessible on-line for indicia creation, account maintenance, and revenue protection processes.
• Postage servers 109, Database 111, and cryptographic modules 110 are maintained in a physically secured environment, such as a vault.
• a client preferably licensed by the USPS (or some other postal authority) and registered with an IBIP vendor (such as Stamps.com), sends a request for authorization to print a desired amount of postage.
• the PSD server verifies that the client's account holds sufficient funds to cover the requested amount of postage, and if so, grants the request.
• the server then sends authorization to the client system.
• the client system then sends image information for printing of a postal indicium for the granted amount to a printer so that the postal indicium is printed on an envelope or label.
• a client system When a client system sends a postage print request to the PSD server, the request must be authenticated before the client system is allowed to print the postage, and while the postage is being printed.
• the client system sends a password (or passphrase) entered by a user to the PSD server for verification.
• the PSD server system communicates with a system located at the USPS for verification and authentication purposes.
• the information processing components of the on-line postage system include a client system, a postage server system located in a highly secure facility, a USPS system and the Internet as the communication medium among those systems.
• the information processing equipment communicates over a secured communication line.
• the on-line postage system does not require any special purpose hardware for the client or user system.
• the client system is implemented in the form of software that can be executed on a user computer (client system) allowing the user computer to function as a virtual postage meter.
• the server system is capable of communicating with one or more client systems simultaneously.
• the on-line postage system is based on a client/server architecture.
• the server system delivers information to the client system. That is, the client system requests the services of a generally larger computer.
• a primary reason to set up a client/server network is to allow many clients access to the same applications and files stored on the server system.
• the on-line postage system includes the following subsystems: the Database subsystem, the Postal Server subsystem, the Provider Server subsystem, the E-commerce subsystem, the Staging subsystem, the Client Support subsystem, the Decision Support subsystem, the SMTP subsystem, the Address Matching service (AMS) subsystem, the SSL Proxy Server subsystem and the Web Server subsystem.
• Postage servers 132 include a string of servers connected to the Internet, for example, through a TI line, protected by a firewall.
• the Database subsystem includes a Postal Database 47, a Postal Database
• the Postal Server subsystem 41 manages client and remote administration access to server functionality, authenticates clients and allows clients to establish a secure connection to the on-line postage system.
• the Postal Server subsystem also manages access to USPS specific data such as PSD information and a user's license information.
• the PostalX Services provide business logic for postal functions such as device authorization and postage purchase/register manipulation.
• the PXS services require cryptographic modules to perform all functions because the PXS services are vital to the system's integrity and are protected by encryption.
• the Postal Database Management System 47 A manages access to the Postal section of the Database subsystem where USPS specific data such as meter and licensing information is stored.
• the Postal Database 47 is a secure database that stores all information for the Postal Server subsystem.
• the Postal portion of the Database subsystem contains the postal-specific information such as licensing, registration, and meter-specific data for all of the customers. Access to the Postal portion of the Database subsystem occurs through the Postal Server subsystem.
• Each piece of client software has a unique software serial number, which will be generated and kept in the database during product registration.
• Provider subsystem 42B provides reporting and external communication functionality for the Postal Information System.
• the Provider subsystem is located on the PRVNET along with the Database Subsystem and communicates directly with the Database Subsystem when the
• Provider Subsystem services request Database subsystem information.
• Provider Subsystem 42B includes Provider Server 55 and Provider Database 42.
• the Provider Subsystem 42B includes the following services: Central Metering License Services (CMLS), Central Meter Resetting Services (CMRS), Automated Clearing House (ACH) transactions, Credit Card services and Billing services.
• CMLS Central Metering License Services
• CMRS Central Meter Resetting Services
• ACH Automated Clearing House
• the CMLS service forwards license applications to and processes requests from the CMLS in the USPS through a CMLS/CMRS communication link.
• the CMRS service provides meter movement and meter resetting information through the CMLS/CMRS communication link to the USPS Computerized Meter resetting infrastructure.
• the ACH Service submits ACH postage purchase requests through an ACH communication link to a USPS lockbox account at a bank.
• the Credit Card Service is invoked by the E-commerce services to authorize and capture funds from the customer' s credit card account and transfer them to a designated merchant bank.
• the Billing Service provides bills through e-mail to customers based on selected billing plans. All of the Provider subsystem's communication with external devices is secure, since the communication is encrypted.
• the Provider Database Management System 42A manages access to the Provider section of the Database subsystem where Provider specific data such as Meter resetting records, Postage Value
• PVD Download
• batch status information is stored.
• CMLS license information is stored.
• the PVD information is included in the log file that is sent to the USPS on a regular basis.
• the Provider Database 42 is a secure database that stores all information for the Provider Server subsystem.
• the Provider portion of the Database subsystem contains Provider subsystem specific data such as Meter resetting records, PVD information, batch status information and CMLS license information.
• the E-commerce subsystem 46B provides functionality for the E- commerce related services required by Customer Support personnel and system administrators.
• the Customer Support personnel and system administrators access the on-line postage system through the E-commerce subsystem.
• E-commerce subsystem 46B communicates with the Database subsystem through the Postal Server subsystem and preferably is connected to a Public Network.
• the E-Commerce subsystem also provides commerce-related services, such as payment processing, pricing plan support and billing, as well as customer care functionality and Lightweight Directory
• LDAP Location Access Protocol
• E-Commerce subsystem 46B also includes a group of servers and databases including the Proxy Services 43, E-commerce Servers 44, E-commerce Database 46, Membership Database 48, E-commerce Database Management System 46A, Membership Database Management System 48A, and Credit Card Server 45.
• Proxy Services 43 provide Customer Support and authenticated access for administrators to the E-Commerce Servers.
• the E-commerce Services such as payment processing, pricing plan support, billing, customer care functionality and LDAP membership services run on the E-commerce Servers 44.
• E-commerce Database Management System 46A manages access to E-commerce Database
• E-Commerce Database 46 where commerce related information is stored, as shown in FIG. 3.
• E-Commerce Database 46 includes information on non-postal commerce transactions, credit card validations, customer invoicing, etc.
• E-commerce Database Management System 46A is scalable and may easily be expanded to meet the needs of the system.
• the E-commerce portion of the Database subsystem includes specific data such as purchase transactions, pricing plans, billing information, and customer account information.
• Membership Database Management System 48A provides access to Membership database 48.
• the Membership Database Management System manages access to the LDAP membership directory database that hosts specific customer information and customer membership data.
• the Membership Database contains all customer and internal user profile information, plus security information for all internal system users.
• the Membership Database Management System is scalable and expands to meet the needs of the system.
• the SSL Proxy server 43 allows secure HTTP access from a web browser and is used by the system administrators to access the e-commerce subsystem.
• Web Server 56A is used to maintain the website, facilitate the customer support activities and distribute the client software to interested parties.
• Web Server 56A communicates with the clients 58 through the Internet 221 and the internal departments via the Intranet LAN 40A.
• the information for maintaining the website and tracking affiliate performance is located in Website Database 56.
• An affiliate Database (not shown) stores client software versions, affiliate profiles and tracking codes and Advertising and Marketing tracking numbers.
• FIG. 4 illustrates more subsystems of the on-line postage system, namely, AMS servers 61, Client Support Servers 62, Client Support Database Management System 62A, Client Support
• DSS Database Management System 63A the Decision Support Services (DSS) Database Management System 63A, DSS database 63, Staging Database Management System 66 A and Staging Database 66, SMTP server 65, and Backup Services 64.
• DSS Decision Support Services
• SMTP server 65 runs the internal and external E-mail systems.
• the Staging Services subsystem coordinates aggregation of business data. Preferably, each night, all of the changes made in the Database subsystem in the last 24 hours are loaded into Staging Database 66.
• Staging Services Database Management System 66A manages access to Staging Database 66. After gathering changes in the databases, Staging Services Database Management System 66 A strips out all of the critical data such as credit card numbers and critical USPS specific information, and moves the changes to offline databases.
• Staging Services Database Management System 66A is scalable and may be easily be expanded to meet the needs of the system.
• the Backup Services subsystem 64 provides the data backup for the Database subsystem.
• the AMS subsystem 61 validates source and destination addresses against a USPS table to verify the mail is being sent to a recognized location. This service is utilized each time the user attempts to print postal indicia.
• the AMS system is used when a user enters a delivery address or a return address using the client software. The user does not need the address matching database on the user's local machine to verify the accuracy of the address.
• the client software connects to the Postage Server and uses a central address database obtained from the USPS to verify the accuracy of the address. If the address is incorrect, the client software provides the user with a prioritized list of addresses to match the correct address. Preferably, these choices are ranked in order according to the type of match.
• Client Support Services subsystem 58 is comprised of the client services that typically do not require secure transactions.
• Client Support Services subsystem 58 includes the Client Support Servers 62, the Client Support Database Management System 62A, and the Client Support Database 62B as shown in FIG 4. The services that execute on the Client Support
• Servers preferably include, Registration Services, Auto-Update Service, Printer Configuration
• the Client Support Services are typically low in volume, however, the number of servers and the capacity of the database can be readily scaled according to the workload of the system.
• the Registration Services includes supported payment type and billing plan information.
• the Auto-Update Service updates the client software when new client software versions are released.
• the Printer Configuration Services assist in setting up the printer to guarantee that the indicia printed meets USPS criteria.
• the Rates Service calculates the correct rate for the client based on class, destination and weight.
• the Printer Database Service updates the on-line postage system with any new printer or printing information.
• Client Support Database 62B is an external storage component for the Client Support
• CSD 62B Transactions executing on the Client Support Servers requiring storage utilize the CSD 62B.
• the data storage size requirements for CSD 62B are relatively low.
• the database schema design allows for the data to be partitioned across multiple physical databases.
• the Decision Support System includes the DSS Database Management System 63A and the DSS Database 63, as shown in FIG. 5.
• the DSS allows restricted (read-only, time delayed) access to the postal data.
• the DSS Database Management System 63A controls access to DSS
• the DSS various accounting tasks for the Staging Services
• the DSS Database 63 is preferably offline and includes most or all of the user's profile information.
• the Postal System Intranet of the invention has the following process flow and user interfaces. Below is described the screens available on the Postal Information Systems Intranet. Preferably, all screens are HTML and generated through ASP, but other languages and protocols can also be used. Screen Flows outline the functions and menu levels available to a particular user group.
• Process Flows outline the underlying logic that applies to an action transaction. Individual screens and possible messages are shown after each Process Flow. There are typically two screens and at least two messages involved with a single process, as follows: Identification Screen - asks for relevant information and positively identifies customer.
• Verification Screen - asks user to verify that what he entered is correct. This may require reentry of identification information.
• Confirmation - visually confirms that the data entered was correct and/or the intended transaction was completed successfully.
• Certain of the Screens are actual screen captures of HTML interfaces as they are currently programmed, or are Visio mock-ups that have yet to be programmed.
• the Intranet can conveniently be broken up by user group. Each User group has access to their screens only. Access can be limited by the user's certificate.
• Stamps.com databases hold information that is valuable to all departments of the company and outside services and partners. Disseminating this information in an easy and efficient way is imperative to keep the company and its suppliers instantly informed about users, trends and trouble spots.
• database administration and information distribution tasks that need to be performed on a routine basis to outside suppliers and the USPS (or other postal authority.)
• Postal Intranet system users will access HTML pages through the Stamps.com Intranet via a browser, such as Netscape Navigator 4.5 or a later version, provided by Netscape Communications. Navigator presently provides secure 128 bit SSL encryption and handle security certificates more securely than IE. All screen resolutions may be set to a minimum of 800 x 600 pixels, with high color. This allows for maximum security and maximum information display area. Of course, this may change. In one embodiment, each Customer Support Representative will be assigned a unique
• Smartcard for access to the Postal Intranet.
• Each workstation is required to have a Smartcard reader installed. Users will not be able to login without a Smartcard, the corresponding user name and password. Smartcards assignment will be controlled inside the vault and maintained by Network Operations.
• User Interface can conveniently comprise all text, quick display HTML, viewable through
• each Usergroup starts at the Postal Information Systems Home Page, then goes to their Usergroup Home page. From a Postal Systems Home 100 page, users can go to
• a standard screen layout 110 (in this case, a screen display for "Meter Administration”.)
• the standard screen layout has a global menu bar 112, a logo hyperlink 114 which links to the postage server website (e.g. Stamps.com), a title bar 116 which contains Usergroup title (and optionally a predetermined Usergroup color), and a function list 118 which lists all functions available to the Usergroup located on the Usergroup home page.
• the postage server website e.g. Stamps.com
• a title bar 116 which contains Usergroup title (and optionally a predetermined Usergroup color)
• a function list 118 which lists all functions available to the Usergroup located on the Usergroup home page.
• FIG. 7 is a screen flow for a customer support department 201, and FIGS. 7-27 are various additional details of the customer support department 200.
• the Customer Support (CS) department needs access to user profile information.
• the CS department should be able to find this customer information quickly to reduce time on the telephone.
• the main functions of this system permit the following activities to take place:
• FIG. 8 is one exemplary Customer Support Header, which preferably can appear on all screens. All fields are preferably free-flow text.
• the user can search for a wildcard or specific customer. If the user does not use a wildcard search and there is an exact match to their query, the Customer Details will be called. If there is not an exact match, or the user specifies a wildcard, a list of "close" results will appear, for example as shown in FIG. 9, which is a screen print of Search
• Results This screen shows a list of results based on the query information provided on the Search screen. This list shows the closest match first, followed by the next closest matches, in numerical or alphabetical order. This list shows all searchable criteria, and preferably has the following features: Each line will be an active hyperlink. Clicking on a line record will take the user to
• Reset Password is selected, and the Reset Password Customer is identified 212.
• a secret code is entered 214 and submitted.
• a verification step 216 if the information is incorrect, then the CS representative must re-enter the customer identification information at step 212. If the information is correct, a system verification step 218 takes place. If the System verification information is invalid, a negative confirmation password reset code 220 is not sent and the CS representative must re-enter the customer identification information at step 212. If the information is correct, then the system generates a password reset Email 222, and a confirmation password reset code is sent to the email of the customer 224.
• a screen print of the password Recovery Verification 226 is shown in FIG. 12.
• FIGS. 13 and 14 there are shown a screen print of the Postage Transaction History screen print 230, and an Account Credit screen print 232.
• Reasons/types of account credits include: an account refund credit, charter member credit, customer payment not credited previously, a demo account, a disputed amount paid, a marketing promotion, a misprint credit, to prevent account closure, free postage for a service that is not initially added, dissatisfaction with the experience, and a valued customer credit.
• FIG. 15 is an Account Credit Verification screen print 234.
• An account credit confirmation is also provided 236 which will indicate that the customer's account has been credited as specified.
• Other screens can be provided, as follows (but not shown): If the account credit is over limit, then the screen can give the user a message such as "You have entered an amount greater than ⁇ limit>.
• FIG. 16 is a License Detail screen print 238, FIG. 17 is an Account Status History screen print 240, and FIG.
• Email History Screen print 242 The listed status will be one of 5 possible strings depending on the status code from the email database.
• the logic will first check the message queue for messages that are being sent (when available), then query the email database. These statuses are as follows: Queued-(x retries) - Where 'x' is the number of retries in the message queue; Sent - Not Confirmed; Sent - Server Receipt; Sent - Client Receipt; and Rejected. Clicking the hyperlink on any email in the Email History screen will reconstruct that particular email and display it exactly as the customer sees it.
• FIG. 19 there is shown a screen print of an Account Statement History Screen 246.
• FIG. 20 is a screen print of an Account Statement Details Screen 248. Clicking the hyperlink on any email in the Account Statement History screen will preferably reconstruct that particular email and display it exactly as the customer sees it.
• FIG. 21 is a screen print of a Convenience Fee Waive (or Suspense) screen 250.
• the CSR can be limited to a predetermined time period (e.g. three months.)
• Reasons for fee waive can include the following reason: Charter Member privileges; demo Account; employee; Failed Transaction
• FIG.22 is a Fee Waive Verification screen print 252.
• a Fee Waive Confirmation should also take place, with an exemplary possible message to the CSR being "The Customer's Fees have been waived as specified.” "OK" "Back to Account History.” If the CSR attempts to waive the fee over a predetermined limit, there can be a Fee Waive Over Limit option that can read "You have entered a waive time over ⁇ time limit, units>. You may only enter a time equal to or less than this. If you need to waive fees for a longer period please consult a manager.” “OK”. "Back to Fee Waive Screen.” If there is a Fee Waive Error, a message can be outputted "ERROR: ⁇ error reason> The entry was not processed. Please process this transaction again.”
• FIG. 23 is a screen print of a Convenience Fee Adjustment screen 256.
• Reasons for Service Fee Adjustment can include the following: Charter Member; Demo Account; Employee; Failed Transaction Fees; Marketing Promotion; Not Charged For Previous Fees; Other Adjustment; Over-Charged For Previous Fees; Prevent Account Closure; Unhappy With Experience; and Valued Customer.
• a Convenience Fee Confirmation 258 can then be generated, e.g. "The entry has been submitted successfully. The adjustment will appear in the customer's next regular statement.” “OK.” "Back to Account Statement History.” If the Convenience Fee is over limit, a message can be generated, such as "You have entered an amount greater than ⁇ limit>.
• FIG. 24 is a process flow for a Print Error Credit module 270.
• the user From the customer service home page 272, the user will select a "Credit Print Errors" button on the main menu bar 273, and will see a Print Error Claim Entry screen 274, an exemplar of which is shown on FIG. 24A. If finished entering information, the user will select the "Finished" button 275, and then there will be a verification step 276. If there is an error and the information does not match, then the user will be asked to try again 278. If the customer is verified, then there is a test to determine if the claim amount is within the predetermined maximum cap 280. If not, then an error message will be displayed indicating that the amount exceeds the cap 282.
• the user may select the more button 283 and be directed to a Printer Error Claim- Additional Entries page 284 (an exemplar being shown in FIG. 24B.)
• a user may use as many additional pages as necessary, and when completed, the user can be directed back to the verify customer step 276.
• the claim amount is within the cap, then the user is directed to a Print Error Claim Verification screen 286 (an exemplar being shown in FIG. 24C.)
• a Print Error Claim Confirmation 290 is displayed, and the claim is added to the customer's account. If the transaction fails, then an Error message is displayed, and the user is directed back to a verification screen 286.
• CSRs Customer Service Representatives
• CSR Managers Customer Support Representative Managers
• the main differences between CSRs and CSR Managers are the ability to run selected reports, the ability to make instant account adjustments, and the ability to withdraw accounts.
• the limits imposed on all credit /debit screens are also higher than the same screens available to CSRs.
• the Screen Flow 300 for CSR Managers is shown at FIG. 25.
• the CSR Manager utilizes a global menu 304 to generate reports
• reset password page 319 including reset password 326, close account 334, postal transaction history 340, license details 346, Stamps.com Email history 350, Convenience Fee Waiver 354, and Convenience Fee Adjustment 358.
• reset password page 326 From the reset password page 326, there will be a reset password verification 328, and a reset password confirmation 330.
• a reset password history log 332 will be display able as well (an example of which is shown in FIG. 25E.)
• the close account screen 334 the next screen is a withdrawal verification screen 336 and then a withdrawal confirmation page 338.
• Postal transaction history screen 340 next flows a credit account page 342 and a credit account confirmation page 344.
• license details page 346 there can be selected an account status history page 348.
• FIG.25 A is a representative screen print showing a Customer Support Manager Header 302.
• the header 301 preferably appears on all Customer Support Manager screens. All fields are preferably free-flow text.
• the user can search for a wildcard or specific customer. Wild cards are preferably only used at the end of a string. If the user does not use a wild card search and there is an exact match to their query, the Customer Profile or Customer Details Main page 318 will be called.
• FIG. 25B there is shown a screen print of the Instant Adjustment page 320.
• CSR Manager Limit for this screen can be set at some limit, such as $50.00.
• Adjustment can include the following reasons: Account Refund; Charged For
• FIG.25C is a screen print of the Instant Adjustment Verification page 322.
• an Instant Adjustment Confirmation will be generated, e.g., "The Customers ⁇ payment type> has been adjusted as specified. If the customer is using Direct Account Withdrawal (ACH) a check will be mailed to them in about 2 weeks.” “OK”, “Back to Customer Details.” If there is an Instant Adjustment Over Limit, there can be a screen print which displays something like
• FIG. 25D is a screen print of an Instant Adjustment History Log 324
• FIG. 25E is a screen print of a Reset Password History Log 332.
• the process flow for an Account Withdrawal/Close Account is shown in FIG.26, and greatly expands upon steps 334 to 338 depicted on FIG. 25. For convenience of presentation, different reference numerals are shown other than those of FIG. 25, although several steps overlap those shown in FIG. 25.
• the user will select "Withdraw Meter” and be directed to an Account Withdrawal identification Screen 376 (an example of which is shown in FIG. 26A) and verify the customer identity 378 and submit it. As an aside, the user can provide the necessary information to fill the fields about the customer. However, if the customer can access the withdrawal features in their software, then the customer must generally initiate the withdrawal at his end, and the CSR Manager will confirm the information. The customer will be asked questions, such as: Why are you canceling Stamps.com Service?
• the user may cancel the transaction 386 and be redirected back to the withdrawal screen 376. If the user desires to proceed, the software will determine if the transaction has been processed 388. If not, a Verification error message 390 will be generated and displayed to the user, and the user will be directed back to the withdrawal verification screen 384. If the withdrawal is processed correctly, then a Withdrawal Confirmation will appear 392, such as "The customer's information has been confirmed, their account has been closed and their account has been flagged for withdrawal. We will process their account balance refund within 14 days and send this information to the USPS. The customer will receive a check directly from the USPS in 6-8 weeks.” "OK", and the customer profile will be adjusted. Thereafter, a confirmation message (e.g. an Email) will be sent to the customer 394, and then the meter status will be updated to indicate that the customer has been withdrawn 396.
• a confirmation message e.g. an Email
• FIGS.27, and 27A-27C there are shown a Reports page 306 with option buttons for Customer Support Credits, Withdrawal Request Activity, and Instant Credits ACH Customers (FIG. 27), and pages for Customer Support Credits (FIG. 27A), Withdrawal Request Activity (FIG. 27B), and Instant Credits ACH Customers (FIG. 27C). That completes the Customer Support Home/Search portion of the Postal System Intranet.
• FIG. 28 is a screen flow showing the Meter Administration System 401 showing the organization and logical flow.
• the user can select Customer Search 404, Report 406, Suspend Meter 408, Activate Meter 410, Upload QA (Quality Assurance) Envelope Log 412, and File Transfer Status Monitor (and File Archive
• FIG. 29 there is shown a process flow for MA Account Withdrawal.
• This process is accessed by navigating through the Customer Detail Main page 420, and its basic steps of selecting Meter Administration (MA) Withdrawal Account 422, which generates a MA Withdrawal Account Verification 424 and finally a Withdrawal Account confirmation 426 in FIG. 28.
• MA Meter Administration
• FIG. 29 This process is shown in greater logical and process flow detail in FIG. 29. While some of the steps are the same as shown on FIG. 28, for convenience of presentation, unique reference numerals are used in describing the steps and process flow of FIG. 29.
• a user Starting from Meter Administration Home Page 480, a user enter search criteria 482 and searches.
• a logic step 484 determines if customer is found. If not, then message is displayed that no records could be found that match the search criteria 486, and the user is redirected to the Meter Administration Home Page 480.
• a Search Results List 488 is displayed. By selecting a hyperlink, the user is directed to a Customer Profile Screen 490. By selecting "Withdraw Meter”, a MA Withdrawal Screen 492 is displayed, which is then submitted.
• a decision tree 496 determines if the information is correct. If not, a message is displayed that "Information is incorrect, please verify” 498, and the user is re-directed to the MA Withdrawal Screen 492.
• An exemplary screen print of the MA Withdrawal Screen 492 is shown at FIG. 29A. If the information is correct, the user is directed to a MA Withdrawal Verification Screen 500. The user is asked to verify the withdrawal 502 and submit.
• An exemplary screen print of the MA Account Withdrawal Verification Screen 492 is shown at FIG. 29B.
• a confirmation screen 504 a message displays that the withdrawal was processed, and the user is directed back to the Customer Profile Screen 490.
• FIG. 28 the screen flow of an administrative hold/suspend from the MA Home page begins at the MA Home page 402, then goes to identify account to suspend 408, verify account 454 and confirm suspension screen 456.
• an administrative hold/suspend can be accessed through the Customer Detail Main screen 420, then go to the License Details page 434, an Account Status History page 436, a Suspend Account page 438, and finally a Confirm Suspension page 440.
• FIGS. 30 and 31 are described in great detail with respect to FIGS. 30 and 31, respectively, wherein FIG. 30 is a process flow administrative hold/suspend from the MA Home page, and FIG. 31 is a process flow administrative hold/suspend from the Customer Details Main page 420.
• FIG. 30 is a process flow administrative hold/suspend from the MA Home page
• FIG. 31 is a process flow administrative hold/suspend from the Customer Details Main page 420.
• the reference numerals used in describing FIGS. 30 and 31 are different than those used in FIG. 28.
• FIG. 30A is a screen print of the account search screen.
• the User will enter the search criteria 524 and submit it.
• a decision will be made whether the account number was found. If it is not found, a message will be displayed that the account was not found, please try again 528, and the User will be re-directed back to the account search screen 522. If the account number is found, the hold account screen 530 will be displayed, and FIG. 30B is an exemplary screen print of the hold account screen.
• the User will need to select reasons to hold the account. Some reasons to hold the account are, a demo account, license revoked, license suspended, non-approved printer, non-payment postage, non-payment service fees, QA envelope failed, QA envelope not received, suspected fraud, or general.
• the User will then submit the information and a verification screen 532 will be displayed, an exemplary sample of which is shown in FIG. 30C. If there is an error in the transaction and the information is not processed, the usual "get an error message" 534 and will be re-directed back to the hold account screen 530. If the information on the verification screen is correct, however, the User will submit it and will be taken to a confirmation screen 536 and then be directed back to the MA Home page 520.
• the User begins at the Customer Detail page 540, and selects "hold account.”
• the User will be then taken to a hold account screen 542 (such as shown in FIG. 30B) and submit the information.
• a verification screen 544 will be displayed (e.g., as shown in FIG. 30C). If there is an error in the transaction and it cannot be processed, the User will see an error message 546 and the User will be re-directed back to the hold account screen 542. If the information on the verification screen 544 is correct, the User will submit it and the User will see a Confirmation Screen 548 and thereafter will be redirected back to the Customer Detail page 540.
• the User will enter the search criteria 554 and submit this information.
• decision tree 556 it will be determined whether the account number was found. If not, a message will be displayed that the account number was not found 558, and the User will be re-directed back to the account search screen 552. If the account number is found, a decision tree will determine if the status is set to "on hold.” If not, a message will be given that account is active and to select another account number 556, and the User will be re-directed back to the account search screen 552. If the status is equal to on hold, then an activate account screen 564 will be displayed, an exemplar of which is shown in FIG. 32A. The User needs to select a reason for activation.
• Such reasons can include demo account re-opened, license cleared, printer approved, outstanding postage paid, outstanding service fees paid, QA envelope pass, QA envelope received, no fraud found, or general, and the User will submit the information, and verification screen 566 will be displayed.
• An exemplary screen print of such a verification screen 566 is shown in FIG. 32B. If the transaction cannot be processed, an error message will indicate that the transaction was not processed 568, and will re-direct the User back to the activate account screen 564. If upon submission, the transaction is processed, the User will see a confirmation screen 570 and will be re-directed back to the MA Home page 550.
• FIG. 33 is a process flow to activate an account from the customer details screen 572. Beginning with a customer detail page 572, User will select suspend an account and will see activate an account screen 574. The User will submit the information and see a verification screen 576. If the User decides to cancel the transaction, the User will be re-directed back to the activate an account screen 574. If the information is incorrect, and the transaction cannot be processed 578, the User will also be re-directed back to the activate an account screen 574. If submission of the verification screen information is successfully processed, a confirmation screen 580 is displayed and then the User is re-directed back to the customer details page 572. The file transfer status and file download process is shown in brief in FIG 28.
• the User From the MA Home page 402, the User will select file transfer monitor 414 or file archive search 416. From the file transfer status monitor 414, the User can select download file 464 and from the file archive search 416, the User can select file archive search result 466, and then download the file. These processes are shown in greater detail in FIG. 34. From the MA Home page 582, in order to initiate the file transfer status monitor, the User will select the file transfer status monitor page 584, an exemplar of which is shown in FIG. 34A.
• the file transfer status monitor page includes a file ID number 585, the expected time of transfer 585A, the status of the file currently 585B, the time of the last status change 585C.
• the available files include CMLS License applications, CMLS License confirmation, CMLS approvals, CMRS address, CMRS movement, CMRS resetting, Citibank ACH,
• FIG. 34B is a table listing the various statuses and their definitions.
• User will select the file ID hyper-link 585, and will re-direct it to a save as browser 586, an exemplary screen print which is shown in FIG. 34C. If there is a download file error, an error message will be displayed and the User can try again. If everything is correct, User can save the information and the download is complete 588, and the User will be directed back to the file transfer status monitor page 584.
• file archive search page 590 (an exemplary copy of which is shown in FIG. 34D), and the User will enter search criteria 592 and press search.
• file archive search results page 594 a sample screen print of which is shown in FIG. 34E.
• the User will be taken to a save as browser 598, a sample screen print of which is displayed as FIG. 34F, and the User can save this information at which point the download is complete 600 and the User is directed back to the file archive search results page. If however at the file archive search results page, no matches can be found 596, an appropriate message will be displayed, and the User will be redirected back to the file archive search page 590.
• the User can access the enter QA envelope information page 423 from the customer details main page 420. Or alternately, from the MA Home page from the upload QA envelope log 412 and then the upload confirmation 462.
• the QA envelope - manual entry process flow is shown in greater detail in FIG. 35. Again, for simplicity of the presentation, unique reference numerals are used in connection with this figure.
• the User will enter search criteria 612, and be directed to a decision tree matches found 614. If no matches are found, a message will be displayed that no records match the search criteria 616, and the User will be re-directed back to the MA customer search page 610.
• a search results list 618 will be displayed, and the User will select the hyper-link to the desired customer which will direct the User to a customer profile screen 620.
• the User can select a hyper-link on QA envelope and be directed to a QA envelope entry page 622, an exemplar of which is shown in FIG. 35 A.
• the User will enter the QA envelope information on this page and submit it.
• a decision tree 624 there is a determination whether the data is accepted. If not, a negative confirmation 626 is given and the User is directed back to the QA envelope entry page 622. If the data is accepted, a confirmation message that the QA envelope information has been successfully entered 628 is given, and the User is directed back to the MA customer search page 610.
• the User will begin at the MA Home page 402.
• An exemplar of the upload QA envelope log 412 is shown in FIG. 35B, and an upload confirmation 462 is given upon successful processing of the file upload. If an upload error occurs, then an appropriate message will be delivered.
• the User will begin at the MA Home page 402, will select reports 406, and select the report and date range desired, and have the option to choose among various reports including licensee summary 468 A (a screen print of which is shown in FIG. 36A), license application status 468B (an exemplar of which is shown in FIG. 36B), a password reset activity report 468C, a suspension status report 468D, a password reset activity report 468E, a suspension report 468F, a QA envelopes log report 468G (a sample screen print of which is shown in FIG. 36C), an activations report 468H, a VMLS confirmations/rejections report 4681 (a sample screen print of which is shown in FIG.
• a User can get an account reset transaction history 428, then select credit account 430, and finally credit account confirmation 432. Also, the User can get a Stamps.com account/statement history 450 and a Stamps.com account/statement details screen 452.
• the next main part of the postal system intranet is the payment administration module 701.
• FIG. 37 is a screen flow of a payment administration module.
• FIG.37A is an exemplary payment administration home page 700 screen print, and includes a customer search button 702, a process transaction button 704, a file transfer status monitor button 706, USPS logs 708, reports 710, reverse transactions 712, and systems configuration buttons 714,
• customer search screen 702 By selecting a customer hyperlink, a customer details main page 718 can be displayed. These page blue prints can be basically as shown in corresponding pages in the customer support module.
• the user can select postage transaction history 720, the credit account 722, and a credit account confirmation 724. Account credit over limit and account credit error messages can be displayed in association with these pages.
• licensee details 726 and account status history 728 can also be displayed.
• Stamps.com e-mail history 730 and Stamps.com e-mail detail 732 can be displayed, with similar screen prints as shown in the customer support module.
• an account statement history 734 and accounts statement detail 736 pages can be displayed again similarly as shown in the customer support accounts last statement history pages described further above. From the payment administration home page, the user can select process transactions 704, then transaction verification 740 finally, transaction confirmation 742.
• file transfer status monitor 706 can be selected and various files can be downloaded including CMLS license application 744A, CMLS confirmation 744B, CMLS approvals 744C, CMLS address 744D, CMLS movement 744E, CMLS resetting 744F, Citibank ACH 746A, Citibank receipt 746B, Chase ACH 748A, and Chase receipt 748B, the banks names Citibank and Chase are names of possible banks that may be used for financial transactions. Of course, other financial institutions can be named and by no means is this system limited to these identified banks.
• the user can also select file transfer archive search 731 from which file transfer archive results 732 can be obtained, and files can be downloaded. Turning now to FIGS.
• ACH error reports 738 A an exemplary screen print of which is shown in FIG. 39 A
• ACH transfer breakdown 738B a screen print of which is shown in FIG. 39B
• rejection/return summary 738C a screen print of which is shown in FIG. 39C.
• DTR daily transaction report
• DBAR daily bank activity reconciliation
• Additional reports include a credit card errors report 738G an accounts reset report 738H (see FIG. 39F), a non-captured refund requests report 7381 (see FIG. 391), a payment requests report 738 J (FIG. 39J) an account dispute/disputes resolved reports 738K (FIG. 39K) and notice of cancellation (NOC report 738L, a screen print of which is shown in FIG. 39L).
• Payment Administration Managers (Commerce) Module 801 one embodiment of which is shown in FIG.40. A second embodiment of a payment administration manager screen flow is shown in FIG. 41.
• a user begins at the payment administration home page 800 and can select a customer search screen 802 and select search to see search results 804.
• the user By clicking on a customer hyperlink, the user is taken to the customer details main page 806.
• user may enter QA postage information 808 and can obtain a QA postage confirmation 810.
• the user can access several screens. For example, the user can access the account research transaction history 812, from which the account credit screen 814 and then an account credit confirmation 816 can be viewed. Also, a licensee detail 818 and an account status history 820 can be seen.
• a Stamps.com email history page 822 and a Stamps.com email details page 824 can be displayed.
• the user can select "hold account” 826, verify the hold 828, and confirm the hold 830. Likewise, the user can activate the account 832, verify the activation 834, and confirm the activation 836. A convenience fee wave page 838 and a fee wave confirmation 840 can be displayed. Lastly, from the customer details main page, the user may select meter administration withdrawal account 842, meter administration withdraw account confirmation 844 and finally, meter administration withdraw account verification 846.
• the user can select a system configuration page 850 and then get a system configuration confirmation 852, an exemplary screen print of the system configuration confirmation page 850 is shown in FIG. 43.
• the user can upload QA envelope log 854 and display an upload confirmation 856.
• the user can also from the payment administration home page 800, display the file transfer status monitor 858 and download various files including pages displaying CMLS license applications 860A, CMLS confirmation page 860B, CMLS approvals 860C, CMRS address 860D, CMRS movement 860E , CMRS resetting 860F, Citibank ACH 860G and Citibank receipt 860H.
• report 862 can select reports 862, and select the report and choose a report date range 864 and access several different types of reports, including credit card error canned 866A, credit card captures canned 866B, credit card rejections canned 866C, account resets CMRS 866D, license rejections, update rejections and pendants 866E, password reset activity 866F, accounts on hold 866G, activated accounts 866H, and email only DTR/DBAR 8661. From any of these pages, the user can download tab-delimited reports 868.
• user can select the customer search screen 882, run a search and have displayed search results 884.
• the user can be taken to the customer details main page 886.
• the user can display the account reset transaction history page 888, the credit account page 890, and then the credit account confirmation page 892.
• a user can access a licensee details 894 and then the account status history 896.
• the user can also see the Stamps.com email history page 898 and from then the Stamps.com email details page 900. Further, the user can access the Stamps.com account/statement history page 902 and then the Stamps.com account/statement details page 904.
• the user can have displayed the processed transaction page 906, the transaction verification page 908, and finally the transaction confirmation page 910.
• user can also access the file transfer archive search page 912 and then a file transfer archive results page 914 and then download the selected file.
• user can next select process transactions page 916 and then from there the transaction verification page 918 and finally a transaction confirmation page 920.
• a user can also select transaction reversal/search page 922, a transaction reversal results page 924, transaction details page 926, a transaction reversal verification page 928, and finally a transaction reversal confirmation page 930.
• the user can select file transfer status monitor 932 and then download various files, including a CMLS license applications 934A, CMLS confirmation 934B, a CMLS approvals 934C, and CSR address 934D, a CMRS movement 934E, a CMRS resetting 934F, Citibank ACH 934G, a Citibank receipt 934H, a Chase ACH 9341, and finally a Chase receipt 934J.
• CMLS license applications 934A CMLS confirmation 934B
• CMLS approvals 934C CMLS approvals
• CSR address 934D a CMRS movement 934E
• a CMRS resetting 934F Citibank ACH 934G
• Citibank receipt 934H a Chase ACH 9341
• Chase receipt 934J a Chase receipt 934J
• a user can also be directed to a reports page 936, select a report, choose a report date range 938 and from there select among twelve different reports, including ACH errors 940A, ACH transfer breakdown 940B, rejection/return summary 940C, DTR/DBAR report 940D, credit card captures 940E, credit card rejections 940F, credit card errors 940G, account resets 940H, non-captured refund requests 9401, payment requests 940J, account disputes/disputes resolved reports 940K, and finally NOC's reports 940L.
• the user may download tab-delimited reports.
• FIG. 42 there is shown an ACH transaction reversal process flow 948.
• a user From the accounts receivable payment administration home page 950, a user will select transaction reversal, and be taken to a transaction search screen 952, a representative screen print of which is shown in FIG. 42A. The user will then enter the transaction number 954 and will submit it, enter a transaction search results list 956, a representative screen print of which is shown in FIG. 42B. If no transaction matches the search criteria 958, the user will be taken back to the transaction search screen 952.
• FIG.42C is a representative screen print of this screen. If the user submits this information, a transaction reversal verification screen 962 will be displayed, and is shown in FIG. 42D. Upon submitting the information, a confirmation screen 964 is displayed, and the user is taken back to the transaction search screen 952. If the user does not submit the transaction reversal screen information, a message indicating that a transaction has not been reversed will be displayed and will inform the user that they need to revise the DBAR for the process date with the reversal and resubmit to the USPS finance.
• FIG. 44 is a screen flow diagram thereof. From the accounts receivable home page 1000, a sample screen print of which is shown in FIG.45, a user can select the customer search 1002, process ACH transactions
• a user can select customer search screen 1002, conduct a search, and be directed to a search results page 1004, click on a customer hyperlink to be delivered to a customer details main page 1006.
• customer details main page the user can select postage transaction history 1008, or license details 1010 and then select account status history 1012, or Stamps.com e-mail history 1014, and then select Stamps.com e-mail details 1016, or finally select accounts statement history 1018.
• a user can select an account statement details page 1020, or a convenience fee waiver page 1022 and then a fee waiver confirmation 1024, or a convenience fee adjustment page 1026 and then receive a fee adjustment confirmation 1028.
• a user can be hyper linked to a process ACH transaction page 1030, then receive a transaction verification 1032 and then a transaction confirmation 1034.
• a user can select file transfer archive search 1036, conduct a search and receive file transfer archive results 1038, and then download the desired file.
• a user can from the accounts receivable home page 1000, select file transfer status monitor 1040, and then download a file, can see screen prints for Citibank ACH 1042 A, CitiBank receipts 1042B, Chase ACH 1042C, and Chase receipts 1042D.
• the user can select reports 1044, select a report and choose a report date range 1046 and receive nine different reports, including ACH errors 1048 A, ACH transfer breakdown 1048B, rejection/return summary 1048C, DTR/DBAR 1048D, credit card captures 1048E, credit card rejections 1048F, credit card errors 1048G, account resets 1048H, non-captured refund requests 10481, payment requests 1048 J, account disputes/disputes resolved reports 1048K, and NOC's 1048L.
• the user can then download a tab- delimited report.
• the screen prints for these various pages will be similar to those shown in the customer support home pages and/or the payment and administration home pages.
• the last module is the management screen flow 1101, the screen flow structure which is shown in FIG. 46.
• the last module in the postal system internet is shown in FIGS. 46 through 48, wherein FIG. 46 is a screen flow of the management module.
• manager home page 1100 a user can select and be hyper linked to a master reports menu 1102, a systems metrics menu
• FIG. 47 An exemplary screen print of the manager home page is shown in FIG. 47.
• a user can select report hyperlink and choose a report date range 1112 and display a report 1114, and then download a tab-delimited report.
• the file transfer archive search 11008 the file transfer archive results 1110 can be displayed and downloaded.
• the master reports menu can have a similar arrangement in appearance as the customer reports selection.
• FIG. 48 is a sample screen print of some of the systems matrix.
• the file transfer status monitor 1106 can have similar appearance as the meter administration file transfer status monitor and the file transfer archive search could have the similar appearance to the payment administration file archive search.
• the next main module of the On-line Postage System is a Meter Refund & Withdrawal
• This software module will be run within the Stamps.com Secure Postal Network on a client machine. It will allow a Meter Administrator (MA) to finish the withdrawal process initiated from either the client or Customer Support (CS). The withdrawal process can be initiated by a Customer Support Representative (CSR) or Meter Administrator through the Postal Intranet only if the customer cannot use their client software. This initiation will be done through an HTML interface.
• the Refund & Withdrawal application will withdraw the meter and print an indicium for the full remaining meter balance. It will generate and print a USPS Form 3601 -C form that will be sent to the USPS with the indicia for refund processing, along with a copy that will be retained and filed by Stamps.com.
• Stamps.com The Commerce Department at Stamps.com will implement additional physical security to control access to this application and the indicia printer.
• the Stamps.com R&D department will require password security and preferably additional security, such as SmartCard authentication to access this application.
• the Stamps.com Network Operations department (NetOps) may require biometric verification for access and this will be located in an enclosed and secure room.
• the functions of the Meter Refund & Withdrawal Processing Module comprise Reports, Print, User Interface, and Customer Support User Interface.
• the Reports displayed on screen include a Withdrawal Request Report and a Withdrawn Meters Report.
• Printing functions include PS Form 3601-C for USPS (which should be signed by a Meter Administrator and mailed to the USPS), a PS
• the User Interface includes a Run / Print Withdrawal Request Report and display, a Print Withdrawal Request Report, a Print PS Form 3601-C's, a Confirm proper printing on each individual PS Form 3601-C set, and a Run/Print Withdrawn Meters Report and display.
• the Customer Support UI will have a Customer Profile Display in HTML, and will have
• FIG. 49 is a "Surrender meter" screen print 1200.
• the additional information required to complete a PS Form 3601-C form should be gathered - most information already exists on Stamps.com servers.
• Client should prompt customer to fill out additional information required, including a mailing address if different from the one on their license - this will require a client UI. If Customer provides a new mailing address, their mailing address will not be changed on the Postal Servers, this address will be held only to generate the PS 3601 -C. Customer should enter a reason for Withdrawal from a pick list in this UI.
• stamps.com can ask for an additional internal reason in this dialog if necessary or if desired.
• Some possible reasons for surrendering can include: No use for software anymore; Too expensive; Difficulty connecting; Too much lost postage due to printing mistakes; No support for windowed or pre-addressed envelopes; Incompatibility with other software; Requires printing of address and postage indicia 'stamp' together; No longer have significant mail volumes; and/or Poor customer support.
• a "HELP" button 1202 to screen to link to Help file for more information on withdrawal.
• the surrender meter 1200 can also ask a second question in the dialog, namely, "What product/service will you now use for your postage needs?", and present the options: Regular stamps; Postage meter; Alternative Internet Postage product; or Other with box for text (not shown.)
• the Customer clicks the "Surrender” button 1204.
• a screen print of the Surrender Meter Confirmation 1206 is displayed. There is no default button - user should choose Yes or No -or- user should manually type 'Y-E-S' to choose yes. If the customer hits "No", it cancels the meter surrender. This does not save the reason for revocation or the mailing address. If the customer hits "Yes”, a dialog box Meter Refund Confirmation 1208 as shown in FIG. 51 is displayed. If the customer chooses "Yes", there is no way internally to stop the Withdrawal or the refund, regardless of when it is actually processed.
• the User has the option to export print logs at this time. If user declines export, print logs will be overwritten when client is re-started or uninstalled. Finally, the Client shuts down. At this point, the only option available is re-registration.
• the Meter Administrator runs a report of all Withdrawal/Refund Requests at a regular time decided by Network Operations. Reports can be displayed on screen before printing to see if any requests are pending. If no requests are pending, report does not have to be printed. Withdrawal Requests are date dependent. This report will find all meters in a "Withdrawal Requested" state, that have been in that state for 14 days or longer. Other periods can also be used. The USPS requires that Stamps.com wait 14 days for a transaction to clear before processing the refund. The Withdrawals Requested Report is printed. FIG. 52 is a exemplary screen print of a Withdrawal Request Report 1210.
• PS Form 3601-C PS Form 3601-C is printed with Refund Indicia as specified by USPS - address.
• One copy is for USPS and is signed by the Meter Administrator. As soon as this indicia is generated, the PSD is completely shut down and will not function.
• One copy is for Stamps.com and is printed with a watermark "COPY”. This copy is filed with the Withdrawal Report for the day. The UI will repeat for each request on the Withdrawal Report.
• the Meter Administrator should confirm accurate printing after each print set (both copies) of PS Form 3601-C. UI will ask if the forms are printed properly.
• the Meter Administrator can immediately reprint the form(s). All pending financial transactions should reach some finality before a meter is withdrawn. A pending financial transaction cannot be left unresolved; it should reach a state of Approved or Rejected.
• the software runs a check on each meter before it prints the 3601-C or the refund indicia. If there are any unresolved transactions, the PS 3601-C will not be printed. The user will be prompted with a simple dialog that states: "This meter cannot be withdrawn, transactions are pending.” The software will remember that the meter cannot be withdrawn and this will be noted in the Withdrawn Meters report.
• the print information is logged and can be re-created in the Transaction Server if a misprint occurs.
• the MA verifies that there were no printer errors, but does not check to see that the indicia reflect the correct values.
• the meter in the PSD is completely de-activated once the withdrawn state is assigned after the USPS receives the PS 3601-C form.
• stamps.com account is closed.
• the Stamps.com billing is stopped when the original withdrawal request was made, the meter balance is zeroed upon printing of indicia, the meter
• a Withdrawn Meters Report is run.
• a sample screen print of the Withdrawn Meters Report 1212 is shown in FIG. 53, and displays the meters withdrawn and amount, and the meters that could not be withdrawn due to pending and unresolved transactions.
• the Withdrawn Meters Report should be attached to copies of PS Form 3601-C and filed for reference.
• CS Customer Services
• CS receives a request from a customer for withdrawal.
• the only acceptable reasons are that software will not run or a server connection cannot be made.
• the customer should withdraw through client.
• CS verifies the customer's identity by looking up customer through normal CS HTML interface. Verifies based on customer information, such as SSN, Tax ID, EID or keyword. This verification information is the same as that used to verify a request for lost password recovery.
• CS launches the HTML Withdrawal user interface (UI.) This is launched from a hyperlink on the Customer Profile screen.
• UI HTML Withdrawal user interface
• CS records reason for withdrawal, and asks the customer if their mailing address is current (as displayed on Profile screen.) If No, CS records new mailing address.
• a sample screen print of the Withdrawal meter 1214 is shown in FIG. 54. Next, CS should get a Manager to continue processing. The Manager should supply
• CS UserName and Password to submit.
• CS should call manager over to their workstation.
• a CS Manager or Meter Administrator can have unrestricted access to the confirmation screen and can process without assistance.
• CS Manager or MA confirms withdrawal and amount, and clicks "OK to Withdraw” on the interface.
• the Meter Status is changed to "Withdrawal Requested" just as initiated through the client. If the information matches, CS gets confirmation, a sample screen print 1216 of which is shown in FIG. 55. If the information does not match, an error message 1218 is displayed, such as shown in Fig. 56, and the user is asked to try again.
• FIG.57 there is shown a Refund/Withdrawal Processing Flow Diagram 1220, that includes withdrawal initiated by either the client or through customer service.
• customer runs the withdrawal function in client 1224. If function runs correctly 1226, then the Meter Status 1228 is changed to "withdrawal requested" and an auto Email is sent notifying customer that their account is closed 1230.
• the Meter administrator runs and prints a Withdrawal Request Report 1232 and 1234.
• MA prints two copies of all PS 3601-C forms 1236 and 1238, and MA mails them to the USPS 1240.
• the MA then prints the Withdrawn Meters Report 1244 and 1246 and MA attaches them to the Withdrawn Meters report and files them 1248.
• the Meter Status 1250 is changed to "withdrawn", the Stamps.com account is closed, CMLS and CMRS are updated 1252, an auto Email Final Statement 1254 is sent to customer, and the process is finished 1242. If the customers call CS 1256 and the client software runs 1258, then CS instructs customer to initiate the withdrawal through the client 1260, in which case the process flow is directed to 1224. If the client software does not function properly, the CS captures the customer information and reasons for withdrawal through the CS withdrawal UI, and the process is directed to 1228, and continues until completed.
• the following scenarios are examples of Refund rules, Reports, PS Form 3601-C printing, refund UI, and Refund Operational procedures in two scenarios. In a first scenario, the Customer requests an ACH payment.
• Stamps.com resets meter with requested amount. Within 10 business days (or some other time period), customer requests a refund and withdrawal of meter. The ACH request has not necessarily cleared by then. Stamps.com generates PS Form 3601-C with refund indicia for full meter amount. The PS Form 3601 -C is mailed to USPS for processing, and the ACH request is returned for NSF.
• stamps.com In another scenario, the Customer requests an ACH payment. Stamps.com resets meter with requested amount. The ACH request is returned for NSF. The Customer requests a refund and withdrawal of meter. Stamps.com generates PS Form 3601-C with refund indicia for full meter amount, and a PS Form 3601-C is mailed to USPS for processing.
• FIG. 58 is a sample screen print of a Withdrawal Request Report 1234 and FIG. 59 is a sample screen print of a Withdrawal Meters Report 1246.
• the Withdrawal Meters Report 1246 shows both the meters actually withdrawn, and the meters that could not be withdrawn due to unresolved transactions. All reports can be displayed on screen, printed, and 'saved as' in standard tab delimited format. The specifications for form PS 3601-C are shown in FIG. 60.
• Refund Indicia the specifics are prescribed by the USPS.
• the format and byte length are the same as normal indicia.
• Indicia amount may not be greater than existing limit of $17,000.00, based on the Ascending register.
• delivery point and rate category fields are zeroed out, and the Indicia Version number is the first field in the barcode is one byte long.
• FIG. 61 is a table 1272 showing the values to be used for these fields.
• the Algorithm ID is the second field in the barcode and is also one byte long.
• FIG. 62 is a table that shows the values to be used for the fields. All other values for these fields are reserved for future use, to be determined by the Postal Service.
• the ascending and descending registers are both adjusted as normal, and the refund indicia print is the last action the PSD can make, and it cannot be reset.
• the refund indicia may or may not contain the Stamps.com logo.
• Unused Postage is postage indicia that has been printed correctly but the customer has chosen not to use. This is at the customer's discretion.
• the USPS may credit the customer for unused IBIP postage, but this process has not yet been defined. Stamps.com is assuming there will be no method in place by product launch to accommodate this type of refund.
• “Misprinted Postage” is postage that has been printed but which cannot be used for mailing purposes due to condition, placement or adhesion characteristics on the label or envelope for a particular mailpiece, and for which a "proof of condition exists. The USPS will not credit the customer in any way for misprinted postage.
• Proof of Condition is the physical example of invalid postage that has resulted in a debit to the customer's Stamps.com account for the above reasons, and which cannot be used for mailing purposes.
• "Reimbursement Postage” is a customer request for reimbursement of postage debited but not produced, and which cannot be substantiated by physical proof or evidence of a program failure. Postage that is not produced may be a result of user error, an error on the Stamps.com Postal servers, or an Internet connection error. The USPS will not credit the customer in any way for postage debited but not printed - there is no way to prove that nothing was printed.
• FIG. 63 shows the five places involved in the printing chain 1300 of events that can cause indicia to misprint or not print at all.
• Postal Server Network e-Meter, Servers, Routers
• Internet Connection 1304 the Customer's hardware and client software 1306, at the printer connection 1308, and at the printer 1310.
• True "Misprinted Postage”, as defined above, will most likely occur at the printer 1310. Any error in 1302, 1304, 1306 or 1308 would most likely result in a non-print, or "Reimbursement Postage”.
• stamps.com In the Stamps.com system, the e-Meter (cryptographic module) and Postal Server design will inherently prevent errant confirmation of indicia printing, so the errors that could be encountered on the server side are related to moving that indicia from the e-Meter to the internet connection (error type #2.) Hardware or software failure or overload could potentially prevent or alter this transmission. Any errors in creating and sending indicia out of the vault will be recorded in an internal server exception log. This is the only case where we Stamps.com can 100% verify errors, as it is highly regulated and tightly controlled. This is also the least likely place for a printing error to occur.
• the internet connection to the client could potentially be reset or dropped completely, due to telecommunications problems, line outages, bad routing, etc.
• stamps.com This is beyond Stamp.com's control, and errors may or may not be detected by the Postal Servers. Any error the servers do detect will be logged in the internal server exception report.
• the client Once the client has received indicia, it can be lost before transmission to the printer due to power failures, software/hardware failures, user error, etc. (error type #3.)
• stamps.com there is no way for Stamps.com to verify this type of error.
• the indicia When the indicia is transmitted to the printer, it may be lost due to user error (i.e. printer not connected or bad connection), power failure, hardware failure, LAN failure, etc. (error type #4.)
• stamps.com Currently, there is no way for Stamps.com to verify this type of error.
• Stamps.com is therefore not able to distinguish what might be a user error as opposed to a connection error or power outage. To limit losses, Stamps.com has a misprints policy. Misprints are generally not credited for unless the request meets certain criteria. For example, if a customer is printing over a certain dollar amount per month (for example, $300 or greater) and also is requesting a credit for a certain threshold amount (for example, $5.00 or greater), they would qualify for a misprints credit exception. A customer's account or meter could be directly credited, depending on the Misprints Policy.
• notification and statement of policy will preferably appear in the Client print dialogs and Help, the website and website FAQ. They might also appear in marketing materials and instruction collateral as necessary. Customers should be aware how a misprint will be treated if it occurs. Documentation and Help should also highlight the fact that the forced test print on a new printer is intended to provide some protection for customers from misprints, and can be done at any time to test printer settings.
• the customer call CS for a Spoils issue 1314 and the Customer informs the CSR that they had a misprint and would like a refund.
• the CSR flags the customer record as "Refund Requested" in the Customer Support software 1316, including the date and time of the request, and the type of misprints as defined by NetOps, and the CSR tries to qualify the reason for spoilage 1318. If Proof of Condition is not available 1342, then the CSR logs the call and informs the customer that they will be notified via e-mail of the resolution (e.g. within 24 hours) 1344.
• a daily report is preferably printed with all misprints requests from all customers.
• Customer Service accesses a non-real-time version of the server error log (a table in the database) and compares this log to the misprints report. This log will have to be manually printed at the end of the day, and contains all print errors.
• the log contains the Customer ID, Transaction ID, the print time and date, and the amount of postage 1346. If the Error is verified 1348, then the CSR updates the customer record to show "Refund Granted'"
• the CSR enters the credit through the Credit UI, with the amount and reason, and the credit made to the Stamps.com account/meter 1336.
• the CSR then sends a "Refund Granted" e-mail to the customer 1338.
• the Monthly statement reflects the credit applied towards the account meter 1340, and the process is finished 1332.
• Proof of Condition is not available 1320, the CSR logs the call and requests that the customer send in the Proof of Condition 1322. Faxing should not be an option, as there is no way to record misprints to ensure the same envelope is not resubmitted. The only way to ensure an envelope will not be resent is to get the original in-house. If the Misprint is received within the requested time (e.g.
• the process is directed to box 1334, and the process continues as described above. If, however, the misprint is not received within the requested time, the CSR will decide whether to grant a refund anyway 1326. If a decision is made not to grant a refund, the CSR updates the customer records to show "Refund Refused" 1328, the CSR sends a "Refund Refused” e-mail to the client 1330, and the process is finished 1332.
• the CSR decides to grant the refund even though no Misprint was received, the CSR updates the customer records to show "Refund Override" 1335, and then the process continues with the CSR entering the credit through the Credit UI, with the amount and reason, and the credit made to the Stamps.com account/meter 1336. The process continues until finished 1332. There are four options if misprints are verified: Credit Stamps.com service fees in the next billing cycle; Instantly credit the customer's meter; Manually issue a check for the amount; or Do not credit customer. If the CSR can verify the error, they will be able to update the customer record (in the CS software) to show the refund and the reason.
• a Master Credit UI 1360 is shown in FIG. 65
• a Convenience Fee Adjustment UI 1362 is shown in FIG. 66
• an Instant Adjustment UI 1364 is shown in FIG. 67.
• All screens can have limits on the amounts, based on user log-in or user group. In addition, different screens can have entirely restricted access based on login.
• Stamps.com account To user's meter
• One time instant debit or credit to a user's credit card or ACH account To the customer's next scheduled statement.
• the credit UI will preferably allow credits of no more than $10.75 (or some other desired amount) for Customer Support personnel and no more than $50 (or some other desired amount) for Managers.
• All reports are generated from the Offline Database.
• Customer Support Credits should be generated by date range, by CSR, and run separately for Instant Credit, Account Credit, or Meter Credit.
• a sample screen print of the Customer Support Credit 1366 is shown as FIG. 68.
• Customer credits can be shown by Customer and can be generated for a specific Date Range 1368, a sample screen print of which is shown as FIG. 69.
• Misprints requests and credits could be monitored through the Customer Support interface, or in the Offline database. Reports should be generated by time period: # Of requests for each type of reimbursement (misprints, unused, reimbursement); # Of misprints logged, Total $ credited (per time period); # Of misprints logged, Total $ credited (per individual meter); or # Of accounts closed due to policy (customer and business), etc. (customer support software report.) This information will be valuable in determining whether this policy is adequate in the long term, and whether Stamps.com needs to address this topic further with the USPS.
• FIG. 70 is a table 1370 which outlines the three approaches for misprints for the different types of errors. This completes the description of the Misprint Processing Modulel312 of the invention.
• the next major software application for On-line Postage System is the Quality Assurance (QA) Envelope Management system.
• the software will record the receipt of QA envelopes.
• This function can be an in-house function but can also be outsourced. To that effect, the application will generate a flat text log file (or simple MS-AccessTM file) that can be FTP'd or e-mailed to Stamps.com daily for upload into the postal system.
• the purpose of the QA Envelope Management system is as follows: To track QA envelope by meter #; indicate QA envelope has been received; indicate the quality of the envelope; and to create an easy-to-transfer log for simple upload into
• This software application would interface with the necessary 2D-barcode reader to read the indicia on a QA envelope.
• a user in any location could run this stand-alone application, scan stacks of mail (eventually using an automated scanner) to record the receipt of the item and attribute it to the correct user by user ID or Meter.
• the log would be sent daily from an unlimited number of locations to our servers and uploaded. This would not require real-time input into the system, and would allow outsourcing of the receipt and storage of this paperwork.
• An envelope that passes will only need to be scanned once. Passed envelopes will show an 'OK' message and a positive beep. If there is nothing wrong with the envelope, the next envelope can be scanned immediately.
• Envelopes that pass the indicia scan but have other flaws in printing can be associated with a Scan Code at the user's discretion. If the scanner is held for 5 seconds and cannot read an indicia, it will timeout and a 'Not Readable' message will be displayed with an audible buzz sound. All envelopes that fail QA will require 2 scans - one of the envelope and one of a standard list of 'Scan Codes'. This list of Scan Codes will be printed and labeled on a standard piece of paper and located on the scanning workstation for easy access (timeout after 5 seconds with scanner on.) The person scanning can evaluate the envelope for other signs of misprint that do not necessarily affect the indicia scan.
• damaged envelopes that do not scan will not necessarily suspend the account if there are different criteria assigned to this failure. If the software detects two scans of the Codes in a row, it will assume an envelope failed, and the user will be prompted to enter the meter # from the human readable part of the IBIP indicia for envelope identification. This will be the only keyboard activity required. All scans can be voided manually in case of error by hitting the 'Esc' key or 'Cancel Scan' button on the main screen. The application will ask for the scan again, depending on what it expects (either indicia or Code).
• FIG. 71 is a chart 1400 of codes representing various envelope states.
• the Q A Envelope Log will include data that is human-readable, tab-delimited text file (.txt) and will not be encrypted.
• Logs should be named with a unique date/time/user name and stored in a user-determined log file. The filename should be the same as or part of the unique serial # in the header information.
• FIG. 72 is a process flow of a Scan Screen Flow 1402. From a login screen 1401 (a screen print of which is shown in FIG. 73) a main screen 1404 can be accessed. From the main screen
• the user will scan the QA Envelope 1406, a screen print of which is shown in FIG. 74. If the envelope is software passed 1408, then an "OK" and an optionally sound message will be displayed 1410. At a decision tree 1412, if there is nothing wrong with the envelope, the user is taken back to the main screen 1404. If there is something wrong with the QA envelope can be associated with a scan code 1414, an OK message and sound 1416 will be given. By hitting an ESC key, the Code
• Scan will be canceled, and the user will be asked to scan new Status Code 1418. If the envelope is not software passed at 1408, then a "No Scan" message and an option unique sound will result 1420. By hitting the ESC key, the process will be canceled, and user will be directed to scan a new indicium 1422. The user can also manually enter information 1424.
• a sample input screen 1424 is shown in FIG. 75. That completes the discussion of the QA Envelope Management Module.
• the next major component of the On-Line Postage System is a Commerce Processing software system, the purpose of which is to summarize, report, and confirm daily payment requests to Citibank (or any other bank which Stamps.com interacts), CMRS, USPS Finance, and credit card processors securely with minimal user involvement.
• the software should also process credit card and ACH transactions by customer purchase and manage monthly invoicing. Finally, the software should provide an audit trail and a viewable history log for all such transactions.
• the Payment Processing process requires Meter Status and Payment Status conditions to be incorporated into the database. Each unique meter number has a Meter Status associated with it.
• Each Payment Request made by a user, either with ACH or credit card also has a Payment Status associated with it. Each Payment Request is considered unique, and each request will have its own status, independent of other requests. Note that each payment is associated with a meter, not a license.
• Each meter is affected by certain events listed in Table 1430 shown in FIG. 76.
• Each meter event is logged with an associated date. These events affect the "Access State" of the client. Access State is a concept rather than a hard coded state and describes the accessibility of the functions of the Client. The reasons for which a meter has been suspended are tracked. The meter number is included in all meter event logging. Reasons for administrative hold, such as invalid billing formation or email address, can be defined by operations.
• Each Payment Request has a status field and a date field associated with it.
• Each Payment Status change event has a date associated and may or may not have an additional Comment associated.
• the payment source should be a separate field rather than in the comment field so that it is preserved when the status changes.
• the sources are: Customer; Employee - Customer
• a next feature of the Commerce Processing System provides for Payment Processing. Purchases are not processed until the customer has been assigned a license. Customers should be able to initiate manual purchases through the client or through a Stamps.com agent. No matter how a purchase is initiated, once it is logged it follows the same process flow based on payment type (ACH or Credit Card). The payment request may be completed in the back-end payment processes.
• a Payment Processing Flow 1500 is shown in FIG. 78. To initiate a purchase 1502, a user logs the purchase and set a status request 1504. From there either an ACH payment request 1506 can be processed, or a credit card 1508 can be processed. Finally, there is back end payment processing 1510. Various features of the Payment Processing Flow are further described below.
• Payment Information is stored in a secure manner.
• the credit card information is encrypted before storing in the database.
• the last 5 digits of the card is stored in an unencrypted form for use by the client and Customer Support. Similar protection for the ACH ABA number and account number are also provided.
• the system will check for unpaid service fees and disputed postage balance for the account whenever the payment information is updated, and process them to collect the outstanding fees.
• the credit card billing address (AVS address) will be saved separately from the licensing physical and mailing addresses.
• the AVS address with each credit card transaction will be saved for later dispute transaction authentication, along with the name, card type, and expiration date.
• a new system variable called the ACH Delay Variable that represents the number of business days that should minimally pass from the time that an ACH payment is submitted until the meter can be reset with that amount is provided.
• the ACH Delay Variable is set to 0.
• a value of 0 indicates that meters are instantaneously reset after a purchase request is made and has passed
• the system should correctly handle all pending and submitted purchase requests whenever the ACH Delay Variable is changed.
• Two (2) business days after the time that a customer requests an ACH postage purchase the customer's meter will be credited with the amount purchased if no return or rejection has been received.
• the number of business days is a variable that can be changed although this may require bringing the system down. For example: A customer requests $200 of postage via ACH at 8PM on Monday night. At approximately 8PM on Wednesday night, the customer's meter value will be increased $200.
• the Payment Administrator can request and schedule a change in this variable from Network Operations. Changes to the Variable are performed offline, and any change to the ACH Delay Variable should pass QA before being released onto the live servers.
• a Reporting Schedule will provide that information is transferred to third parties according to a desired schedule.
• the software adds the date and time of the request.
• the client should offer the customer the chance to use the previously entered bank numbers on file on the server, otherwise, the customer can enter new ones. Display only the last 5 digits of the ABA number and account number plus the account name.
• the customer submits the completed request, check the validity of the information. Verify that the ABA Number and the account number are correct using the Thompson software. Prompt the customer to make corrections and resubmit.
• the customer initiates a purchase through the client and specifies credit card as the payment method. Provide the client with a list of accepted credit cards. The customer supplies name, credit card number, credit card type, expiration date, AVS address, and the purchase amount. The software adds the date and time of the request. The client should offer the customer the chance to use the previously entered credit card number on file on the server. Otherwise, the customer can enter a new one. Display only the last 5 digits of the credit card number plus the card type and expiration date. When the customer submits the completed request, check the validity of the information. Verify that the expiration date is greater than the current date.
• the Payment Administrator or a Customer Service Representative can add postage to a meter for a variety of financial and customer support issues.
• the source type, the actual person making the request, the reason code, the amount, the date and time are logged. Accept a transaction ID number for tracking the request and enter it in the purchase comment field.
• Initiate an ACH purchase request with the source account being the Stamps.com account, not the customer's account. Reset the meter immediately (as if ACH Delay Variable 0) because no credit risk from Stamps.com's account exists.
• Email Email the customer indicating that the meter was reset, the amount, the date and time.
• the Payment Administrator For immediate credit initiated by Customer Support or Payment Administrator, the Payment
• Administrator or a Customer Service Representative can issue an immediate credit to a customer's credit card.
• the source type, the actual person making the request, the reason code, the amount, the date and time are logged. Return a transaction ID number for tracking the request.
• ACH postage payment requests the following system is followed, and describes how money is transferred to the USPS from customers and Stamps.com using ACH. Meters should be eligible to have purchase requests processed (see the Client Access Status.) The appropriate reports are sent to the Payment Administrator, including online Payment Request Report.
• FIG. 81 depicts a simplified flowchart of ACH batch processing 1512.
• An eligible payment is defined as an ACH purchase request submitted after the last ACH processing batch. No payments are ever resubmitted for ACH processing, even if rejected or returned.
• Stamps.com account for the total amount of free postage reset into meters during that period (see Pricing Plans); Eligible Immediate Meter Credits: Include a payment from the Stamps.com account for the total amount of free postage reset into meters during that period for spoilage and other customer support reasons; and Combine the two previous amounts into one transaction.
• ACH Returns File and download returns file from Citibank twice per day, Monday-Friday only, and upload file to server for processing.
• change Payment Status for appropriate payments 1526 Change the Payment Status from Pending or Approved to Returned or Rejected as appropriate. Update the disputed amount if the payment was reset into the meter. Notify customer via email that payment was rejected or return.
• PaymentStatus Rejected or Returned since the last report .
• Customer Support should work with customer to resolve issues.
• Customer Support sees the transaction status via their interface. Notify customer of payment rejection or return via email and on next login.
• Stamps.com-only ACH Transactions Manually If ACH is restricted from customer use and is only to be used for Stamps.com paying for free postage, then the transmission process may be implemented manually.
• Stamps.com automated free postage, customer support credits, credit for unused postage put into the meter, etc.
• stamps.com Automatic free postage, customer support credits, credit for unused postage put into the meter, etc.
• files are ordinarily sent to Citibank, sum up the total amount of money owed to the USPS.
• the Payment Administrator will manually upload the file to Citibank. Archive the file. A report should be available via the offline database to allow the Payment Administrator to view the transactions that made up the total calculated in #2. Mark the transactions as having been sent as per the automated ACH processes. Provide a means for the Payment Administrator to decrypt the file and to set passwords, etc. Include the total from #2 in the ACH transfer line item of the DBAR. Use the following process to update the Citibank passwords. Maintain the Citibank passwords locally on the server. Initiate a password file Email to the Payment Administrator every 4 weeks. Payment Administrator manually transmits the password file to Citibank. Payment Administrator sends a "password confirmed" request to the ACH service causing the password to be updated after manually confirming that the password file was received by
• the payment capture is described in a following section with reference to FIG. 83 credit card processing 1540.
• the first step is to authorize the purchase 1542.
• the Client displays the valid credit card types according to an ordered list sent by the server. Send the customer name, credit card number, expiration date, and billing address to FDMS. Use a Stamps.com merchant ID if acting as merchant for postage purchases and for service fee billing. Use USPS merchant ID if acting as agent for postage purchases. Queue all purchase requests for later processing if the credit card processor is down, and do not reset the meters. Client should inform user that approval is pending after timing out. Save the AVS address along with the transaction for dispute analysis. Next, process AVS return file 1544.
• PaymentStatus Approved if transaction Response Code is Approval and AVS Response Code is A or A* per the AVS Response Code.
• reset meter 1550 Apply credit to meter if amount authorized and captured. If a meter has a disputed value, apply all funds to the disputed amount first. Then, reset the remaining amount, if any. Notify customers of meter reset, method, amount, date and time via email. Notify customers of payment rejections via email.
• FIG. 84 is a logic flow diagram showing Back-end Processing 1560.
• ACH payment results are processed as described above 1562. Additionally, all authorized credit card purchases are captured 1564.
• Stamps.com acts as a merchant these previously authorized purchases should first be captured (at the time of authorization or through a delayed batch process), transferring the money from the customers to Stamps.com's merchant bank account. This operation is described in previous sections pertaining to credit card operations.
• send the Merchant Transfer Breakdown Report 1566 When Stamps.com acts as a merchant, all funds captured from previously authorized postage purchases bought using credit cards should be transferred from Stamps.com's merchant bank account to the USPS's Citibank account using a wire transfer. Until this process is automated, the Payment Administrator initiates this process manually by transferring one lump sum wire transfer to the USPS.. Send Payment Administrator the Merchant Transfer Breakdown Report, notifying the
• CMRS 1568 Coordinate transmissions to CMRS, Citibank, and USPS Treasury (DTR DBAR) to reference the same set of data over the same time period.
• Create the 2 CMRS files (movement and reset.) Give all the files the same date, time, and cycle number. Preferably use Pacific Time as the time zone for all time-based fields (but any consistent time zone is acceptable.)
• Use a configuration parameter that defines the number of years ahead the inspection due date is from the installation date. Set the inspection period parameter to two years initially.
• CMRS using Expedite Manager Retry calls and log failures. Notify the Payment Administrator if unable to send the files.
• TIME are the date and time of submission to CMRS. Archive Movement file under the name CMRS.MOVE.DATE.TIME. Archive Address file under the name CMRS.ADDR.DATE.TIME. Fifth, create and distribute Meter Reset reports 1570. Send Meter Reset and CMRS Report to Payment Administrator. Sixth, Send DTR/DBAR to USPS 1572. Fax DBAR to USPS. Notify Payment Administrator that DTR/DBAR is ready to be printed and faxed if DTR/DBAR should be faxed manually. Lastly, calculate partner information 1574. This involves collecting appropriate information to allow the following calculations to be performed on an offline version of the database: Calculate amount due to partners from postage printing. Total amount printed by all customers with the same OEM code.
• Pricing plans can be stored in a table.
• FIG. 85 is a such a table 1576.
• the Commerce Director should be able to make changes to any pricing plan. Sufficient operational controls should be enacted to ensure management signof and Quality Assurance verification of any pricing plan changes or email template changes. Simple changes to the contents of a row may be implemented after sufficient Quality Assurance verification. Implementing new pricing plans (columns) may require new software development. Any changes to a plan that are in customers' favor may be changed in that plan description. Any changes to a plan that are not in customers' favor should be entered as a new pricing plan to allow the original plan to be used for existing customers on that plan.
• FIG. 86 is a Pricing Plan Selection Process Flow 1580.
• a customer selects a pricing plan 1582 and selects a payment method 1584.
• the customer then either enters ACH information 1586 or the customer enter credit card information 1588. If the customer enters ACH information, software validates the entry 1590. If the entry is incorrect, the user is asked to re-enter the ACH information. If the ACH or credit card information is correct add a selected subscription order 1592.
• decision tree 1596 a determination is made to see if the authorization and capture was successful 1596. If not, the user is asked to re-enter the credit card information 1588. If the authorization and capture is successful, the user selects a pricing plan 1598. If free postage is offered, then the free postage is added to the meter 1602, and the customer receives thank you for signing up message E-mail 1600. If no free postage is added, the customer simply receives the thank you for signing up message E-mail 1600.
• the Business Plan Selection can offer the following features: Allow customer to pay by ACH, Visa, MasterCard; Customer enters financial information; Do not charge customer for service fee at sign-up; Require customer to purchase postage to continue; Set minimum postage purchase requirement to $10 (as an example); Use the same financial information to pay for service fees and postage purchases; Deposit $25 Free Postage into customer's postage meter; and Allow only 1 Free Postage Promotion per customer, e.g. customers who switch plans do not get a second free starter kit and the free postage.
• the Consumer Plan Selection offers the following features: Allow customer to pay by ACH, Visa, MasterCard.
• the Business Plan can offer the following features: Do not charge customer a reset fee on postage purchased; Require a $10 minimum for postage purchases, $500 maximum; Allow customer to make an unlimited number of purchases, subject to the previous limitations; Notify customer in the client to correct financial information if a customer purchases postage (via credit card) and authorization fails; If a customer attempts to purchase postage via ACH and authorization fails later, customer will be sent email notifying customer that submitted financial information has been rejected and access will only be available to the undisputed amount in the meter; and If a customer attempts to purchase postage via credit card or ACH and the transaction cannot be completed in a timely manner, inform the customer that an email will arrive and display purchase approval (or lack thereof).
• the Customer Plan offers the following features: Do not charge customer a reset fee on postage purchased; Require a $10 minimum for postage purchases, $500 maximum; Allow customer to make an unlimited number of purchases, subject to the previous limitations; Notify customer in the client to correct financial information if a customer purchases postage (via credit card) and authorization fails; If a customer attempts to purchase postage via ACH and authorization fails later, customer will be sent email notifying him that his financial information has been rejected and access will only be available to the undisputed amount in the meter; and, If a customer attempts to purchase postage via credit card or ACH and the transaction cannot be completed in a timely manner, inform the customer that an email will arrive and display purchase approval (or lack thereof.)
• the Pricing Plans and monthly billing therefore have the following features, which differ slightly depending on the plan type.
• the features include: Begin a customer's billing cycle on the day of registration if the customer registers on the 1 st - 28th of the month; If a customer signs up on the 29th, 30th, or 31 st, move the customer's billing date to the 1 st, 2nd, or 3rd, respectively; Ensure that the first monthly billing cycle for these days begins in the following month, not after 2-3 days; Charge customers 10% of postage used/printed for the month with a $3.99 minimum and $29.99 maximum charge; Email the customer on the day of the billing an email statement outlining postage use and calculation of service fee; and Suspend access to printing temporarily if service fee payment is rejected.
• the features are as follows: Begin a customer's billing cycle on the day of registration if the customer registers on the 1 st - 28th of the month; If a customer signs up on the 29th, 30th, or 31st, move the customer's billing date to the 1 st, 2nd, or 3rd, respectively; Ensure that the first monthly billing cycle for these days begins in the following month, not after 2-3 days; Charge customers $1.99 per month for up to $25 of postage used/printed per month; Charge customers 15% of postage used/printed above $25 with a $29.99 maximum charge; Email the customer on the day of the billing an email statement outlining postage use and calculation of service fee; and Suspend access to printing temporarily if service fee payment is rejected.
• the Prepay Option for Consumer Plan are as follows: Offer those customers on the
• Stamps.com should have the option to switch customers between plans. There is accordingly a provision provided for switching between pricing plans. In general, customers should be switched to a new billing plan only after the next billing so only full months of postage use are billed. No prorating is required. Use only the last plan chosen during a billing cycle if the plan was switched multiple times.
• the Customer may also wish to switches plans. If so, the customer should be warned of the implications of switching plans, particularly for forgoing the fees from the Prepaid Option to the Consumer Plan. If the customer switches, mark account to switch plans the next time the bill is calculated, and send customer email alerting him or her of the way switching is handled and welcoming him or her to the new plan.
• FIG. 87 is a process flow for meter surrender and pricing plans 1610.
• a customer quits the business or consumer plan 1612.
• Send customer an email asking customer to call Customer Support if authorization fails. Do not process a withdrawal request until all its outstanding transactions have cleared.
• the software calculates the monthly bill using standard pricing plan equation 1614.
• the postage print fee is captured 1616, and lastly, a "Thanks for trying us" type of E-mail is sent to customer 1618.
• the monthly billing process for Business Plan customer preferably involves submitted bills to customers every month via email. Bill customers regardless of whether the meter or license is suspended or the meter is dormant.
• the Email Infrastructure does not need to be secured for monthly billing. Customer Support should be able to view current and past billing statements. Customer Support also requires the ability to add entries to the monthly bill to provide credits or debits to customers' accounts. The system should log the entry, including the account number, the reason code, the amount, and the date and time.
• Customer Support requires the ability to give free months of service to customers and there should be maintained a field for each customer that contains the number of free months remaining.
• log the entry of the free months including the number of free months provided, the customer service representative making the entry, and the date and time. Do not bill the customer if the field is greater than 0. Decrement the field value after that customer gets the current month free on the current billing cycle.
• Writing checks to customers processes all "ACH reversals". Process credit card reversals normally. When a credit or debit is made, log the amount, the employee making the change, the reason, and the account changed. Email the customer with the information about this change.
• FIG. 88 is a monthly billing process flow 1620.
• the step of calculating the monthly bill for all accounts 1622 has the following features: Level-load the billing process equally over each month; Process the monthly billing on the registration anniversary of each customer; Do not assign customers an anniversary day to ensure that billing is level loaded.
• the statement should include: greeting; customer name; customer ID number; total postage printed; total service fee; list of credits and debits; total charge; pricing plan summary; advertising space; and Prepayment Option for Consumer Plan should also include number of remaining months of prepaid basic fee left.
• E-mail to the customer in step 1630 bounces, re-send every day for up to 5 days.
• Log all failures Have client display message to customer indicating the failure.
• a last step in the monthly billing process involves processing ACH Reversals. Send report to Payment Administrator containing list of needed ACH reversals. These will be processed by writing checks to each customer.
• a second bank to accept ACH Service Fees for Stamps.com can be used, except that a different phone number will be dialed, different passwords will be used, and different potential file header formats will be needed.
• Separate internal ACH reports should be sent for each bank. For example, if Chase Manhattan is acting as the service fee ACH processor, the following protocol should be observed. Sends Transaction Journal as acknowledgment of ACH request file, listing settlement dates, total debits, total credits, and processing system (Fed, etc.) Can be retrieved 2 hours after ACH request file is sent. Empty files should not be sent.
• Stamps.com can safely retransmit the same file, unlike with Citibank. Supports ACH reversals using NACHA format
• This ACH Password covers transfers to and transfers from Citibank for ACH transactions. While the bank Citibank is used to process ACH transactions, obviously other financial institutions can be used. Two password files are required each for NOC files, ACH rejection files, and transfer request files. One file covers the account from which Stamps.com receives files. The other covers the account to which Stamps.com transmits files. The ACH Password may need to be updated. One way to do this is to randomly generate a password preferably based on the rules below and send it to Citibank. Change the password each month.
• the password conforms to Citibank requirements, namely, that:
• the password is 7 characters; Alphanumeric; No repeating characters; No obscenities; No days of the week or months of the year; No ascending or descending characters or numerals, e.g., no 123, 321, abc, cba, etc.; Changed from the previous 5 passwords; Different first four characters of previous 5 passwords; Different first four characters from the username; Different first four characters from the name Stamps.com, i.e., STAM; and Cannot contain restricted words.
• Send two files containing the password to Citibank Include the account name, the old password, and the new password. Send the files using the standard transfer protocols.
• Stamps.com should resolve the dispute as quickly as possible. If appropriate, refunds should be made in a timely manner either directly into the customer's account or through a credit on a credit card. Legitimate charges should be collected promptly. A collections agency may need to be employed for customers who do not submit payment in a timely manner, however if and how this will be implemented is still to be determined.
• FIG. 89 shows a process flow for a disputed charge process 1640. First, a notification of dispute is received 1642. This can be a fax received from the USPS or the Stamps.com merchant bank stating that a charge is being disputed. Forward all faxes immediately to the Payment Administrator for processing. Next, forward Payment Authorization report to FDMS and USPS 1644.
• the report is sent via fax (TBD) to FDMS and USPS for resolution.
• the report contains: customer name; customer ID#; transaction amount; date; address used for AVS; authentication number (if available.)
• Payment Administrator uses an interface to set the disputed amount for meters associated with disputed postage payments. Payment Administrator uses an interface to suspend the meters associated with disputed service fee payments. Suspension of printing privileges is also appropriate when both postage and service fees are in dispute. Lastly, create report for Collections 1652.
• Stamps.com should process refunds in a timely manner but in such a way that funds are only credited to customers once the refund has been verified.
• Printer jams, etc. are considered spoils and are dealt with separately.
• Envelopes with incorrect addresses, etc. are considered unused postage and are dealt with separately as well.
• consistent time zone should be used. The system will be able to correctly handle the situation in which the client and server are in different time zones.
• the system should correctly handle situations in which the client and server change to daylight savings time at different times of day, different days, or not at all. Potentially, this can happen in the middle of any transaction with the client.
• a language field indicating the preferred language of the customer. Send all e- mails to the customer in that language. This may be pre-populated with US English until needed.
• the following areas should also be encapsulated or otherwise isolated to ease internationalization: Currency; Numeric format (commas and periods); Dates, including the calendar used; Sorting; Telephone number formatting; Address formatting; Billing Administrator Interface
• the e-commerce system requires a numbering system to track each item that is processed through it.
• SHU's stock-keeping units
• SHU's appear as the line items on the email statement e-mailed monthly to customers if applicable. All e-commerce transactions, from free postage and signing up for a monthly billing plan to customer support direct meter credits and monthly billing line items (both debit and credit), are assigned SHU's.
• reports are archived for at least 3 months online and offline thereafter.
• reports include Payment Requests Reports (which can cover daily payment requests made since the last payment processing), NOC Report, ACH Payments Rejected/Returned Reports, Credit Card Payments Rejected/Returned Reports, Meter Resets Reports, an ACH Transfer Breakdown Report (which allows the Payment Administrator to audit the lump sum payments transferred to the USPS account via ACH), an ACH Reversals Report, and a ACH and Credit Card Payment Rej ected/Returned Report (for Service Fees) report.
• FIG. 90 is a sample DTR/DBAR Fax to the USPS 1660
• FIG. 91 is a sample form for Detail of Reconciling Items on the DBAR 1670
• FIG. 92 is a table 1672 of definitions for the DTR/DBAR Fax to the USPS of FIG. 90.
• Payment Administrator is able to use the interface in the following ways: Adjust ACH Delay Variable; Adjust time of day Citibank files are processed; Change email template ID numbers used for all email template; Obtain disputed charge payment documentation; Enter Payment rejections; Suspend or Hold a customer account; Set the disputed amount for meters associated with disputed postage payments; Suspend the meters associated with disputed service fee payments; Directly credit a meter; and Directly credit or debit a credit card.
• the Payment Administrator is able to: Lookup the customer record by the meter number listed on the Citibank fax; and Change the transaction status to Rejected or Returned.
• FIG. 93 is a sample interface screen print of the Payment Administrator 1680.
• Customer Support is able to use the interface to: Add additional entries, debits or credits, to a customer's bill; Directly credit a meter; and Directly credit or debit a credit card.
• the Meter Administrator is able to use the interface to change the default maximum meter balance on an account-by-account basis.
• the client handles the following summary of features explained elsewhere in this document: Handle new client access states; Handle pricing plan selection and switching; Enforce maximum and minimum postage purchase requirements; The client should offer the customer the chance to use the previously entered credit card or ACH information on file on the server, otherwise, the customer can enter a new one. Display only the last 5 digits of the credit card number along with the card type and expiration date; Implement new meter surrender procedure; Send messages to the client on log in, such as notify the client on login that the email address cannot be reached and to call Customer Support; Send info on advertising art printed to server; Inform user that purchase approval is pending after timing out; and Handle different daylight savings time changes and time zones from server. In additional other features may also be handled.
• Email templates are not deleted from the system. They are kept so that with transaction and other information, an email to a customer can be recreated.
• Each email template is assigned an ID number. These ID numbers are then associated with different e-mails that the system sends out.
• the Payment Administrator can change the email template ID number associated with each outgoing email type. Operational processes to assure management signoff and QA verification are beyond the scope of this specification.
• Email the Payment Administrator with a simple message that the daily Citibank, CMLS, and CMRS processing has been fully transacted; Email Payment Administrator if 1 hour passes without successful credit card capture; Email the Payment Administrator if unable to send the CMRS files; Email Payment Administrator that DTR/DBAR is ready to be printed and faxed if DTR DBAR should be faxed manually; Email Payment Administrator and Customer Support if the email statement cannot be delivered after 5 days (Customer name, ID number, statement date, phone number, and email address); Email the Payment
• Another, miscellaneous requirement is to log customers' IP address at every log in to the system.
• the Commerce Processing System of the invention has additional features.
• a user can initiate a Purchase through Auto-Refill.
• the customer In order to configure auto-refill for the first time, if the customer does not have auto-refill set, they are shown an interface 1682 (a sample of which is shown in FIG. 94) when their account is at or below the minimum reset amount for their pricing plan.
• the customer should set an auto-refill level through the client that allows them to specify the "empty" level (the amount which triggers the refill), the refill amount, and the account that pays for the refill.
• the customer should not be able to specify an amount below the minimum specified in their pricing plan.
• the customer Before the payment is submitted, the customer should see a message that reminds them that exceeding their maximum number of meter resets per month will result in a meter reset charge.
• the customer should be given the option to change the amount or submit the current amount.
• the client In order to trigger an auto-refill purchase, each time the customer prints postage, the client should check to see if the meter is at or below auto-refill minimum. If it is, the client should initiate a purchase request. The purchase request should be logged and processed as if it was manually initiated by the customer. Add a field to the purchase log to indicate if the purchase was manually initiated or auto-refill initiated. Send an email to the customer stating that the meter has been automatically reset via the auto-refill function. State the amount of the reset, the method (credit card, ACH), the new total amount in the meter immediately after the reset, and the number of free resets remaining this month.
• Purchases may be initiated by Telemarketing or Customer Support.
• customers call Stamps.com Telemarketing or Customer Support.
• the client can view the new payment information on the next login.
• ACH Purchase Velocity Controls there can be ACH Purchase Velocity Controls in place. These controls allow only a (configurable) maximum amount of postage payment requests to be processed over a (Payment Administrator) configurable period. The client should inform user that they have exceeded the velocity limit and disallow further requests. This feature prevents a customer from requesting unlimited ACH payments and printing the entire value multiple times in a 48-hour period until we catch them (slows ACH velocity.) There can be added a personal velocity override that can override the limits imposed above. There can be an Online Postage Purchase Audit which compares the amount of ACH and credit card purchases versus amount reset in meters, taking into account rejections and returns and disputed amounts. A report is then sent to Payment Administrator and Risk Manager.
• the server should automatically capture all authorized purchases at a set time every day. This system should capture all approved purchases. This involves calling the merchant bank, transmitting a list of all authorized credit card transactions since last captures, retrying the merchant bank until capture completes, and notifying Payment Administrator if 1 hour passes without successful capture. The system should update payment status to captured for every previously authorized purchase that is successfully captured. Third, the system should handle rejected capture requests. Send report of all previously authorized purchases that are not successfully captured to the Payment Administrator, and send email to customer notifying them of payment problem.
• Prepaid Plan Expiration Notification There can be a Prepaid Plan Expiration Notification, wherein the customer is e-mailed 45 days before the expiration of the prepaid plan year.
• the customers' plans can be extended by 12 months when they pay for another year.
• the Client should support purchasing additional plan years when authorized
• the VP of Operations and VP of Marketing (and others) will be notified after a pricing change.
• the Billing Administrator should be able to use the interface to change the Pricing Plan table or change the billing statement format.
• stamps.com for convenience sake.
• references to particular banks and financial institutions e.g. Citibank and Chase Manhattan
• references to particular banks and financial institutions are not intended to be limitation to the bank or financial institution used for various functions.
• References herein to the USPS are by way of example, and as other nations' s postal authorities implement IBIP types of programs, the above described system can be put into place in foreign postal j urisdictions.
• the system and method of the invention can be implemented on a system- wide basis, or certain components and elements of the described system can be implemented, as desired. All in all, the system and method of the invention allows many critical functions of an on-line postage system to be automated, not only to save costs, but to improve service and profitability.

Landscapes

• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Devices For Checking Fares Or Tickets At Control Points (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Applications Claiming Priority (13)

Publications (1)

Family

ID=27558425

Family Applications (1)

Country Status (3)

Families Citing this family (5)

Family Cites Families (10)

• 2000
  • 2000-10-18 EP EP00984553A patent/EP1226554A1/de not_active Ceased
  • 2000-10-18 WO PCT/US2000/041291 patent/WO2001045051A1/en active Application Filing
  • 2000-10-19 AU AU21155/01A patent/AU2115501A/en not_active Abandoned

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events