Supplement to the United States of America Pending Patent Application Number 09/113,344, Group Art Unit 2751 Preliminary Class: 711
© Copyright: Ben Livson 1999. All rights reserved. Confidential.
Version 12, October 1999.
TOC \o "1-2" \h \z
The 1st page will be printed with the following message header information:
· Date-time originally sent by A-party and date-time entered into postal stream
· Public sender details by default are title, first name, optional middle initial or name, postal address, telephone, faxes and email contact details if available and not suppressed by subscriber. Automatically obtained from subscriber profile and can be set per message within a web session.
· Receiver details including a postal-address that has to translate to a valid DPID
· List of attachment file names, number of pages printed and document type
See Pitney Bowes DirectNET http://www.directnet.pb.com/main/tr_dov_home.htm as and example of postal message workflow, mail list handling and mail document templates.
The subscriber will be able to set her preferences for the following with defaults highlighted in bold:
Parameters to control cost:
· User-Id Y/N selected by user but uniqueness enforced
· Customer-Id Y/N parent billing account id for user-id is system generated
· First Name Y/N
· Middle initial or name: Y/N optional
· Last name Y/N
· Or Business Name Y/N for business customers
· Australian Company Number Y/N when available
· Alternative Business License Y/N for businesses without A.C.N
· Unit name within Business Y/N optional for business accounts
· Belongs to Group name Y/N optional for business accounts
· Postal return address Y/N
· DPID Y/N
· Email Address Y/N optional
· Phone Number Y/N optional
· Alternative Phone Number Y/N optional
· Facsimile Number Y/N optional
· Message authentication method Y/N
· User-Id attributes u1, u2 to u10 Y/N optional users specify display names and allowable values
· Customer-Id attr. C1, c2 to c10 Y/N optional customer admin specifies display names and allowable values
· B-party messaging preference Y/N shows none set or top-to-bottom receive preferences. If set, then chargeable service for conversions.
Archive asp means deletion on confirmed delivery plus a service policy specified cool-off period (1 month). Keep messages with delivery under dispute. Messages with delivery failure notified are kept 1 month for re-submission.
All valued added messages sent are stored for the retention period in the subscription service web-mail / e-mail account and can be viewed or resubmitted or forwarded as new messages, of course attracting fees. Excess retention is chargeable. Retrieval from archive is chargeable.
A message inherits customer profile preferences for all attributes not re-specified by the customer for the message.
Message is sent only if customer account (or scratch cash) has cover or within credit limits.
A postal message is never sent within Australia unless the postal address translates to a valid unique DPID unless a customer overrides DPID enforcement in which case @post assumes no other responsibility except that the message has been onto postal fulfilment. Messages without a valid DPID will not be accepted for postal delivery receipting and will not be part of @post notary services.
@Post endeavors to handle postal address validation for major overseas postal services under IDP, in particular the U.S. zip 5+4 and the future zip-11 validation.
Subscriber is prompted for send confirmation in a web-session if a message has any non-fatal errors such as invalid addresses in a mailing list. The prompt will be whether to send the valid ones or not.
Messages sent ‘blind’ say by email to mailing lists, will be processed and sent to valid addresses but only if the number of errors is below system and user set limits.
All types of messaging supported by @post can be addressed from a distribution list including postal, email, fax, voicemail and so on. Multiple message types may contact the same entity.
Distribution lists can be uploaded using the web administration interface from customer databases in MS Excel and Access, csv-file and fixed format flat files. Also, support import of address-books and distribution lists from major email systems and clients such as MS Outlook.
The syntax shall be receiver-info followed by address. Each entry has to be a separate record/ or line. The parsing starts from right-to-left to identify message type. If an Australian postal address, it has to translate into a unique valid DPID. For overseas postal addresses and for other address types, @post validation capabilities will be gradually implemented.
Customers will be offered distribution list templates to minimise rejects.
Each creation or update of a distribution list creates a valid address file stored for use and a reject list. Reject corrections can be added in bulk. Similarly, addresses can be deleted in bulk. A web-interface will enable interactive add/change/delete.
New addresses can be automatically or via prompt added from messages sent into address books or distribution lists nominated.
The following rules will be observed for envelope printing:
New distribution lists are accepted for message sends if percent of address rejects is less than the maximum percentage of rejects allowed. Existing distribution lists are pre-approved and not submitted for re-validation unless so requested by customer.
Provide List Server functionality for distribution list member to unsubscribe by sending an email or by free call or fax at customer’s expense or prepaid return mail. @Post will not allow unsolicited bulk mail by direct mail advertisers. Recipients under the @post Privacy Protection List service will be removed.
Customers can request by e-mail usage and billing information by send a blank message to account-id.bill@post the reply being always emailed to the email address in the customer profile. Group accounts have a single master account-id eligible to request group wide information.
Bill presentment is always emailed when a periodic or on demand invoice is generated. Similarly, bill presentment including usage and cost since last bill is available via the web administration logon. Bill presentment starts with summary information for the current period and for the last n-invoices. Each invoice then itemized at message-id level. Each message-id is a hyperlink to detailed per message information.
Group accounts breakdown is at Group Level, User Level and Message Level. Groups within groups can be supported via the web-query interface to the subscriber directory information. Customer administrator can set the attribute Belongs to Group Account to reflect organizational hierarchy. Similarly, any other combination of customer profile attributes can be queried for usage and billing information. In particular, customers can extend the schema by setting user attributes 1,2 and 3.
Billing and usage information is available for export in csv-file and Excel formats for customers to create their own reporting to go beyond @post reporting and graphical presentation capabilities.
@Post support for message tracking functions follows.
Message tracking is by message-id with result available by web pull or pushed by email to the sender’s email address in response to email queries addressed to message-id.status@post.
Status of messages paid anonymously by scratch stamps require both message-id and the id of the 1st scratch cash stamp used for payment
Message statuses include:
The @post web portal provides the following functions:
The portal needs a unified messaging centre capable of sending and receiving all types of messaging including postal messaging.
Support business-to-business with @post being the hub, facilitator and notary for transactions.
Portal attraction includes directory services, calendaring & scheduling etc. free services to support and attract wealthy consumers, SOHOs and SMEs.
@Post provides a number of robotized email services for its customers:
Responses actions include status, cost, trace and stop in-transit (if possible). Responses to queries and commands relating to specific users or specific message-ids are always emailed back to the email address listed in the customer regardless of the originating from e-mail address.
Enable search of @post web site including knowledge bases for information according to the keywords.
Privacy protection is a list service to the public for a small annual fee that ensures @post is not used to send any message of a type(s) not desired. Public joins the Privacy Protection List via @post web-interface for payment and maintenance of preferences including filtering conditions such as not receiving messages not exclusively addressed or other specific exclusions. This is in addition to the public anti-spam lists. Any mailer may subscribe to the Privacy Protection List to prune mailing lists from people and companies subscribing to the privacy protection service. Such mailers are entitled to use the @post privacy protection logo.
Responds back about any known service difficulties and bottlenecks in processing
An alternative @post web site hosted outside external to @post without any dependencies on @post will be maintained to provide information about @post status and service difficulties and resumption.
Message header, body and attachments converted into a pdf (or postscript) spool file for postal fulfillment.
Provide sender and receiver DPID information when obtainable from address analysis and translation.
Parameters to control print fulfilment include (colour, print resolution, 1 or 2-sided, paper size and type, envelope type), postal class and optional postal delivery receipt.
Multimedia fulfilment is as above but on media such as CD ROM. Message header will be printed as well as written into the CD ROM. A courier service jiffy bag, delivery and receipt information is prepared. Courier service web-tracking message-id is emailed to the sender and to receiver if the receiver’s email address is provided.
Messages to distribution lists are logically spooled into a mailbag with individual messages. The spool file and control parameters, if possible, are transmitted only once. The to and from blocks are preferably collated into a single address file. This has to be worked out with the postal fulfilment service provider.
Functionality such as generating cover letters from the distribution list and modifying content according to some filtering criteria embedded as additional attributes in a distribution list is possible (currently supported by EDIPost/IDP fulfilment).
A protocol for postal fulfilment notification for completing defined stages in the postal service fulfilment; querying and reporting of status and position in fulfilment queue are required.
@Post has a 2-layer firewall service with all chargeable services firewall protected. Alarming and monitoring, rating and billing, @post mail switch and administration system are all behind a second firewall.
Secure MIME is enforced for customers choosing X.509 authentication. In particular, @post will not accept any value added message for send unless encrypted and, of course, will not send any email back unless encrypted with the customer’s public key.
Message authentication types range from the weakest = email address to the strongest = X.509 certificate + fixed IP address + email address.
A-party controls whether the authentication method is included in the message header information.
@Post is audited for auscert, e-trust and web-trust compliance.
@Post privacy statement and security policy will be public and comply with e-trust.
@Post postal messaging has to comply with postal services security policy
Procedures for dealing with law enforcement and security bodies are mandatory.
Procedures for supporting customers against false authentication and non-delivery claims are mandatory but carry fees. Procedures for @post trusted party notary services and insurance claims are mandatory, re: G5 compliance.
Reference-Id is the identifier of the incoming message sent to @post. The inbound message may have bee by any means supported by @post whether incoming email, web request, fax, voicemail or IVR, SMS, EDIFACT or EDI/XML or an inbound postal message. An incoming message even if rejected is allocated a reference-id. A reference-id is always associated with at least one message-id even is a null message for rejects. A single reference-id of an inbound message sent to a distribution may generate a very number of message-ids across all the message types that @post can generate. The Reference entity has reference-id as its primary key, originator from address information, where obtainable, and attributes to store or point to the inbound message header, body and attachments. Inbound messages must be stored for the minimum retention period required by the billing contestability and longer when requested by customer. The Inbound-to-Outbound messaging entity is the master-detail table with reference-id as its primary key and foreign key references to all the message-ids, outbound messages generated, e.g. from the to, cc, bcc lists of an inbound email message.
We simply refer to outbound messages generated by @post by the term message-id. The following characterises message-id:
Inbound message entity has message-id as the primary key, inbound message's reference-id as foreign key and includes as attributes header, body and attachment information.
Outbound message entity has message-id as the primary key and all the attributes set by the customer or inherited from the customer's profile required by the @Post message switch for fulfilment and rating, for example number of pages printed, colour, type of postal class and so on.
Message rating entity has message-id as the primary key, index on customer id paying for the message and message cost rating before discounts.
Bill Presentment and Payment application is driven by a customer database and billing database where for each customer-id a (postal) message is generated according to the billing address details and according to the billing web-form attributes. The bulk of customers get their hardcopy bill via @post. Customers that prefer bill presentment by email are sent the filled in web-form with links to e-payment if applicable. Customers failing to acknowledge or pay their e-bills within the specified period (default 72 hours) will be billed by postal message.
Alert services are event driven messaging applications. For example, respond to a request for information as a postal fulfillment. A customer may, for example, send a request for a share offer pack by email or by web, with information automatically posted by @post. Another type of alert service, are debt collection notices, say for overdue bills. @Post will have a generic alert engine enabling customers to define events and responses to events.
These applications for direct mailers range from writing an individual cover letter generated from the customer database to selective inclusion of content by selective parts of the submitted e-package meeting the filtering criteria of specific customer database attributes.
@Post will offer customer name and address matching services for customers willing to clean their customer database. We will seek partnership will one of the Future Post specialist houses such as MasterSoft.
Some 15% of all postal addresses at any time are forwarded delaying and slowing the postal process. If eligible and feasible, @post will interface with the postal service(s) forwarding database(s) for improved quality of service by removing a point of failure and processing from the postal delivery process.
@Post will provide inbound mailroom application to scan in and archive documents, to support virtual e-mail and virtual fax addresses, and mailbag collation as per the US PTO patent application.
@Post professional services will work with major corporate customers to develop custom-made value added messaging applications.
@Post will seek alliances with major mail houses and print-on-demand value adders, direct mailers and organisations for bill presentment and payment with open systems, integration and value adding in mind.
@Post will support the X.520 person object based directory services as well as the following two specialist uses:
Anti-spam filters enabling users to specify criteria against reserving messages e.g. blocking:
The core business of @Post is postal messaging. Everything directly related to postal messaging will be developed and supported by @Post. In particular, @Post message switch, activation, authentication, billing, customer care, distribution management and tracking are core business.
All other messaging types are non-core and if possible will be bought off-the-shelf. The criteria for acquiring third party messaging systems is ability to interface with @Post messaging database, ability to integrate with the @Post message switch, scalability and ease of support.
@Post messaging platform functions are classified core versus non-core as follows:
Non-core System Management and Monitoring Services
Core Message and Customer Database
Core Message Routing Services
Core Message Handling Services
Core Message Integration Services
Core Postal Fulfillment Services by IDP/EDIPost
Non-core Internet Messaging Services
Non-core POP3 Mail Access Services
Non-core IMAP4 Mail Access Services
Non-core Web Mail Access Services
Core Distribution Lists Management Services
Non-core Anti-Virus Services
Non-core Anti-Spam Services
Non-core Message Encryption and Decryption Services
Non-core Message Content Filtering Services
Core Postal Application Integration Services
Non-core Computer-Telephony (CT) Integration Services
Non-core Fax Gateway Services
Non-core Pager, SMS and PDA Gateway Services
Non-core Software Customization Services
Non-core Directory Services
Automated document conversion is not just a significant competitive edge for @Post but a potential revenue stream. The input document types are all major word processing applications, spreadsheets and presentation types. The output is PostScript 3 for print fulfillment and PDF for viewing with HTML/XML being an optional type. In particular, convert the following desktop types:
Microsoft Excel 95, 97, 2000 (7.0, 8.0, 9.0)
Microsoft PowerPoint 95, 97, and 2000 (7.0, 8.0, 9.0)
Microsoft Word 95, 97, 2000 (7.0, 8.0, 9.0) and earlier (Windows: 1.0,
2.0, 6.0, 7.0, 8.0; DOS: 3.0, 3.1, 4.0, 5.0, 5.5, 6.0)
Lotus 1-2-3 96, 97, and Millennium
Freelance 96, 97, and Millennium
Lotus WordPro 96, 97, and Millennium
Lotus AmiPro (1.1, 1.2, 2.0, 3.1)
Microsoft write (3.x)
Corel WordPerfect 8.0 and earlier (Windows and DOS: 5.x, 6.0, 6.1,
FrameMaker (3.0, 4.0, 5.0)
Interleaf (1.1, 5.0, 5.2, 6.0)
Rich Text Format (RTF) - RTF is mandatory.
ASCII Standard PC
HTML files - HTML is mandatory
Converts these file formats:
BMP, CDR, CGM, DIB, DRW, DXF, EPS, GIF, HPGL, JPEG, MSP, PCC,
PCX, PNG, PIC, RAS, TIFF, WMF, WPG
@Post requires an SDK to obtain the number of pages per document to be printed, whether gray scale or color and if color then whether light color, medium color or heavy color based on ink content. This is info is important for costing of jobs. Infoaccess.com supports the automated conversion of the above document types into HTML and XML. See ftp://tcsdkdocs:firstname.lastname@example.org/pub/tcsdkdocs/HTMLformat/TCSDK40.exe for details about their SDK.
The below form must be viewed by Internet Explorer. For those with NS Navigator: the cost for 1-page grayscale letter for domestic U.S. is $53$ for 100 letters.
Copyright © 1999 ELetter Incorporated. All Rights Reserved.
The above with heavy color would cost $124.00. Similarly the above as a 3-page letter would cost $65.00 or 6c per page grayscale or 23c per medium color.
Observe the above is quoted in $US. Note the $10 minimum. Add $5 for mail merge of 100 letters.
For up-to-date eletter.com pricing information see http://www4.eletter.com/pricing/letter/letter.asp.
InfoAccess.Com, KeyPak.Com and all the relevant third-party document conversion solutions on the Microsoft and PDF-Zone web sites have been contacted. The following concerns have been expressed about automated document conversion into PostScript and PDF as automated page composition:
The bottom line is that a PDF conversion for print pre-view and user confirmation before print must be offered unless the user wants to skip print preview. @Post e-mail users would receive by return email the converted PDF file(s) for viewing - a small conversion charge of 5-10c per document applies waived if the user confirms sending of the postal message - with a URL hotlink for print confirmation. @Post web-interface presents the above as an online process.
A significant problem could be that print fulfillment is generally used for long runs involving similar documents, in such situations the problem of generating and parsing vast amounts of postscript is simplified by splitting off text that changes from the rest of the document (aka "Decomposition"). The current print fulfillment providers may not have the computer power to accommodate low volume complex postscript and still run these fast printers at full speed. Eletter.com has made significant progress in resolving such issues.
@Post implements legally admissible messaging by combined secure electronic and postal messaging.
Level 1 messaging combines secure strongly authenticated encrypted and check summed e-package with postal message with postal delivery receipt. Level 1 is insured for $10,000. L1 messages cost $25 per party plus postal message cost for pages printed in excess of ten pages. Thus, a L1 message involving four parties is priced at $100.
Level 2 adds to L1 twin print fulfillment of the e-package with a reply paid envelope for receivers to return the second copy signed and witnessed in total with each page initialed. Level 2 is insured for $100,000. L2 message cost $50 per party plus postal message cost for pages printed in excess of ten pages.
Level 3 adds L2 physical witnessing of all signatures with a 100-point identity check of all the signers in a post office or other authority such as Justice of Peace. Level 3 is insured for $1,000,000. Higher insurance can be made available for L3 on request. L2 message cost $100 per party plus postal message cost for pages printed in excess of ten pages.
G5 messaging has the following benefits:
1. MIME based
2. Inclusion of document/message metadata, viz. sender, recipient, subject, keywords in first MIME header file of the message
3. Electronic postmarking including time and date stamp, unique message ID, and an encrypted checksum (for message integrity).
4. Content negotiations (new subject of a Standards track document from the IETF)
5. Full message confirmation by recipient electronic postmark retained with the sender’s.
6. Automatic “Electronic Original” legally admissible retention and archiving in compliance with 5 International Codes of Good Practice.
7. 3 Standards based additional forms of authentication and encryption
8. Automatic drop down to Group 3 Fax (carrier) and Internet e-mail and/or Internet Fax and/or postal delivery
9. Carrier independent operation: GSTN, Internet, mobile, cable, internal network
10. A range of automatic service calls to help the user, e.g. Directory Enquiry
@Post requirements are closely aligned with G5. The additional benefits would be automatic drop down to the message type capable of achieving delivery. Also, G5 has established criteria for legally admissible messaging. See http://www.group5forum.org/, http://www.group5.net/ and http://www.5gm.com/ for further G5 information.
We have the " G5 Messaging Trial Interoperability Agreement" by the 5th Generation Messaging Ltd detailing what it takes to implement G5 messaging.
Observe that the automated drop down capability is to maximize the reliability of message transport to overcome message delivery failures as distinct from delivering the same message by multiple means. @Post not only supports multiple types of delivery but offers B-party receive preferences as a paid service. Drop down should be paid by A-party and will override B-party preferences. The exception is where the B-party has subscribed to a privacy protection service and specifically requests not to be contacted by specific message types.
@Post will explore possible partnership with 5th Generation Messaging Ltd. Software.com has been selected as the supplier of the 5G protocol stack and archiver, thus enabling us to expedite G5 functionality and compliance. @Post is analyzing
Print fulfillment queue management is a critical success factor ensuring customer satisfaction. Simplistic FIFO queue management is not satisfactory as a single job can tie a queue for hours or possibly days when handling a massive direct mail campaign. Simple postal messages no longer than three pages should be given priority to maximize overall customer satisfaction.
Customers will be given the nice option of lowering their priority into 2nd class best effort mail with a discount. Mailbag collation is a very valuable and cost efficient service for customers with B-party preferences wanting all their messages converted into postal messages or for customers using @Post for outsourced printing services. Such requirements are ideally supported by mailbag collation on DPID.
Certain resource such as colour printing are more limited but in general @Post intelligent distribution should have an algorithm for print on demand at the facility nearest to the postal destination for maximal delivery speed. However, the algorithm must weigh this against supporting optimised throughput. Another complicating factor is the ability to sustain full print fulfilment speed with very large amounts of variable PostScript resulting from single postal messages. In fact, bulk jobs and distribution list handling may maximize overall throughput and thus revenue at the expense of customer satisfaction. In summary, print fulfilment queue management is a very complex issue.
1. EDI Post production printers would be generally used for long runs involving similar documents, in such situations the problem of generating and parsing vast amounts of postscript is simplified by splitting off text that changes from the rest of the document (aka "Decomposition"). AP may not have the computer power to accommodate @post's low volume complex postscript and still run these fast printers at full speed.
2. EDI Post printing is black & white 300 dpi. At least Sydney and Melbourne would require color 600 dpi. The cost of the top Xerox 92 ppm production color printers is $265,000 a unit plus extra for folders and stuffers, altogether perhaps $350,000 each, re: Xerox DocuPrint 92C Enterprise Printing System
3. EDI Post will face block obsolescence of equipment being 7-8 years old by the time @Post goes live.
· Xerox Purchased Delphax about 1 year ago, and do not intend to continue to sell the existing machines but intend to use the technology to extend their existing printer range to greater speeds.
· The Xerox High End Printer (HEP) engineering group has taken over responsibility for servicing the Delphax machines in Australia (only Australia Post).
· Since Xerox became involved operations and quality have much improved - the printers are now comparable to equivalent Xerox products.
· There are a total of 18 printers in Australia used by the EDI post project, 3 in Sydney, 3 in Melbourne.
· They are approx 6 years old.
· Cut Sheet, 300 dpi, connected to Pitney Bowes folders & stuffers.
Question: Could Xerox justify replacing the Delphax printers with DP180s?
Answer 1 (Responsible Engineering Manager): "Our cost tracking systems have not been in place long enough for us to get an accurate picture of the costs of running the units. Given that the Delphax systems are fully owned by Australia post already I don't think it would be cheaper for Australia Post to lease DP180s instead - I don't know it might be very slightly cheaper."
Answer 2 (Responsible Sales Manager): "No chance of making a cost justification to replace the Delphax machines yet"
Background. The DP180 is Xerox's fastest HEP product, 180 sides per minute, 600 dpi physical and 2400 dpi in PostScript emulation, cut sheet and a list price of half a million dollars. In the past 18 months the larger Print bureaus have prospered at the expense of the smaller operations. Both Security Mailing Services (SMS) and Salmat have invested heavily in several DP180s each. The cost of operations is only marginally better than the previous 50 and 90 page per minute printers; the payback is primarily in increased productivity (one man can manage more machines and product more copies per hour) and to a lesser extent reduced downtime.
The DP 330/900/1300 are Xerox's continues feed HEP products and represent a quantum leap in capability in comparison to the old cut sheet printers. The question is whether continuous feed printing can be justified and at what stage. The Australian Market according to Xerox large account manager FAX is too small to justify the expense of offering printers faster than 180 ppm. A Docuprint 360 has been available for some time (really two 180s back to back) but there have been no takers. When a Xeroxified Delphax does become available, he still questions the commercial feasibility of offering such a printer down under. Also, note the approaching bulk obsolescence of AP's printers being already six years old, and 7-8 year when @post goes live.
In summary, the advantage/disadvantage of using the Delphax machines to be negligible in terms of production cost per page. However while 300 dpi is still considered to be acceptable in the volume print industry quality might be an issue. High speed postscript printers might also give some technical headaches in terms of their ability to ingest & our ability to provide complex postscript data streams.
Operating costs of a Xerox printer vary between $4/1000 for the latest & greatest and $12/1000 for the oldest; the Delphax units probably fall in the middle of this range. Total indicative costs per thousand, printing onto blank A4 stock:
Xerox Lease & Maintenance plan 4-12
Burdened operator Cost (6 mins & $60/hr) 6
So the actual incremental cost of printing the document is at most 2.5c/sheet assuming the printers are fully occupied and your overheads are already being covered.
Obviously costs are usually far higher than this since overheads, management, sales, marketing and under-utilised equipment time has to also be covered. @Post is talking in terms of >$1 per postal message. Thus, the actual print production costs should be negligible. Success is far more likely to depend upon quality, speed of service etc.
EDI Post supports DPID appending, barcode printing, mail preparation and lodgment service.
If you have a database of addresses in which you would like to include Delivery Point Identifiers (DPID) this service will address match and link DPIDs to your customer addresses using AMAS certified software.
This service enables you to lodge bar-coded mail by supplying EDI Post with data files containing DPIDs. EDI Post converts the DPID (where present) into the appropriate barcode for printing. Your mail is sorted into bar-coded and non-bar-coded streams before lodgement to ensure you gain the maximum postal savings.
If your data file contains a mix of addresses with and without DPIDs, EDI Post can also sort and add DPIDs to new records or records for which DPIDs have become available. EDI Post will print barcodes with the updated addresses and lodge as bar-coded mail. The amended records can also be returned for updating of your database.
This is a comprehensive service that takes data files without appended DPIDs; an address match using AMAS certified software, barcodes and streams the mail before lodgement to optimise savings. The data file can be returned to you with DPID information appended for updating of your database.