U.S. patent application number 09/801966 was filed with the patent office on 2001-10-25 for automatic generation of correspondence via an email interface.
Invention is credited to Powers, Gene.
Application Number | 20010034849 09/801966 |
Document ID | / |
Family ID | 24073530 |
Filed Date | 2001-10-25 |
United States Patent
Application |
20010034849 |
Kind Code |
A1 |
Powers, Gene |
October 25, 2001 |
Automatic generation of correspondence via an email interface
Abstract
There is disclosed a process for generation, graphical
composition, and delivery (or routing for delivery) of conventional
forms of written correspondence. Specifically, the conventional
form of written correspondence (e.g., business letter) is generated
from a correspondence message, such as a text Internet email
message. More specifically, a sender can initiate correspondence in
a variety of formats, to multiple recipients or to group(s) of
recipients, wherein there is security provided against unauthorized
generation of correspondence by assumed SMTP email identities,
thereby preventing "forgery" of a correspondence from the
sender.
Inventors: |
Powers, Gene; (Tiburon,
CA) |
Correspondence
Address: |
DAVIS WRIGHT TREMAINE, LLP
2600 CENTURY SQUARE
1501 FOURTH AVENUE
SEATTLE
WA
98101-1688
US
|
Family ID: |
24073530 |
Appl. No.: |
09/801966 |
Filed: |
March 7, 2001 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09801966 |
Mar 7, 2001 |
|
|
|
09520654 |
Mar 7, 2000 |
|
|
|
Current U.S.
Class: |
726/30 ;
709/206 |
Current CPC
Class: |
G06Q 10/107 20130101;
H04M 3/53366 20130101; H04M 3/493 20130101; H04L 51/00 20130101;
H04L 9/40 20220501; H04L 69/329 20130101; H04L 51/066 20130101 |
Class at
Publication: |
713/202 ;
709/206 |
International
Class: |
H04L 012/22; H04L
009/00 |
Claims
I claim:
1. A process for generating completed mail objects from email or
text messages from a registered sender to be received by recipients
in hard copy and comprising graphical correspondence content and
graphical representation of a signature, comprising: (a) receiving
a correspondence message from the registered sender containing
text, recipient names or sender-specified recipient identifiers,
and identity of the registered sender; (b) locating registered
sender information in a database or a plurality of databases,
wherein the database or the plurality of databases comprises
preferences having correspondence format information and a
graphical representation of a registered sender signature; (c)
obtaining, using either the recipient names or the sender-specified
recipient identifiers, recipient location information from either
the database or the plurality of databases, or directly from the
registered sender, wherein the database or the plurality of
databases comprises names and addresses of recipients for each
registered sender; and (d) generating a completed correspondence to
deliver to the recipient by one or more transmission means selected
from the group consisting of transmitting a facsimile to a
facsimile telephone number utilized by the recipient, transmitting
an email providing or linking to a graphical representation of the
correspondence to an Internet address utilized by the recipient,
generating a hard copy of the completed correspondence for
submission by hard copy delivery services, and combinations
thereof, wherein the completed correspondence comprises the
registered sender's letter head or card graphics, registered
sender's signature and correspondence message.
2. The process of claim 1 wherein receiving a correspondence
message from the registered sender occurs via a website interface,
instead of via an email.
3. The process of claim 1 wherein the hard copy completed
correspondence is generated at a location facilitating rapid
delivery to the recipient using existing delivery services.
4. The process of claim 3 wherein the completed correspondence is
created at a location adjacent to an overnight courier hub.
5. The process of claim 1 wherein the completed hard copy
correspondence is sent by facsimile transmission to the
recipient.
6. The process of claim 1 wherein the database or the plurality of
databases comprises names, postal addresses, email addresses, and
telephone numbers for recipients.
7. The process of claim 1 wherein the database or the plurality of
databases enables each registered sender to have multiple formats
for documents, and to optionally customize each document format by
selecting from a variety of signatures, content and identification
information held for the sender.
8. The process of claim 1 wherein transmitting an email, providing
or linking to a graphical representation of the correspondence, to
an Internet address utilized by the recipient involves the use of
either HTML or HTML with bit-mapped formats.
9. The process of claim 1 prior to step (d), further comprising
generating a proof copy of the correspondence to be sent by email
to the sender for review and approval.
10. The process of claim 9 wherein the sender approves the proof
copy of the correspondence by return email or by HTTP
transmission.
11. The process of claim 9 wherein the sender is able to change the
correspondence or the preferences associated with the
correspondence.
12. The process of claim 11 wherein the preferences that can be
changed are selected from the group consisting of correspondence
type, letterhead or card graphics style, recipient delivery means,
greeting, closing, signature, text of correspondence, and
combinations thereof.
13. The process of claim 9 wherein generating a proof copy of the
correspondence to be sent by email to the sender for review and
approval involves the use of either HTML or HTML with bit-mapped
formats, or in text form with a URL link to either HTML or HTML
with bit-mapped formats.
14. The process of claim 1 wherein the correspondence message
further comprises additional information selected from the group
consisting of attachments, preferences and combinations
thereof.
15. The process of claim 14 wherein the preferences are specified
on a subject line of an email message.
16. The process of claim 1 wherein obtaining recipient location
information from either the database or the plurality of databases,
or directly from the registered sender, wherein the database or the
plurality of databases comprises names and addresses of recipients
for each registered, is achieved using the names of the
recipients.
17. A system or an apparatus for generating completed mail objects
from e-mail messages from registered senders to be received by
recipients in remote locations in hard copy, Fax transmission or
HTML email and comprising message information, graphical letterhead
or card content, and graphical representation of a signature,
comprising: (a) a computer or server means for receiving a
correspondence message from the registered sender containing text
and other information to be included in a correspondence; (b) a
database or plurality of databases having registered sender
information and preferences, wherein the database or the plurality
of databases comprises a sender's preferences for correspondence
format information, recipient information and a graphical
representation of a registered sender signature; (c) recipient
location information, wherein the source of the recipient location
information is from either the database or the plurality of
databases, or from the registered sender, wherein the database or
the plurality of databases comprises names and addresses of
recipients for each registered sender; and (d) a remote or local
facility for generating a completed hard copy correspondence at a
location facilitating rapid delivery to the recipient using
existing delivery services, wherein the completed correspondence
comprises the registered sender's letter head, registered sender's
signature and correspondence message, or a Fax server for
generating a fax correspondence telephoned to the recipient's fax,
or an Email server for sending the correspondence in HTML or HTML
with bit-mapped formats, or in text form with a URL link to either
HTML or HTML with bit-mapped formats.
18. The system or apparatus for generating completed mail objects
from email messages of claim 17 wherein the completed hard copy
correspondence is created at a location adjacent to an overnight
courier hub.
19. The system or apparatus for generating completed mail objects
from email messages of claim 17 wherein the completed hard copy
correspondence is sent by facsimile transmission to the
recipient.
20. The system or apparatus for generating completed mail objects
from email messages of claim 17 wherein the database or the
plurality of databases comprises names, postal addresses, email
addresses, and telephone numbers for recipients.
21. The system or apparatus for generating completed mail objects
from email messages of claim 17 wherein the database or the
plurality of databases enables each registered sender to have
multiple formats for documents, and to optionally customize each
document format by selecting from a variety of signatures, content
and identification information held for the sender.
22. The process of claim 1, further comprising a security mechanism
directed to precluding either creation, or transmission of a forged
correspondence to a recipient.
23. The process of claim 22 wherein the security mechanism directed
to precluding either creation, or transmission of a forged
correspondence to a recipient is selected from the group consisting
of password-controlled access to a POP server, public key/private
key encryption, digital signatures, firewalls, SQL or VPN
interfaces, database architecture and combinations thereof.
24. The process of claim 1, further comprising a security mechanism
directed to precluding theft of sender information.
25. The process of claim 24 wherein the security mechanism directed
to precluding theft of sender information is selected from the
group consisting of public key/private key encryption, digital
signatures, firewalls, SQL or VPN interfaces, database architecture
and combinations thereof.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation-in-part of U.S. patent
application Ser. No. 09/520,654, entitled AUTOMATIC GENERATION OF
CORRESPONDENCE VIA AN EMAIL INTERFACE, filed Mar. 7, 2000.
TECHNICAL FIELD OF THE INVENTION
[0002] The present invention provides a process for generation,
graphical composition, and delivery (or routing for delivery) of
conventional forms of written correspondence. Specifically, the
conventional form of written correspondence (e.g., business letter)
to be transmitted to a recipient is generated from a correspondence
message provided by a sender via an email or text message, or via
an internet interface. More specifically, a sender can initiate
correspondence in a variety of formats, to multiple recipients or
to group(s) of recipients, wherein there is security provided
against unauthorized generation of correspondence by assumed SMTP
email identities, thereby preventing "forgery" of a correspondence
from the sender.
BACKGROUND OF THE INVENTION
[0003] The present invention is in the field of computer-generated
correspondence. The evolution of this field has begun by focusing
on tools that assist a computer user in composing written
communications through a number of disparate interface methods.
Previous disclosures for composing and producing computer assisted
written communications have included word processing applications,
computer Fax applications, Internet greeting card providers,
Internet Fax from email (or Web Browser) services, Internet email
to postal mail services that simply reproduce what they receive
plus addressing, and Internet service(s) providing direct mail
fulfillment services from a graphical template composed by and
provided by the user. However, such services do not allow full
reproduction of traditional written communication formats and
media, or at best require significant intervention and/or actions
by the sender (and at times by the receiver) to achieve such
formats. Additionally, none of these present a unified interface
for composing and delivering differing forms of written
communication.
[0004] Traditional written communication formats include, for
example, all forms of written communications generated including
business letters on business letterhead (sizes 81/2".times.11", A4,
Legal, Monarch, etc.), business notes/memos, business
announcements/invitations, business form letters, business
postcards, business legal notifications, personal letters, personal
letter on personalized stationery, personal notes/cards, personal
announcements, personal postcards. These forms of communication
historically use various combinations of layout, handwriting, hand
printing, signatures, preprinted fonts and graphics. Earlier
services fall short of reproducing these formats automatically or
with ease. Word processing programs can generally be configured to
produce these formats, however it is a manual and cumbersome
process with many steps. Many users are not capable of the graphics
manipulation required to compose these formats with letterhead and
signature. Furthermore, it is left to the user to render the
composition into hardcopy form, and to arrange the delivery
connection. Internet greeting card providers (both e-card and
hardcopy card vendors) provide only limited personalization for the
cards they vend. Greeting card providers provide neither a
handwriting equivalent that reflects the user's personal cursive
style, nor an essential "signature" to personalize the card. One
service exists for ordering hand calligraphy on cards, but this is
not an automated process. Internet FAX-from-email and
letter/direct-mail-from-email providers either force the user to
compose the graphics of his or her message manually with a word
processor, or provide "canned" formats without personalization of
signature, personal stationery or business logos.
[0005] Email Systems
[0006] In computer network systems such as local-area networks
("LANs"), wide-area networks ("WANs"), and the Internet and the
world-wide web ("WWW"), electronic mail ("e-mail," or "email")
systems are often utilized to facilitate communication between two
or more users of the network. Each user has a unique network
address that may be used for routing and identifying purposes in
delivering an e-mail message from one user (the "sender") to
another user (the "recipient") on the network. Often an e-mail
message contains a relatively small amount of text or other forms
of data. One or more additional files of data, called "attachments"
are often attached to the e-mail message. For example, a word
processing file or graphic file that is incompatible with the
display capabilities of the e-mail system or that is too large to
be conveniently displayed by the e-mail application program may be
transmitted from the sender to the recipient by attaching it to an
e-mail message. The e-mail message may introduce or explain the
attachments. Thus, the recipient receives the e-mail message plus
any attached data files, wherein the attached data files must be
opened, accessed, or utilized separately from the email message
itself. One drawback is that this method requires the recipient
have the necessary software to open and display the attachment(s).
Another drawback of this technique for electronic deliveries is
that the size of the email with attachments is often large, and
requires relatively long upload times for the sender and download
times for the recipient.
[0007] HTML formats have become the language of page compositions
for web sites. Moreover, objects can be scanned into HTML formats
for use in web pages. Composition and display of HTML formats has
been added to most mainstream email programs. However, a large time
commitment is needed to design HTML email formats with scanned
inputs and graphical elements. Hence, this format has not been
generally utilized for personal correspondence in email messages
due to the limited amount of time typically available for doing
such tasks. Several World Wide Web sites provide for the
association of some rudimentary HTML graphics with email created at
their sites, but none even approach the capability of generating
full traditional correspondence formats, or an easier method of
interface than the World Wide Web can provide. Furthermore,
adapting HTML composition techniques to produce suitable quality
output for hardcopy local to the user for postal, courier or
express deliveries is cumbersome and rampant with potential time
consuming problems.
[0008] Internet Letter Services
[0009] Netgram.TM. and Eletter.TM. represent services that utilize
email and database methods, and have limitations and drawbacks that
leave room for major improvements. Drawbacks that are shared by
both, are 1) that the "sender" can only initiate a transaction that
results in a physical postal mail item or items, 2) no graphical
composition other than what the user provides, is supported, and 3)
the "sender" does not "see" and approve the final article that is
sent to the recipient until after the fact, or by special manual
arrangement that significantly delays the sending.
[0010] While Eletter.TM. will generate and post for delivery a
letter to the recipient sent by email from the sender, it is up to
the recipient to provide the fully formatted letter, along with the
list of addresses, in conventional mail merge format. Eletter.TM.
will then provide the necessary printing, assembly and mailing
services. While this technique is suitable for volume mailings
(i.e., junk mail), it does not afford the convenience, automatic
composition, selection of media and alternate delivery methods that
the present invention does.
[0011] Netgram.TM. uses a relatively crude form of composition with
no flexibility to generate anything beyond a single format of
written correspondence containing formatting and graphics to the
extent that the user provides them in the initial e-mail request.
Therefore, "Netgram.TM." is much like an Internet telegram or
Western Union mailgram, and results in a message printed centrally,
or remotely, that is then placed in an addressed envelope and
delivered by regular postal means.
[0012] Therefore, there is a need in the art to improve upon the
drawbacks of such systems as Eletter.TM. and Netgram.TM.. For
example: 1) Netgrams.TM. cannot replicate standard forms of
communication other than the "telegram" format, or some similar
"print-on-plain-paper" format with a header above text and/or
whatever graphics are supplied by the "sender"; 2) while a
Netgram.TM. user could theoretically supply all the graphics for
replicating conventional written communication, the Netgram.TM.
method does not permit automatic integration of the "recipient"
address inside the email provided by the "sender," and hence the
sender would have to supply the "recipient" address twice, inside
the graphical email and then to the Netgram.TM. delivery system; 3)
the "sender" never sees the Netgram.TM. before it is sent (in case
an error was made in supplying the address, or if the formatting of
the Netgram.TM. is undesirable); 4) the "sender" cannot initiate a
variety of correspondence items and delivery methods from the
interface; 5) the "sender" is required to associate an identifier
with each potential "recipient" in order to retrieve addressing
information for the "recipient"; and 6) the Netgram.TM. method
allows a forgery to be easily made, due to the way that SMTP email
protocol works on the Internet; namely, a forger can assume the
identity of the "sender" by setting up an email program with the
"sender's" public email identifier, and by guessing or in some
other manner (such as examining mail headers on the internet or in
storage folders) determining the "recipient ID" that the sender
would use for a particular addressee, send any message under the
identity of the "sender" to the "recipient."
SUMMARY OF THE INVENTION
[0013] The present invention provides a process for generating
completed mail objects from email or text messages from a
registered sender to be received by recipients in hard copy and
comprising graphical correspondence content (e.g., business
letterhead, personal letterhead, card graphics, photo postcard
graphics, etc.) and graphical representation of a signature,
comprising:
[0014] (a) receiving a correspondence message from the registered
sender containing text, recipient names or sender-specified
recipient identifiers, and identity of the registered sender;
[0015] (b) locating registered sender information in a database or
a plurality of databases, wherein the database or the plurality of
databases comprises preferences having correspondence format
information and a graphical representation of a registered sender
signature;
[0016] (c) obtaining, using either the recipient names or the
sender-specified recipient identifiers, recipient location
information from either the database or the plurality of databases,
or directly from the registered sender, wherein the database or the
plurality of databases comprises names and addresses of recipients
for each registered sender; and
[0017] (d) generating a completed correspondence to deliver to the
recipient by one or more transmission means selected from the group
consisting of transmitting a facsimile to a facsimile telephone
number utilized by the recipient, transmitting an email providing
or linking to a graphical representation of the correspondence to
an Internet address utilized by the recipient, generating a hard
copy of the completed correspondence for submission by hard copy
delivery services, and combinations thereof, wherein the completed
correspondence comprises the registered sender's letter head or
card graphics (such as greeting card graphics, thank you notes,
etc.), registered sender's signature and correspondence
message.
[0018] Preferably, receiving a correspondence message from the
registered sender occurs via a website interface, instead of via an
email. Preferably, the correspondence message further comprises
additional information, including but not limited to attachments
(e.g., graphical images or documents) and preferences. Most
preferably, new or amended preferences are specified in a subject
line of an email message. Preferably, the hard copy completed
correspondence is generated at a location facilitating rapid
delivery to the recipient using existing delivery services.
Preferably, the completed hard copy correspondence is created at a
location adjacent to an overnight courier hub or at a location
adjacent to a major regional postal service hub. Preferably, the
completed hard copy correspondence is sent by facsimile
transmission to the recipient's fax telephone number. Preferably,
the database or the plurality of databases comprises names, postal
addresses, email addresses, and telephone numbers for recipients.
Preferably, the database or the plurality of databases enables each
registered sender to have multiple formats for documents, and to
optionally customize each document format by selecting from a
variety of signatures, content and identification information held
for the sender. Preferably, obtaining recipient location
information from either the database or the plurality of databases,
or directly from the registered sender, wherein the database or the
plurality of databases comprises names and addresses of recipients
for each registered, is achieved using the names of the recipients.
Preferably, transmitting an email, providing or linking to a
graphical representation of the correspondence, to an Internet
address utilized by the recipient involves the use of either HTML
or HTML with bit-mapped formats, or text formats with a URL link to
either HTML or HTML with bit-mapped formats.
[0019] Preferably, prior to step (d), there is a further step
comprising generating a proof copy of the correspondence to be sent
by email to the sender for review and approval. This step helps to
implement a security measure to the inventive process. Most
preferably, the sender approves the proof copy of the
correspondence by return email or by HTTP transmission. Most
preferably, the sender is able to change the correspondence or the
preferences associated with the correspondence. Most preferably,
the preferences that can be changed are selected from the group
consisting of correspondence type, letterhead or card graphics
style, recipient delivery means, greeting, closing, signature, text
of correspondence, and combinations thereof. Preferably, generating
a proof copy of the correspondence to be sent by email to the
sender for review and approval, involves the use of either HTML or
HTML with bit-mapped formats, or text formats with a URL link to
either HTML or HTML with bit-mapped formats. Preferably, the
inventive process further comprises a security mechanism directed
to precluding either creation, or transmission of a forged
correspondence to a recipient. Preferably, the security mechanism
directed to precluding either creation, or transmission of a forged
correspondence to a recipient is selected from the group consisting
of password-controlled access to a POP server, public key/private
key encryption, digital signatures, firewalls, SQL or VPN
interfaces, database architecture and combinations thereof.
Preferably, the inventive process further comprises a security
mechanism directed to precluding theft of sender information.
Preferably, the security mechanism directed to precluding theft of
sender information is selected from the group consisting of public
key/private key encryption, digital signatures, firewalls, SQL or
VPN interfaces, database architecture and combinations thereof.
[0020] The present invention further provides a system or apparatus
for generating completed mail objects from email or text messages
from registered senders to be received by recipients in remote
locations in hard copy, Fax transmission or HTML email (dual mode
contains a text URL pointer to an on-line HTML image as well as the
full HTML) and comprising message information, graphical letterhead
or card content, and graphical representation of a signature,
comprising:
[0021] (a) a computer or server means for receiving a
correspondence message from the registered sender containing text
and other information to be included in a correspondence;
[0022] (b) a database or plurality of databases having registered
sender information and preferences, wherein the database or the
plurality of databases comprises a sender's preferences for
correspondence format information, recipient information and
addresses and a graphical representation of a registered sender
signature;
[0023] (c) recipient location information, wherein the source of
the recipient location information is from either the database or
the plurality of databases, or from the registered sender, wherein
the database or the plurality of databases comprises names and
addresses of recipients for each registered sender; and
[0024] (d) a remote or local facility for generating a completed
hard copy correspondence at a location facilitating rapid delivery
to the recipient using existing delivery services, wherein the
completed correspondence comprises the registered sender's letter
head, registered sender's signature and correspondence message, or
a Fax server for generating a fax correspondence telephoned to the
recipient's fax, or an Email server for sending the correspondence
in HTML or HTML with bit-mapped formats, or in text formats with a
URL link to either HTML or HTML with bit-mapped formats.
[0025] Preferably, the correspondence message further comprises
additional information, including but not limited to attachments
(e.g., graphical images or documents) and preferences. Most
preferably, new or amended preferences are specified in a subject
line of an email message. Preferably, the completed hard copy
correspondence is created at a location adjacent to an overnight
courier hub or regional postal service hub. Preferably, the
completed hard copy correspondence is sent by facsimile
transmission to the recipient's fax machine. Preferably, an
electronic image of the completed correspondence is delivered as
email (e.g., HTML or HTML with bit-mapped formats, or in text form
with a URL link to either HTML or HTML with bit-mapped formats) by
a conventional Internet email server to the sender, and optionally
to the recipient. Preferably, the database or the plurality of
databases comprises names, postal addresses, email addresses, and
telephone numbers for recipients. Preferably, the database or the
plurality of databases enables each registered sender to have
multiple formats for documents, and to optionally customize each
document format by selecting from a variety of signatures, content
and identification information held for the sender.
BRIEF DESCRIPTION OF THE DRAWINGS
[0026] FIG. 1 shows a flow chart of a hardware design (system
architecture) to implement the inventive process.
[0027] FIG. 2 shows an illustrative structure of the fields and
tables of a first database for a hypothetical subscriber or
sender.
[0028] FIGS. 3A, 3B and 3C show a system flow chart of the overall
process of a sender "email user" registering and identifying
recipients and their addresses (FIG. 3A), configuring and
transmitting a "proof copy" (FIG. 3B), and ultimately transmitting
the correspondence by any or all of three means of transmission
(FIG. 3C).
[0029] FIG. 4 shows an example of a screen image showing a partial
proof copy of a letter for review by the sender, including a
digital image of the sender signature and sender letterhead.
[0030] FIG. 5 shows a partial proof copy of a letter for review by
the sender, including a set of preferences that can be modified by
the sender. FIG. 5 also illustrates the ability to modify the
correspondence content according to the present invention.
[0031] FIG. 6 shows a sample screen page for a sender email used to
compose his or her correspondence according to the inventive
process that resulted in the correspondence proof copy shown in
FIGS. 4 and 5, and final emailed delivery correspondence of FIG.
8.
[0032] FIG. 7 shows a sample World Wide Web page for a sender that
used alternatively to compose his or her correspondence according
to the inventive process that results in a correspondence proof
copy similar to that shown in FIGS. 4 and 5, but displayed with a
Web browser.
[0033] FIG. 8 shows a final emailed delivery correspondence,
corresponding to the correspondence proof copy shown in FIGS. 4 and
5.
DETAILED DESCRIPTION OF THE INVENTION
[0034] Definitions:
[0035] The term "recipient address" or "address" refers to various
identifying information, including, but not necessarily limited to
email addresses, street addresses, telephone numbers, fax numbers,
PCP-IP addresses, etc., that can be used according to the present
invention to transmit a correspondence to a specific recipient or
of recipients.
[0036] Overview
[0037] The present inventive process provides the following
marketing advantages with the following features for generating
hard copy quality correspondence to a recipient from a
correspondence message sent by a "sender" or by a registered sender
using the corresponding Web site. Additionally, the inventive
process and system provides for composition, routing and delivery
of Fax communications and electronic versions of all written
communications by the same sender email interface. These
improvements and additional functions maximize convenience to the
sender, because the sender can utilize the familiar interface of
his or her email program, or Internet interface, to effect all
these results.
[0038] Composition Module Specification
[0039] The invention produces traditional written correspondence in
diverse formats including email (HTML or HTML with bit-mapped
formats, and including text email with URL link), and as hardcopy
deliverable items. Such hardcopy items vary in physical size and
layout, (e.g., Faxes, full-size business letters, personal letters,
monarch/executive size letters, announcements, cards, photo
postcards, etc.). The present invention includes a process for
decomposing and storing the graphic structure of various
correspondence items (in particular letters) that permits
recomposing them for specific individual and personal
correspondence items. This is the process of registering a sender.
The sender registration process utilizes recomposing graphics and
various correspondence components assembled in a service database
as "preference" entries for a particular sender. Further sender
preferences in the database include an address book of a recipient
or recipients, including preference information for each recipient
as to how the correspondence is to be composed and sent.
[0040] Thus, graphic components and sender information (both called
"preferences") are stored in the service database when a sender
registers for use of the system. Recipient information and
preferences for correspondence with the recipient are set by the
sender by various methods, such as (1) uploading addressee
information at the WWW site for the service in various formats that
are converted to the service database and stored in association
with the sender, (2) entering addressee information and
correspondence preferences at the WWW site for the service, and (3)
issuing an email request for correspondence to an "unknown" or
"previously undefined" addressee. In the latter case, the inventive
apparatus sends an HTML form to the sender, via email, requesting
the missing recipient address information and correspondence
preferences. Such new recipient (to the sender) information must be
returned prior to issuing the correspondence. The sender may simply
use the name of a recipient, or may optionally associate a unique
identifier with each recipient or multiple recipients. Either may
be used to select the recipient(s) for a correspondence item. In
the case of recipient names, the system provides an email form to
resolve any ambiguity where multiple recipients have been
associated with the same name by the sender.
[0041] The Composition Module
[0042] The Composition module retrieves various components or
preferences from the service database entries, stored for a
particular sender, to create the image of the letter it is
producing. Therefore, the business stationery graphics, personal
stationery graphics, note graphics, card graphics etc. associated
with a sender are stored on the system. Likewise, recipient
preferences, including, for example, addresses (postal, street for
FedEx, Internet, and facsimile), correspondence style, signature
style (i.e., first name only, initials, or full name), letter
closing (e.g., sincerely, best regards, right on!, etc.) and
greeting (e.g., Mr. or Ms, full name of recipient or first name of
recipient) are all preferences that are specified by a sender for
each recipient, and stored on the system. Delivery means, such as
email (e.g., HTML or HTML with bit-mapped formats), Fax, and
printed hardcopy all have different requirements of resolution and
color, so that the database must store a different image (or
several image components) for each type of output.
[0043] Alternatively, but less preferably, the image composition
module generates these image variations on the fly, resulting in a
processing load that is less favorable for high volume usage of the
composition module.
[0044] There are differing requirements for each preference of
correspondence production. Therefore, each sender can register
multiple preferences for a single field, such as electronic images
for the sender's business letterhead, business envelope, personal
stationery and Formal/Standard/Casual signatures. Such high
resolution and original source files will be of varying format and
resolution, and will typically be produced by a high-resolution
scanner, or with various graphics composition programs like Adobe
Print Shop.TM.. These images are typically higher resolution than a
printer technology can render, and of a higher resolution than
would be needed to produce any of the output forms mentioned.
[0045] Upon update or initial entry of a high-resolution source
image (e.g., a signature block or a letterhead), the apparatus and
database produce and store a plurality of secondary image files for
each of these files sets. The file sets are used, for example, to
produce HTML letters (for example, 72 dpi 16MM color image files
can be produced and stored in the database in ".png", ".gif", or
".jpg" format), to produce Faxes (200 dpi 256 gray scale images),
and to produce color printouts (600 dpi or greater, 16MM color,
TIFF images--preferably in CMYK color mode). Each letterhead and
envelope scan can be broken down into designated areas of the page
(for example, into 8 page sub-areas) that are reassembled by the
composition software to recreate the page graphics. For example,
the top of a page can be divided into three sub-areas (left, middle
and right). Similarly, the bottom of a page is divided into three
sub-areas of left, middle and right. Each side is a separate area
and the middle is an area. This system allows for more efficient
storage per full-page image.
[0046] However, full-page images for hardcopy are preferable
because non-HTML page composition engines typically overlay
elements without any problem. Therefore, for hard copy, a letter or
correspondence can be "overlaid" with elements on the blank area in
the letter. Also, the blank areas do not appreciably increase the
file size for most formats, because one full-page image file may
actually take less bytes than several partial-page image files.
Preferably, the system encrypts sensitive and confidential
information such as the high resolution signatures of sender and
any images or letters that are kept on line utilizing a secure
mechanism such as RSA encryption.
[0047] For "HTML only" letters to shrink and expand, between the
dimensions of an HTML "page", the extra regions at top and bottom
are needed for proper layout on a variable size page. Each area is
stored with an absolute offset from the top left corner of the
original page. The image for an area may be any size, for example,
area 1 may extend all the way across the top of the page if
sub-area 2 and 3 are empty, or it may extend only partially across
the page and sub-areas 2 and 3 may be empty. Business-sized
envelopes have designated areas at the top and left margin.
[0048] While the multi-region approach to composing "HTML only"
letters can provide space savings and a more traditional
shrinking/expanding page format, it does require that all fonts
used in the letter be on the recipient's system used for viewing.
This requirement can only be met with high certainly for a very
limited set of fonts with current technology. Hence, an alternative
approach to "HTML only" letters is to fully render each full page
(or full surface) image in bit-mapped form in an HTML-supported
compressed format such as PNG (portable network graphics) or JPEG.
This rendering is performed by raster image processing methods
well-known and used in various printing and display mechanisms,
such as the screen display drivers and printer drivers used with
various operating systems, such as Microsoft Windows. When the
so-rendered full-page images are then delivered as part of an HTML
email, the result is the ability to directly display the
correspondence item in an electronic form that is almost exactly as
it would appear as a FAX or a printed article, which is currently
not possible using other HTML techniques.
[0049] The database stores the original scans (preferably 1200 dpi
or higher), generated graphics, or vector graphics for letterhead,
envelope and signatures (multiple types) for each sender or the
original digital files provided by each sender. Each sender is
identified, for example, by the source email address (from
identifying box) such that the proper database preferences for an
identified sender can be accessed. Alternatively, the sender is
identified by a sender login process on a web site. Furthermore,
the system determines the addressing and delivery information for
the intended recipient(s) from database(s) or database table(s)
associated with the identified sender by, for example, referencing
and decomposing the "To" and "CC" identifier(s) in an initiating
email, or by recording selections made by a sender issuing a
request on a web site.
[0050] When "To" and "CC" identifiers are extracted from an
initiating email, the email domain specifier (e.g. @microsoft.com)
is removed and the preceding information is examined for either a
recipient name or a unique sender-specified identifier associated
with a recipient or recipients.
[0051] When recipient name is used by a sender to specify the
receiver of a correspondence, the system allows for other optional
identifying information, such as city and/or zip code, to follow
the name to resolve the possibility that senders database includes
multiple recipients with the same name. The system uses the
provided name and any optionally provided information, and attempts
to locate a unique recipient in the database. If more that one
recipient matches the provided information, the system sends an
HTML form to the sender asking them to choose the intended
individual recipient from the multiple matches found. Composition
of the correspondence proceeds when all recipient(s) have been
uniquely identified, and any missing recipient(s) or missing
information in the database entry for a recipient required to
complete the correspondence has been solicited from, and provided
by the sender.
[0052] The final composition process for fax delivered
correspondence items, print-delivered correspondence items, and
HTML email-delivered items is somewhat different, so each is
separately described. Preferably, the production of a
correspondence for delivery is based on a proof copy form that has
been returned by the sender, though the proof copy review is not an
essential step in the inventive process. Proof copy composition is
detailed following final delivery item composition.
[0053] In the case of hardcopy printed letter composition works,
the following steps describe a preferred embodiment for automatic
composition activities performed for the sender.
[0054] 1) The type of correspondence (e.g.,
Business/Personal/Legal) is determined from the sender's addressee
database entry(ies) for the recipient(s) or from "approved" proof
copy form.
[0055] 2) The delivery method(s) of the correspondence (e.g.,
Email/FAX/Postal/Express) is determined from the sender's addressee
database entry(ies) for each recipient(s) or from an "approved"
proof copy form.
[0056] 3) The format and size and layout of a correspondence item
is determined (e.g., 81/2.times.11, A4, 81/2.times.14, Monarch,
postcard, announcement) from database preferences or from an
"approved" proof copy form.
[0057] 4) The appropriate high-resolution graphics for the
stationery, card or letterhead are retrieved from the database
(including multi-part graphics; such graphics are supplied or
selected in advance by the sender as part of registration) or from
an "approved" proof copy form.
[0058] 5) The fonts are determined from the sender's database or
preferences or from an "approved" proof copy form.
[0059] 6) The date of the letter is composed according to the
retrieved fonts and layout (preferences) or from an "approved"
proof copy form.
[0060] 7) The inside address of the letter is composed with an
address book entry for the recipient according to the retrieved
fonts and layout or from an "approved" proof copy form. If the
proof copy form indicates changes and an update of the address book
(database) is requested, these changes are posted to the
appropriate sender's address book entry in the database.
[0061] 8) The greeting is composed according to the retrieved fonts
and layout (preferences) or from an "approved" proof copy form.
[0062] 9) The body of the correspondence specified by sender
request is formatted and composed according to the retrieved fonts
and layout (preferences) or regenerated from an "approved" proof
copy form.
[0063] 10) The closing is composed according to the retrieved fonts
and layout (preferences) or from an "approved" proof copy form.
[0064] 11) The appropriate signature graphic is retrieved from the
database according to the retrieved layout or from an "approved"
proof copy form.
[0065] 12) The printed name is added from the sender's database
entry or from an "approved" proof copy form.
[0066] 13) A secretarial line is added for business letters
according to the sender's database entry or from an "approved"
proof copy form.
[0067] 14) The enclosures line is added where appropriate
(attachments specified with initiating request are stored and
re-associated with proof copy).
[0068] Preferably, an envelope is also generated:
[0069] 1) The envelope graphics are retrieved from the
database;
[0070] 2) The recipient's address is positioned and applied for the
envelope;
[0071] 3) E-postage is applied if postal delivery; and
[0072] 4) If express/registered/certified delivery is indicated,
the necessary FedEx or UPS or US Postal forms are composed and sent
with the print job.
[0073] Preferably, in the case of a Fax delivery process, the
following is a preferred embodiment of the inventive process:
[0074] 1) A Fax cover sheet is composed, according to sender
database entries and an HTML document template supplied by the
system, and precedes the letter;
[0075] 2) The cover sheet is populated with appropriate information
for sender and recipient from database entries of the sender and
recipient or from "approved" proof copy form;
[0076] 3) The correspondence item is composed as above, however,
using 200 dpi gray scale images for
letterhead/stationary/cards/envelopes, instead of high-resolution
color images. These images are either a) stored in the database of
the sender b) generated programmatically when needed from the
high-resolution color images in the database;
[0077] 4) No envelope is produced; and
[0078] 5) Alternatively, the sender may choose a single page Fax
letter format, instead of a separate cover sheet, which causes a
somewhat different HTML template from the system (but quite similar
composition process) to be executed.
[0079] Preferably, when an HTML email is a delivery method, the
following is a preferred embodiment of the inventive process:
[0080] 1) The type of the letter (e.g., Business/Personal/Legal) is
determined from the sender's addressee database entry(ies) for the
recipient(s) or from an "approved" proof copy form;
[0081] 2) The delivery method(s) of the letter (e.g.,
Email/Fax/Postal/Express) is determined from the sender's addressee
database entry(ies) for each recipient(s) or from an "approved"
proof copy form(s); HTML email composition applies when Email is
selected as the only, or one of several delivery methods;
[0082] 3) The format and size and layout of correspondence item is
determined from the database (e.g., 81/2.times.11, A4,
81/2.times.14, Monarch, postcard, announcement) or from an
"approved" proof copy form;
[0083] 4) The appropriate business letter/personal
letter/card/announcemen- t or HTML template is selected; templates
are a part of the system, and provide an "HTML" shell that can be
modified to insert various sender-specific graphics and contents
into the correspondence item. This is much simpler than generating
the entire HTML programmatically;
[0084] 5) The appropriate screen resolution (72 dpi) graphics for
the stationery, card or letterhead are retrieved from the database
or from an "approved" proof copy form. References are inserted into
the HTML template;
[0085] 6) The fonts are determined from the sender's database or
from an "approved" proof copy form, and references inserted into
the HTML template;
[0086] 7) The date of the letter is composed and inserted into the
HTML template;
[0087] 8) The inside address of the letter is composed with address
book entry for the recipient (preferences) or taken from an
"approved" proof copy form and inserted into the template;
[0088] 9) The greeting is composed according to the retrieved
database settings (preferences) and inserted into the HTML
template;
[0089] 10) The body of the correspondence is formatted and composed
and inserted into the HTML template;
[0090] 11) The closing is composed according to the retrieved
database settings (preferences) and inserted into the HTML
template;
[0091] 12) The appropriate screen resolution (72 dpi) signature
graphic is retrieved from the database according to the retrieved
database settings, and reference is inserted in to the HTML
template;
[0092] 13) The printed name retrieved from the database is inserted
in the HTML template;
[0093] 14) A secretarial line is composed from sender's initials
and inserted in the HTML template for business letters;
[0094] 15) Enclosures line is added where appropriate (attachments
specified with initiating request); and
[0095] 16) A finished HTML file and associated graphics files are
posted to a web site for delivery as a text URL reference that can
be displayed by browser, and/or are posted to a multi-part HTML
email that can be displayed by HTML email programs.
[0096] Letterhead graphics require a fixed region to display and
can collapse only to a limited extent. Therefore, it is preferred
that a minimum display width be set. Any window less than the
minimum display width would have to scroll to see the letter.
Similarly, letterhead graphics can only be expanded to the width of
a real page (or perhaps somewhat larger) and retain the look
desired by the designers, so a maximum should be set. Within the
limitations of HTML, HTML deliveries are coded to display between
such minimum and maximum widths, dependent on the display
window.
[0097] A simpler variant can be used with fixed width HTML objects,
and may in some cases actually yield more desirable results than
the variable width items, such as reliable representation of a more
diverse set of fonts in the sender's correspondence item. In this
variant, the pages or surfaces of the correspondence item are
actually composed not as discrete HTML elements, but are rendered
in bit map image form as a composite image item in PNG, GIF or JPEG
(or similar format that is part of standard HTML definition), and
can be displayed as a single entity from the HTML. The pages or
surfaces can be rendered as multiple images, or combined into one
monolithic image. In this variant, steps 5-15 above are executed in
similar fashion, but rather than HTML output, they generate a
conventional bit map image of the page or surface to be
represented, which is then stored in an HTML compatible graphic
file format and is referenced in the HTML used for displaying the
correspondence item. The result is a greatly simplified HTML
representation of the correspondence item, whose dimensions are
fixed and can directly represent the equivalent printed item.
[0098] HTML Proof Copies of Correspondence Items
[0099] A sender has the opportunity to review a proof copy of the
correspondence, preferably comprising an HTML version of the
correspondence item, prior to its delivery, where various
preferences are subject to change, and where the text of the
correspondence is subject to change. This HTML version of the
correspondence is delivered as an email (FIGS. 4 and 5) or
displayed at the web site when that interface is used. The HTML
version accurately represents the graphical composition and layout
of the correspondence item, and allows the sender to approve (or
change) the correspondence to be sent. The sender can make changes
to the type of correspondence, choice of stationery and the
delivery method(s) for the correspondence, text, greeting, closing,
signature, and more (FIG. 5). The HTML proof copy of the
correspondence allows (1) the sender to approve correspondence
content (text) and appearance, and (2) to dispatch the
correspondence according to either the preset preferences for the
recipient(s) or modified preferences that the sender indicates in
the returned proof copy form.
[0100] Many email programs (such as AOL 5.0 and earlier) do not
provide support for the recent HTML email standards. Therefore,
general viewing in a variety of email programs requires a dual mode
email message that is supported by more recent HTML email programs.
In such an arrangement, the message comprises two parts:
[0101] 1) The first part of this message is a standard email, and
is read by all email programs. This part of the message is a URL
link to a World Wide Web URL where the correspondence proof copy is
posted. In most email programs, the Web browser can be activated
and the URL selected for viewing, just by selecting the link by
mouse click; and
[0102] 2) The second part(s) of the message is the HTML that
provides a complete representation of the correspondence item,
along with HTML forms and selection items that allow changes to the
correspondence and delivery methods (FIG. 4).
[0103] The proof copy for hard copy items has the following design
requirements:
[0104] 1) The proof copy image represents, as nearly as possible,
the exact image that is printed for hardcopy. This implies that
exact content of each line of text, location and appearance of
graphics, including fonts and pagination will mimic the hardcopy to
be printed;
[0105] 2) The HTML of the proof copy sets a fixed width image for
representing the item image, providing a means by which such images
will be scaled according to the physical size of the item to be
printed. A width of an American letter (81/2 inches.times.11
inches), for example, could be displayed as 612 pixels by 792
pixels, @ 72 dpi of screen resolution; this would approximate the
actual size of the paper. When a graphic is saved at 100% size at
72 dpi, it's on-screen display size is set;
[0106] 3) Font size is the other element for making an HTML letter
accurately represent a printed one. The standard Times New Roman
size, at least on Windows.TM.-based machines, seems to approximate
12-point type closely. Unfortunately, 12-point Times New Roman
displays smaller on Internet Explorer than on Netscape Navigator,
and much smaller in a Mac browser. The other problem is that Arial,
the other standard HTML font, displays substantially larger than
Times. Therefore, font sizes may be modified in the HTML letter to
overcome these variations as much as possible.
[0107] A further problem, is that in current versions of HTML, only
fonts that are loaded on the viewers system can be displayed. Thus,
alternatively, the correspondence item, including all fonts, is
fully rendered in as a bit-mapped image (preferably one image for
each page, though such pages can be combined to a reduced number of
images), which can be referenced and included in the HTML for the
proof copy. This has the advantage of superior accuracy in
controlling the selection, representation and sizing of the fonts,
avoiding the problems mentioned above;
[0108] 4) A 1 to 1 screen size is typically not optimum for
representing the content of the correspondence, and the present
invention thus provides for scaling the displayed correspondence
image. One natural representation puts all of the page on an
800.times.600 screen, and applies a scale of 75% to the above pixel
count. All other printed items are sized independently, not
necessarily in relationship to the letter size. An initial sizing
at full scale relative to 72 dpi is used, with a parameter that is
changed for each correspondence item (full size letter,
monarch/executive letter, note, announcement, postcard, etc.),
allowing scaling for optimum representation;
[0109] 5) The "edit box" of the proof copy for the body of the
correspondence shows the line breaks exactly as they appear in the
correspondence to be printed. This allows the sender to manipulate
(add/subtract/change location of) line breaks and page breaks. Page
breaks are represented in the edit box by <PAGE BREAK>
preceding the first line of text that goes on the new page. This
implies that proof copy composition does a "layout" of the hardcopy
page and determines where line breaks and page breaks occur,
inserting hard carriage returns and <PAGE BREAK> into the
HTML edit box as appropriate. This capability also requires that
the edit box be specified at a width that circumvents the forced
line wraps that HTML imposes, and that the composition module
ignore hard carriage returns in the edit box text that are returned
(and in the initial requesting email), except where they precede a
blank line. Whereas the latter case implies the start of a new
paragraph, the general case implies nothing when composing the
lines for page layout of a correspondence item;
[0110] 6) The margins for each type of correspondence item (top,
left, right, bottom) are independent, one for each type of item,
and are system parameters (preferences) that can be changed;
[0111] 7) Monarch/Executive size items utilize the same graphics as
full size (American or European), scaled down by an easily computed
ratio determined by the difference in sizes of the two items;
[0112] 8) Large Envelopes (the kind that hold an entire page
unfolded) utilize the same graphics (expanded by 20%; a changeable
system parameter) as the standard envelopes that hold a tri-folded
page;
[0113] 9) Envelopes for cards and announcements are scaled
according to a system parameter (initially set to 100%);
[0114] 10) Fax cover sheets, and one page Fax letters are composed
according to HTML document templates that are supplied by the
system and can be modified; using gray-scale versions of full-size
letterhead graphics; and
[0115] 11) Attachments to an initiating email are saved and
transmitted with the final letter.
[0116] Security for Sender
[0117] The present inventive process and apparatus optionally
provides a security mechanism for a sender to insure that forged
correspondences are not sent out erroneously. Security issues are
important with regards to generation of correspondence using online
systems connected to the Internet and utilizing email. A first
security issue is an identity assumption, and generation of a
letter falsely attributed to a particular sender or registered
sender. This problem exists because of the nature of email. Email
is issued from an SMTP server through an anonymous connection. The
issuer of an Email can set the identity of his Email program to
mimic that of another Email user, and hence, could in practice
assume the identity of a registered sender and request generation
of a correspondence to a recipient in the registered sender's
address book. The inventive process provides for several levels of
security, optionally selected by the sender, that provide security
such that identity assumption difficult, if not impossible.
[0118] A basic level of sender identity security is provided where
the inventive process generates a proof copy of the correspondence
emailed back to the sender. The sender must retrieve this email
from his or her POP server with his or her email program. In so
doing, the sender must have password-controlled access to the POP
server. This is the security mechanism that typically prevents
others from retrieving the sender's email. This is a first level of
identity security, because the sender is required to authenticate
his or her identity by retrieving and approving the proof copy. The
only ways to defeat this security is to breach the POP server
security of email, steal or otherwise obtain the password of the
registered sender's POP server, or to physically have access to the
registered sender's computer system and email program with embedded
password information.
[0119] A second, extended level of sender identity security
utilizes a Public Key/Private Key encryption system and digital
signatures. Both forms of security are available from software
providers. For example, a registered sender obtains a
Private-Key/Public-Key pair from a number of providers on the
Internet (e.g., Thawte, RSA, Verisign.TM.) that verify the identity
of the sender to some level of certainty. The sender configures his
or her email program (Netscape.TM., Outlook Express.TM.,
Eudora.TM.) to be a) digitally signed with his or her key
information, and/or b) encrypted using a double key mechanism of
encryption. The sender provides the Public Key information and the
digital signature information to the service provider of the
inventive service during the registration process, and these data
are stored in the database. The registered sender sets preferences
in the invention to reject any "unsigned" requests and/or to
receive requests in encrypted format," then initiates
correspondence requests based with digital signature and/or
encryption. The database verifies the digital signature, and/or
decrypts the request message before proceeding with fulfillment of
the request, and hence provides very strong security that the
sender of the request is indeed the registered sender, and not an
imposter. The only method to defeat this security is to physically
possess the registered sender's email program with security keys
embedded, or to have obtained the sender's public key, and
surreptitiously obtained the private key, setting up duplicate
digital signature and assumed identity in a different email program
installation.
[0120] There is further provided an optional level of security for
credit card/EFT information, signatures and generated
correspondence. Credit card information, Electronic Funds Transfer
information, high-resolution digital replicates of personal
signature(s) and copies of letters generated and sent are stored.
The prevalence of Internet security breaches by hackers is a cause
of concern for misappropriation of such information. The inventive
process is preferably configured with firewall and standard
security mechanisms. In addition, the inventive apparatus
architecture is designed such that no security sensitive
information is stored on drives that are directly connected to the
Internet and have incoming ports open. The Database server (12) is
where the sensitive information is stored. Access to the Database
server (12) from the vulnerable Internet connected systems is
preferably by SQL query protocol. Hence, to access sensitive data
the hacker would have to penetrate the vulnerable system and
interact with the Database server (12) via an SQL interface. Though
this is possible, the inventive process preferably stores sensitive
information in the database in encrypted format (e.g., credit card
information, EFT account information, high-resolution signature
graphics, and letter archives) using a commercially-available
strong encryption mechanism, such as RSA. Even if a hacker were to
succeed in retrieving such data from the database, the hacker would
then face a virtual decryption nightmare to make these data useful
(FIG. 1). Servers that do have the encryption/decryption keys and
algorithms are the Composition server(s) (17) and the Operation
server(s) (13). Composition servers 17 have no connection to the
Internet. The connection to the Web server is limited to one
strictly limited and monitored interprocess protocol. The
connection to the outgoing Email server (11) is not at risk,
because the outgoing Email server 11 cannot be penetrated from the
Internet. The Operation server 13 is preferably connected to the
Database server 12 by a monitored SQL protocol port only, and by
VPN to the Print/FAX servers 14, providing a unlikely penetration
risk. This architecture, and these connectivity methods (FIG. 1),
provide a high level of security around sensitive information that
is held in the database, and that is required for correspondence
generation.
[0121] Certain of this information needs to be accessed by the Web
Server 10, and displayed to the registered sender. For credit card
information, for example, the last 4-5 digits are stored
unencrypted and can be displayed to the registered user to identify
which account is on file. Similarly, EFT accounts involve storing
only trailing account digits. Signatures in 72 dpi, low resolution
for computer screen display are stored unencrypted, but these are
of insufficient quality to be printed and applied to correspondence
or legal documents to affect a convincing forgery, and are thus not
viewed as a security risk.
[0122] Apparatus
[0123] The invention provides software that operates on a system
comprising one or a plurality of computers connected by LAN and/or
the Internet, by which an email from a "sender" is utilized to
compose and generate a digital graphic representation of any
written communication to one or multiple recipients. The graphical
digital representation of the written communication is presented to
the "sender" for correction/revision and for a delivery method
decision. The delivery method decision will affect, where required,
a printing (onto a fixed medium of expression) of a physical
representation of the communication and any related delivery
envelopes/paperwork at a location with local access to the delivery
organization (i.e., postal mail or express courier service).
Alternatively, the delivery means can be by an electronic means
(i.e., Fax or email).
[0124] The computer system preferably comprises: (a) a first host
computer, comprising one or a plurality of databases listing
registered sender information (preferences), including, but not
limited to senders preferences and data for generating various
forms of correspondence (such as, digital representations of a
senders signature, business letterhead, preferred letter styles,
etc.); (b) optionally, a second host computer comprising one or a
plurality of databases that implement a separate "address book"
database for each "sender" and which contains "sender" supplied
data regarding preferences and data for generating correspondence
to the "addressee" (such as, email address(es), Fax number(s),
phone number(s), etc.); (c) a commercial email server to collect
and dispatch email messages, and operably connected to the first
and second host computers; and optionally (d) a commercial web site
server and software. Preferably, the inventive apparatus further
comprises Fax transmission software, such as WinFax.TM. from
Symantec. Preferably, the inventive apparatus further comprises
printer output devices, such as high quality color printers.
[0125] FIG. 1 shows a block diagram of a preferred configuration of
hardware systems to implement the inventive process. An Internet
web server 10 comprises one or more computers, connected to the
Internet 16, with appropriate firewall(s) 15. The Internet web
server 10 runs the registration and preference setting software and
stores the first database. Examples of appropriate Internet servers
10 are a Sun SparcServer.TM. with associated Unix.TM. operating
software and Cold Fusion.TM. Web server software connected to the
Internet through a commercially available firewall 15, such as a
Compaq Prosignia.TM. running Microsoft Windows NT.TM. and Microsoft
Proxy Server, or such as a Cisco 2501 Router. The inventive
apparatus further comprises a Database server 12, wherein the
database server 12 comprises one or a plurality of computers
connected to the Internet web server 10 and to an Email server 11
by a network. The network can be a private Local Area Network
(LAN), Wide Area Network or Virtual Private Network providing large
scale high volume data transmission services. A suitable Database
server 12, Email server 11 or Composition server 17, is, for
example, a Sun SparcServer.TM. or Digital Alpha Server.TM. with
associated Unix.TM. operating software and Oracle SQL database.TM.
software. The Composition server 17 comprises one or a plurality of
computers that run the correspondence composition and addressing
software as described in the inventive process. The Email server 11
comprises one or a plurality of computers that run email, and
transmit and receive software, such as Unix Sendmail.TM., as
described in the inventive process. Preferably, the Email server 11
is connected to the Internet with appropriate firewall(s) 15, and
to a Composition server 17 and to a Web server 10 by a network.
Examples of suitable networks include, but are not limited to
private Local Area Network, Wide Area Network or Virtual Private
Network. Examples of suitable Email servers 11 include, but are not
limited to, a Sun SparcServer.TM., with associated Unix.TM.
operating software and Cold Fusion.TM. Web server software
connected to the Internet through a commercially available firewall
system(s) 15. An Operations server 13 comprises one or a plurality
of computers connected to the Database server 12, the Internet
server 10, the Composition server 17, the Internet 16 and a printer
or other hardcopy output source 14 via one or several networks.
Examples of networks include Local Area Networks, Wide Area
Networks or Virtual Private Networks. The Operations server 13 runs
accounting, customer service, and production software for the
process as described herein. Examples of suitable Operations
servers include, but are not limited to, a Sun SparcServer.TM. with
associated Unix.TM. operating software and Cold Fusion.TM. Web
server software connected to the Internet in a VPN configuration
through a commercially available VPN/firewall system(s) such as a
Sun SparcServer.TM. running Unix.TM. operating software and Apache
VPN/Proxy.TM. server software.
[0126] There are also one or a plurality of Print/FAX servers 14.
The Print/Fax servers comprise one or a plurality of computers,
connected to the Operations server 13 by a network, wherein the
network is a private Local Area Network, Wide Area Network or
Virtual Private Network. A suitable existing computer for each such
Print/Fax server 14 is a Compaq Prosignia.TM. 720, with Microsoft
Windows NT.TM. operating software and Symantec WinFAX.TM. server
software, and a Xerox 55xx color laser printer.
[0127] The Internet web server(s) 10, Database server(s) 12, Email
server(s) 11, Composition server(s) 17, Operations server(s) 13,
and the Print/FAX servers 14 may be located at any location served
by the network. The location of the hard copy correspondence
production with the Print/FAX server(s) 14 is best sited to
facilitate rapid delivery to the recipient. Instead of trying to
locate a printing facility to create hard copy in each zip code,
the inventive process will locate printing facilities in overnight
courier hubs and/or in regional postal distribution hubs. In a
minimal configuration, one major delivery hub, such as Oakland
CALIF. in the United States can serve the entire world provided
FedEx, UPS, and a US Postal Service sorting and routing facilities
are commonly located there. In the preferred implementation, a
printing facility is located at the main hub of every major
delivery service. For example, FedEx uses Memphis airport as a hub
such that planes with deliveries leave each major city in the
evening and land in Memphis in the middle of the night for sorting
to the planes to deliver the items to their return cities. A
printing facility that is located in or adjacent to the hub sorting
facility, obviates the need for a large number of hard copy
printing stations throughout the country or world and substantially
reduces the time and costs to deliver the mail object. Other
suitable overnight couriers include UPS and Airborne. As further
example of maximum benefit of the inventions hard copy delivery
features, London ENGLAND or Frankfurt GERMANY would serve as an
excellent regional hub for postal or express deliveries throughout
Europe. Similarly, Hong Kong CHINA would server the entire Asian
continent well.
[0128] Correspondence Generation Process
[0129] The inventive process is designed for composition,
generation and delivery of written correspondence. Prior to
implementing a written correspondence, a sender must first
register. The registration process involves obtaining information
from the sender for the database(s). A registered sender implements
the process of sending a written correspondence to one or a
plurality of recipients by indicating the names of the recipients,
or by indicating the identifier(s) sender has associated with said
recipient(s), in an email that the sender dispatches to the
Internet domain of the system containing the invention. If
recipient(s) are not in the sender's profile, then the sender
provides address information for each recipient and the nature of
the conveyance (e.g., fax, postal mail or express courier). The
location of each recipient is determined in either the first
database having the locations of recipients associated with each
sender or is requested directly from the sender (and then added to
the first database).
[0130] The sender requests that a correspondence be created using a
template previously provided in the first database. The text of the
correspondence and desired recipient(s) can be provided with a
simple email message. Once the correspondence has been created with
the text of the email message along with template information from
the database (such as a letterhead), a graphical representation of
the correspondence is sent to the sender for review, changes (if
any) and approval. Once the final correspondence is approved by the
sender, the document is transmitted to a hard copy production
location according to the instructions of the sender, or to be
faxed or to be delivered as an HTML format. For hard copy, the
transmission can be sent, for example, to a printer located
adjacent to an express courier hub or via facsimile transmission
for hard copy creation.
[0131] FIG. 2 illustrates a hypothetical subscriber ID showing
examples of various fields and tables in the first database. These
include the upper left box that contains information concerning the
sender such as the sender's email and postal addresses, various
digital signature images, letter preferences and letterhead
graphics. The upper right hand box illustrates fields of a listed
recipient in the sender's address book. The bottom box provides
fields for structuring a reference file for each sender to be able
to access electronically images of correspondences sent and sorted
by subscriber, date, keywords in description, addresses and
recipients.
[0132] FIG. 3 shows a process for signing up new subscribers or
senders, and for processing correspondence requests from registered
subscribers of senders, and generating the end correspondence
item(s). Specifically, a sender (email user) initiates a request 30
and this request is coded with sender information from the first
database 31. The Email server 11 and Database server 12 first
determine if the sender is a registered sender 32 and if not go
through the registration process of generating a new subscriber
HTML form 33, transmitting a completed subscriber form 34 to the
Database server 12, checking the new subscriber information 35 and
completing the new subscriber registration process 36. Each
recipient (called "addressee" in FIG. 3A) needs to have an address
located either in an address book of each registered sender 37, or
the address has to be entered by going through a process of
generating a new address HTML for each recipient 38, having the
user (sender) complete the HTML form 39 and transmitting such
information to the Database server 12, and checking the recipient
address information and adding such information to the sender's
address book 40.
[0133] An intended recipient (Addressee) is identified by parsing
the pseudo email address(es) that a sender places in the "TO:" and
"CC:" fields of a requesting email that sender issues to the email
server at the Internet domain of the Email server of the invention
37. In particular, the portion of each pseudo email address
preceding the actual domain name ("@" sign and following character)
is extracted and used as A) a unique identifier that sender has
previously associated with an addressee database entry or a group
of such entries 37A, or B) a unique identifier that sender wishes
now to associate with an addressee database entry 38, or C) the
actual first and last name of an addressee, put together with no
space or with an optional separator such as underscore (" ") or
period (".") to replace space (which cannot be used with
commercially available email servers), and with optional added
separators and qualifiers such as City and/or State and/or Postal
Code and/or Country that can serve to distinguish between
individuals with the same name 37A. When the extracted portion of a
particular pseudo email address of type C) yields more than one
potential recipient, the desired recipient is determined through a
process of generating and transmitting a multiple addressee HTML
form showing the choice of recipients 37B, having the user choose
the desired recipient in the HTML form and transmit this
information back to the Composition server by HTTP or email 37C.
Once the recipients are located in the sender's Address Book
database, and their addresses obtained or accessed (A) (top of FIG.
3B), the formatting of the correspondence is determined 41 through
either an existing template in the registered sender's database or
a new template. The sender transmits through email the text of the
correspondence, and this text is incorporated into the
correspondence format to generate an HTML graphical image of the
draft correspondence 42.
[0134] The next step is to determine if a digital signature of the
sender is needed 43A and to authenticate that signature with the
sender 43B. If a security check is needed 47, an additional step is
required to provide additional security to the sender. A draft
correspondence image in HTML format (or dual mode URL pointer) is
transmitted to the sender 44, who reviews and approves 45 or makes
changes and approves 46 to finally get to the transmission to the
recipient process B.
[0135] In FIG. 3C, the correspondence is created and approved by
the sender (B). The sender has a choice (not exclusive) of delivery
methods. The sender can choose email and the relevant HTML
information will be extracted and sent to the recipient 49. The
sender can choose hard copy delivery, such as by postal or private
courier means 50, and the HTML description and components embedded
in the relevant HTML file along with any required high resolution
graphics from the database will be electronically dispatched to a
properly located Print/Fax server 14 to print a hard copy for
dispatching through the local courier or postal service 51. As a
third alternative, the sender can choose transmission by fax 52 and
the HTML file and components embedded in it will be transmitted to
the Print/Fax server 14 for telephone line facsimile transmission
to the facsimile number of the recipient 53.
[0136] FIGS. 4 and 5 show an example of a screen image showing a
proof copy of a letter for review by the sender, including a
digital image of the sender's signature, and sender's letterhead,
card or note graphics.
[0137] FIG. 8 shows a sample of the HTML email delivered
correspondence that results from approval of the proof copy of
FIGS. 4 and 5.
[0138] FIG. 6 shows a sample screen page for a sender to compose
his or her correspondence in email according to the inventive
process that resulted in the correspondence shown in FIG. 8.
[0139] FIG. 7 shows a sample screen page for a sender to compose
his or her correspondence at a web site according to the inventive
process that resulted in a correspondence proof copy similar to
that shown in FIGS. 4 and 5, and the final emailed delivery
correspondence shown in FIG. 8.
* * * * *