U.S. patent application number 10/334891 was filed with the patent office on 2003-05-29 for private, trackable urls for directed document delivery.
Invention is credited to Bandini, Jean-Christophe, Smith, Jeffrey C..
Application Number | 20030101271 10/334891 |
Document ID | / |
Family ID | 27113451 |
Filed Date | 2003-05-29 |
United States Patent
Application |
20030101271 |
Kind Code |
A1 |
Smith, Jeffrey C. ; et
al. |
May 29, 2003 |
Private, trackable URLs for directed document delivery
Abstract
A document delivery architecture dynamically generates a private
Uniform Resource Locator (URL) to distribute information. Each
private URL ("PURL") uniquely identifies an intended recipient of a
document, the document or set of documents to be delivered, and
(optionally) other parameters specific to the delivery process. The
intended recipient of a document uses the PURL to retrieve the
document. The server, upon retrieval of the document, customizes
the behavior of the retrieval based upon attributes included in the
PURL, as well as log information associated with the retrieval in a
data base. This architecture and usage of PURLs enables secure
document delivery and tracking of document receipt.
Inventors: |
Smith, Jeffrey C.; (Menlo
Park, CA) ; Bandini, Jean-Christophe; (Cupertino,
CA) |
Correspondence
Address: |
PATENT DEPARTMENT
SKADDEN, ARPS, SLATE, MEAGHER & FLOM LLP
FOUR TIMES SQUARE
NEW YORK
NY
10036
US
|
Family ID: |
27113451 |
Appl. No.: |
10/334891 |
Filed: |
December 30, 2002 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10334891 |
Dec 30, 2002 |
|
|
|
09522250 |
Mar 9, 2000 |
|
|
|
6529956 |
|
|
|
|
09522250 |
Mar 9, 2000 |
|
|
|
08832784 |
Apr 4, 1997 |
|
|
|
6192407 |
|
|
|
|
08832784 |
Apr 4, 1997 |
|
|
|
08738966 |
Oct 24, 1996 |
|
|
|
5790790 |
|
|
|
|
Current U.S.
Class: |
709/229 ;
707/E17.116; 709/203 |
Current CPC
Class: |
G06F 16/958 20190101;
G06F 2221/2107 20130101; H04L 63/0823 20130101; G06Q 10/10
20130101; H04L 63/0428 20130101; H04L 51/23 20220501; H04L 63/0236
20130101; H04L 2463/101 20130101; G06Q 10/107 20130101; H04L 51/224
20220501; H04L 67/01 20220501; H04L 51/066 20130101; H04L 63/083
20130101; H04L 51/42 20220501; G06F 21/606 20130101; H04L 63/04
20130101; H04L 63/0435 20130101 |
Class at
Publication: |
709/229 ;
709/203 |
International
Class: |
G06F 015/16 |
Claims
What is claimed is:
1. An apparatus for delivering one or more data files between a
sending computer and a receiving computer, the apparatus
comprising: a server interposed between said sending computer and
said receiving computer, wherein when said server is configured to
receive said data files from said sending computer and said server
is further configured to, in response to receipt of said data
files, store said data files, generate a private Uniform Resource
Locator ("PURL") which enables identification of said data files
and of one or more intended recipients, and provide said PURL to
one or more intended recipients of said electronic document.
2. The apparatus of claim 1, wherein said PURL identifies one or
more parameters which specify a manner which delivery of said data
files is to be accomplished.
3. The apparatus of claim 2, wherein said intended recipient of
said electronic document uses said PURL to retrieve said electronic
document.
4. The apparatus of claim 3, wherein said server, upon retrieval of
said electronic document, customizes the behavior of said retrieval
based upon attributes included in said PURL.
5. The apparatus of claim 1, wherein said server uses electronic
messaging for notification of arrival at said server of said data
files.
6. The apparatus of claim 1, said PURL comprising: a temporary,
dynamically generated uniform resource locator which identifies an
intended recipient of said data files.
7. The apparatus of claim 1, wherein said PURL attaches a general
reference to data file to be sent, and enables a recipient to
access said data file via said reference.
8. The apparatus of claim 7, wherein said server receives a request
to access said data file and provides a value added service in
connection with said access, when said recipient accesses said
document by using said reference.
9. The apparatus of claim 1, wherein access to said electronic
document requires key data and wherein said PURL comprises: the key
data.
10. The apparatus of claim 1, said PURL comprising: identification
data that identifies a recipient of said data files.
11. The apparatus of claim 10, wherein said server detects that a
specific individual has accessed said data files and records access
by said individual of said data files in a data base.
12. A document delivery system for delivering one or more data
files between a sender and at least one recipient, said system
comprising: A server that temporarily stores said data files,
wherein said server dynamically generates a private URL ("PURL")
for each intended recipient of said data files and sends each of
the PURLs to each respective intended recipient.
Description
SPECIFICATION
[0001] This is a continuation of U.S. patent application Ser. No.
09/522,250 filed Mar. 9, 2000, which is a continuation of U.S.
patent application Ser. No. 08/832,784, now U.S. Pat. No.
6,192,407, which is a continuation-in-part of U.S. patent
application Ser. No. 08/738,966, now U.S. Pat. No. 5,790,790.
FIELD OF THE INVENTION
[0002] The invention relates to the field of computer networks.
More particularly, the invention relates to techniques for the
delivery of electronic documents to users over the Internet.
BACKGROUND OF THE INVENTION
[0003] The development of computerized information sources, such as
those provided through the Internet or other on-line sources, has
led to a proliferation of electronically available information.
Currently, a user who subscribes to the Internet manually navigates
through the Internet to visit sites which may or may not be of
interest.
[0004] An inherent problem in this Internet system is that the
available information is distributed through a "pull" type
infrastructure, where the user who wants to receive information
must manually search sites of interest, or use a finder
application, to search and download appropriate information. For a
user who wishes to publish and distribute information or documents,
either an individual or a larger entity that has information that
is desired to be distributed, the present "pull" system doesn't
allow the freedom to send and distribute to a recipient or group of
recipients, in a "push" fashion.
[0005] Facsimile technology is widely used at the present time for
the distribution of simple documents, but has numerous drawbacks,
including lower quality printed documents, costly and bulky paper
copies (particularly if the recipient doesn't care to have a paper
copy), loss of content (e.g. text and graphics can't be edited or
manipulated), and time requirements for transmission, particularly
for long or complex documents.
[0006] Electronic Mail (E-mail) provides a means for sending
electronic messages from computer user to another. E-mail has
advantages of convenience, format and storage of messages for later
retrieval. As such, E-mail has been accepted and widely used for
basic communication. E-mail is typically an ASCII based format,
however, and proves to be very limiting for the communication of
long or formatted documents. As well, E-mail is not the medium of
choice for the distribution of complex documents, such as reports,
articles, advertisements and art which can include page layout
grids, postscript-formatted objects, multiple fonts with tracking
and kerning, graphics, imbedded tables and spreadsheets, and other
complicated information. Some E-mail systems provide a means for
appending an ASCII based E-mail message with an associated file, to
be downloaded along with the E-mail message. Most systems that
allow the appending of an associated file are designed to allow a
single user to send unsecured files to an associate or friend, and
neither allow for controlled automated distribution to multiple
recipients, nor do they provide advanced accounting, billing or
other such features (e.g., receipt notification). E-mail gateways
also limit the applicability of attachments, and do not solve the
problems of security and receipt notation or acknowledgment.
[0007] C. Baudoin, Interenterprise Electronic Mail Hub, U.S. Pat.
No. 5,406,557 (11 Apr. 1995) discloses an interenterprise
communications center, which has a computer hub comprising a common
core and a plurality of input and output modules. The input modules
connect to a first end user, and convert a message sent by the
first end user into a universal format. The hub core queues the
message and forwards it to the output module for conversion into
the format of the destination user. While the disclosed hub
discloses techniques to relay simple e-mail messages, it is
designed to convert the e-mail message formats, thus losing the
integrity of the original text-based file.
[0008] The disclosed prior art systems and methodologies thus
provide some methods for the delivery of documents, but fail to
provide an economical, fast document delivery system that operates
in a push-fashion, while conserving the integrity of the original
electronic file. The development of such an electronic document
delivery system would constitute a major technological advance. In
addition, the ability to distribute electronic portable high
content-quality documents to many recipients in a controlled,
economical and accountable fashion would constitute a further
technological advance.
SUMMARY OF THE INVENTION
[0009] An electronic document delivery system and methods of its
use are provided. A document delivery architecture dynamically
generates a private Uniform Resource Locator (URL) to distribute
information. Each private URL ("PURL") uniquely identifies an
intended recipient of a document, the document or set of documents
to be delivered, and (optionally) other parameters specific to the
delivery process. The intended recipient of a document uses the
PURL to retrieve the document. The server, upon retrieval of the
document, customizes the behavior of the retrieval based upon
attributes included in the PURL, as well as log information
associated with the retrieval in a data base. This architecture and
usage of PURLs enables secure document delivery and tracking of
document receipt.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] FIG. 1 is a block diagram which depicts a binary file
delivery system using one binary file server;
[0011] FIG. 2 is a block diagram which depicts a binary file
delivery system using two binary file servers;
[0012] FIG. 3 is a block diagram which illustrates key elements of
a store item;
[0013] FIG. 4 is a schematic depiction of the binary file delivery
server;
[0014] FIG. 5 provides an example of the architecture of one
embodiment of the binary file server;
[0015] FIG. 6 illustrates different types of store events employed
by the binary file delivery server;
[0016] FIG. 7 is a block diagram of the specific components within
the binary file delivery server architecture;
[0017] FIG. 8 provides a block diagram illustrating of the
architecture of the store;
[0018] FIG. 9 illustrates how the user session organizes internet
clients into three layers, including sessions, transactions, and
transports;
[0019] FIG. 10 illustrates the non-interactive tasks of a delivery,
once the send session has created a store item or another server is
forwarding a store item;
[0020] FIG. 11 provides details of the account manager
architecture;
[0021] FIG. 12 provides details of the logger architecture;
[0022] FIG. 13 provides details of the server connector
architecture;
[0023] FIG. 14 provides a functional block diagram which depicts a
portable document delivery system using one portable document
delivery server;
[0024] FIG. 15 provides a functional block diagram which depicts a
portable document delivery system using two portable document
delivery servers;
[0025] FIG. 16 illustrates how a portable document send client
application and a portable document receive client application are
used in the invention;
[0026] FIG. 17 illustrates how a server configuration user
interface application is used in the invention;
[0027] FIG. 18 illustrates how a document can be sent by the fax
gateway of a server to a printer;
[0028] FIG. 19 illustrates how a document can be sent by the
department gateway of a dedicated corporate server through a LAN to
a department printer; and
DETAILED DESCRIPTION
[0029] The binary file delivery system 10a enables corporations,
publishers and individuals to distribute documents electronically.
Importantly, unlike existing World-Wide Web ("Web") based document
publishing technologies, the binary file delivery system 10a allows
the directed and secure distribution of documents. The World Wide
Web ("Web") could currently be characterized as a pull-publishing
environment, where the consumer of documents must find and retrieve
documents from a server. Push publishing, by contrast, allows the
producer of a document to direct the delivery of documents to
consumers. Facsimile (fax), the postal service, and electronic mail
(E-mail) are all examples of push-publishing.
[0030] FIG. 1 is a block diagram which depicts a binary file
delivery system 10a using one binary file server 12. The binary
file delivery system 10a allows users to push documents, enabling
the producer of documents to direct where those documents will go.
One way that the binary file delivery system 10a achieves
push-publishing is by combining HTTP, which is usually implemented
to pull information over a network, with SMTP (which only supports
text). Additionally, the binary file delivery system 10a provides a
host of services to facilitate the various applications of directed
document delivery. At one level, the binary file delivery system
10a can be characterized as a new generation of facsimile
technology, which utilizes networks instead of telephone lines, and
moreover, introduces support for new document representations
vastly superior to existing fax formats. At another level, the
binary file delivery system 10a is a general purpose document
delivery server capable of supporting massive amounts of documents
and transactions. In all cases, the binary file delivery system 10a
provides a complete and robust solution for document delivery.
[0031] The binary file delivery system 10a is used for sending a
set of binary files from one endpoint to one or multiple
end-points. An endpoint is typically a recipient 22 with Internet
access, but can also be another entity, such as a facsimile machine
172 or a printer 178 (FIGS. 14, 15). The delivery of binary files
is accomplished in a reliable, accountable, and tractable manner.
The binary file delivery system 10a provides several levels of
security for the directed files, from E-mail equivalent security,
to better than facsimile or physical mail. The binary file delivery
system 10a also provides user account management including the
credit and debit of billing accounts. The binary file delivery
system 10a can also cooperate between multiple binary file delivery
servers 12, which may or may not be controlled by some other
authority. FIG. 2 depicts a binary file delivery system using two
binary file servers 12a and 12n, which communicate across an
Internet.
[0032] The binary file delivery server 12 (FIG. 1) operates in
three primary modes, which include a public mode, where senders 16
set up their accounts 132 (FIG. 11) themselves and are subject to
billing, a private mode, where senders 16 (FIG. 1) are controlled
by an administrator, and billing is more an internal accounting
issue than a collection issue, and a publishing mode, where there
are many recipients 22, but few senders 16.
[0033] The binary file delivery server 12 includes separate
functional components, and are not necessarily processes or shared
libraries. The binary file delivery server 12, shown schematically
in FIG. 4, includes. an intelligent storage compartment called a
store 42, which is augmented by a set of clients 44a-44n, called
store clients 44, which use the store methods and listen to the
store events, but do not interact with or know about other clients
44. An account manager 46 component is a shared service that keeps
information about the sender 16. The design also incorporates
information about recipients 22 (FIG. 1) for the case of a receive
application (as opposed to e-mail notification).
[0034] The client/server general architecture provides a better
extensibility than a more pipelined structure. It also decouples
the store clients 44 (FIG. 4) from each other, which can be useful
in the context where some tasks are interactive, while others are
more background oriented.
[0035] The Store. The store 42 contains a set of store items 48. As
shown in FIG. 3, a store item 48 includes a tree of binary files 34
and a descriptor 36, which is a set of store-defined and
client-defined attributes. The tree of binary files 34 can be
viewed as part of the store-defined attributes.
[0036] The file storage system of store 42 (FIG. 4) provides the
following functionality:
[0037] 1) Permanent storage of Store items 48 (FIG. 3) (e.g. the
binary file tree 34 contained in a store item 48 is written to
disk);
[0038] 2) Client read/write access to the descriptor 36, which is
made up of store-defined and client-defined attributes (e.g. a
client 44 (FIG. 4) can write the expiration date of a store item
48);
[0039] 3) Client notification of store events 67 (FIG. 6) (e.g.
clients 44 (FIG. 4) can be notified of the creation event 68 of a
new store item 48);
[0040] 4) Internal management according to store defined attributes
(e.g. store item expiration date generates an event).
[0041] The store 42 provides access to the store items 48 and
generates store events 67, wherein store items 48 have
store-defined attributes such as ID, creation date, file count,
file names, file data, and store events 67 can be listened to by
the clients 44. Store events 67 may include the creation 68,
deletion 69 or modification 70 of a store item 48. The events 67
play a crucial role in the architecture, since this defines how the
clients 44 synchronize their work with a very limited knowledge of
the other.
[0042] Store Clients. Store clients 44 can be of a wide variety,
and specific clients will be detailed further. In this framework, a
store client 44 is some component which uses some of the store
methods and/or listens to some of the store events 67 to perform
useful tasks on the store items 48.
[0043] Account Manager. The account manager 46 provides read/write
access to user and billing accounts, and is used by clients 44 or
other components of the system 10a. The store 42 does not use or
know about the accounts.
[0044] Other Components. Other components used by the store clients
44 and the store 42 itself are implemented within the architecture
of the system. For example, inter-server communication, log
management, and other administrative services, which is discussed
below.
[0045] FIG. 5 provides an example of the architecture of one
embodiment of the binary file server 12, including client 44
modules (52-66) that are used to implement server functions. The
Internet Send 52 is used to create store items 48 and fills in the
attributes. The Internet Receive 54 opens existing store items 48
and can be used to modify their attributes. A Fax gateway 56
listens to the creation events 68 generated by the store 42,
processes relevant store items 48, and then deletes them from the
store 42. A forwarder 58 listens to the creation events 68
generated by the store 42, and then examines the attributes of the
new store items 48, and decides if forwarding is necessary. An
archiver 60 listens to deletion events, and copies the store item
48 to secondary private storage before deletion occurs. The format
translator 62 listens to creation, examines attributes, and if
translation is needed, it reads, processes and writes back the
files in the store item 48. The web publisher 64 listens to the
creation events 68 and checks if the store item attributes
specified a Web publishing, and if so, read the attributes as
necessary. A pickup notifier 66 listens for a creation event 68,
and then notifies recipients 22.
[0046] Security Issues for Internet-based Users. While the binary
file delivery system 10a offers the flexibility to support
specialized security solutions, it readily supports current
industry-standard security solutions, including:
[0047] a) secure server interconnect and server authentication
(available with SSL 2.0, which is built into the servers
(HTTP);
[0048] b) secure Server-to-Server (on top of SSLX);
[0049] c) support end-points private key (the private key has to be
exchanged by the users using their own channels);
[0050] d) support end-points public key, using CryptoAPI or the
standard user public key. The system can also help the user
generate a public key for BFD use only, and update user account
information with it, so that the sender does not have to
communicate directly with the recipient to get the public key;
and
[0051] e) Client Authentication by the server with SSL and MS PCT
(End user can get their own certificate and be authenticated by the
servers).
[0052] An important aspect of the binary file delivery server 12 is
that it handles multiple requests in parallel and minimizes the
response time for most requests. Therefore, synchronization issues
are important, for both correctness and system performance.
Performance is enhanced by minimizing synchronized data access,
deferring to asynchronous processing whenever possible, and by
using multitasking and Inter-Process Communication (IPC) for the
platform. One embodiment of the server 12 relies heavily on
threading, which provides low overhead multitasking within one
process, and leverages multiprocessor capabilities when available.
The IPC on this embodiment uses named pipes, in addition to mail
slots or Remote Procedure Call (RPC).
[0053] FIG. 7 provides a block diagram of the specific components
within the binary file delivery server 12 architecture.
[0054] The user session 72 handles send sessions, receive sessions
(which are implemented when the user is using a BFD desktop
application 192 (FIG. 16), and 198 (FIG. 17), HTML receive sessions
(which are implemented through an HTML browser, as opposed to when
the user is using the BFD desktop 164 (FIG. 15) (note that a BFD
desktop session may go through HTML)), maintenance sessions (which
implement the account setup and maintenance sessions (e.g.
notification downloads, account setting modifications (not to be
confused with console services by an administrator, as opposed to
an end user of a public server), HTML maintenance sessions (which
implement the account setup and maintenance through an HTML
browser).
[0055] A delivery component 74 (FIG. 7) implements the background
work of making a delivery, including notification and forwarding. A
console 76 is used to implement administration sessions, which are
conducted through an HTML interface instead of a specialized user
interface. The console 76 provides a user interface to browse and
modify all the server properties, including accounts, logging,
performance, and parameter settings.
[0056] Shared Components. Shared components may be used by the
store 42, by any of the store clients 44 (FIG. 4), or they may
operate on their own. While they do not listen to store events 67
(FIG. 6), they can use store methods, as needed, for efficiency,
such as for connector receive. Shared components may include:
[0057] 1) An account manager 78 (FIG. 7) which maintains all local
account information and provides a unique access interface to local
accounts, including billing account and remote account
information;
[0058] 2) a server connector 80, which handles all inter-server
communications;
[0059] 3) a mail gateway 84, which handles the sending and
receiving of bounced mail;
[0060] 4) a logger 86, which manages access read/write to the
different logs which are classified by a type. The most important
log is the send/receive transaction log, which tracks what happens
to store items 48 (FIG. 4) over time; and
[0061] 5) an operating system accessor 82 (FIG. 7), which provides
a platform independent interface to the operating system for file
input and output (I/O), process management (synchronization,
locking, threads, process), IPC (RPC, shared memory, shared queues,
pipes), network access (TCP/IP sockets, HTTP server interfacing,
POP/SMTP interfacing). Specific portions will be implemented as
needed.
[0062] The Server Application. The server application 88 is used to
start up and shut down all pieces of the binary file delivery
server 12 (FIG. 4), according to the configuration parameters. It
also provides the administrative aspects of the server not covered
by the Account Manager (46 or 78) or by the Logger 86, such as
performance profiling, usage information and server
parameters/configuration.
[0063] FIG. 8 provides a block diagram illustrating of the
architecture of the store 42. A store manager 92 is used to
maintain global state, to synchronize access to the store 42 and to
provide housekeeping functions. A store item manager 94 is used to
maintain the state, locks, and cache mechanism of a store item 48.
A store event manager 96 is used to maintain listener lists and
event filters, as well as to dispatch events according to event
filters and event priorities.
[0064] FIG. 9 illustrates how the user session organizes Internet
clients into three layers, including sessions, transactions, and
transports. The session manager 102 maintains all the currently
active session states and performs the session related
housekeeping. It processes transactions coming from transaction
managers 108 through the uses of the store 42 and the account
manager 46. The transaction manager 108 receives raw data from the
transport managers 114, 118, and performs validation and
preprocessing using one or more BFD transaction interpreters 110 or
HTML transaction interpreters 112. The transaction manager 108 then
submits the data to the appropriate BFD session manager 104 or HTML
session manager 106, waits for an answer, and then passes the
answer back to the appropriate transport manager 114 or 118.
[0065] FIG. 10 illustrates the non-interactive tasks 120 of a
delivery, once the send session has created a store item 48 (FIG.
4) or another server 12 a-n (FIG. 2) is forwarding a store item 48.
The delivery manager 122 (FIG. 10) listens to relevant store
events, makes a forwarding decision, and coordinates work with the
notifier 66 and the forwarder 58. The server directory 124 keeps
track of the association between Email domains and server domains.
The notifier 66 is used to handle E-mail notification 20 (FIG. 2)
to the recipient 22. The forwarder 58 (FIG. 10) is used to forward
store items 48 (FIG. 4) to other servers 12a-n (FIG. 2), using a
server connector 80 (FIG. 7). Since not all E-mail notifications
may be received, an E-mail scanner is used to check the server mail
account for "returned" E-mail, and then to match it with the failed
transaction.
[0066] FIG. 11 provides details of the account manager architecture
130. The account manager 78 is used to maintain user account states
132 for the local server 12 (FIG. 1), to maintain billing account
states 134 (FIG. 11) for the local accounts 132, to query local
accounts 132, and to maintain a directory of remote accounts 136.
The primary goal of the remote account directory 136 is to
associate E-mail addresses with either BFD accounts or non-BFD
accounts.
[0067] FIG. 12 provides details of the logger architecture. FIG. 13
provides details of the server connector architecture.
[0068] System Operation. The following example illustrates how the
binary file delivery system 10a (FIG. 1) or 10b (FIG. 2) is used to
distribute electronic information from a sender 16 to a receiver
22. A hypothetical publisher, Sam in Redwood City, Calif., wishes
to send a document to an associate, Rob, in Tokyo, Japan. The
following progression of events illustrates how this is achieved,
in a controlled fashion.
[0069] Sam connects to a local server in Santa Clara, Calif. Sam's
BFD desktop opens a connection to a local server 12a (FIG. 2) in
Santa Clara, where his user account resides. The session manager
102 queries the account manager 78 to validate the user of sender
16 (Sam). The session manager 102 (FIG. 9) then creates a send
session state for the user of sender 16.
[0070] Sam's Send Session. Sam's BFD desktop sends transaction
details, such as the number of files, file size, and intended
recipients. The session manager 102 (FIG. 9) attaches this data to
the session state. Then the session manager 102 creates a store
item 48 (FIG. 3) descriptor 36 in memory, and reserves disk space
with the store 42 (FIG. 4), as well as a store item ID. Then the
upload starts. The session manager 102 (FIG. 9) spools the data
directly to a file with asynchronous I/O.
[0071] When the upload 18 (FIG. 2) of all of Sam's files is
complete, the session manager 102 (FIG. 9) updates the store item
descriptor 36 (FIG. 3) to the disk asynchronously, and then inserts
the store item 48 (FIG. 4) asynchronously into the store 42.
[0072] The session manager 102 (FIG. 9) answer's Sam's upload with
an acknowledgment, and provides information regarding the
transaction. This session then ends.
[0073] At the Santa Clara Store. The insertion of the store item 48
(FIG. 4) is logged asynchronously in the logger 86 (FIG. 7) by the
store 42. The store 42 then runs the store item descriptor 36 (FIG.
3) against the registered event handlers filters. For each match,
it inserts the event and notifiee (Rob) in its event queue. Then
that thread dies.
[0074] The event dispatch thread pulls the events, and dispatches
them asynchronously to the notifiee at rate, depending on the
tuning parameters of the system.
[0075] The Santa Clara Delivery is Notified. The delivery manager
74 (FIG. 7) is notified of a relevant event and starts a thread
which waits on the lock of the store item 48 (FIG. 4) via a
synchronous transaction with the store 42. Once the lock is
secured, the thread reads the store item descriptor 36 (FIG. 3),
and the delivery manager 74 (FIG. 7) analyzes the store item
descriptor 36, to decide how to handle the store item descriptor
36. In this illustrative example, the recipient 22 (FIG. 2) is in
the Japan domain, where another BFD server 12n is located. The
delivery manager 74 (FIG. 7) found this out by querying a server
directory 124 (FIG. 10). The manager then decides to forward the
store item 48 (FIG. 4). The forwarder 58 (FIG. 10) asynchronously
asks the Connector 80 to do a forward to Tokyo. Then the thread in
the delivery manager 74 (FIG. 7) dies. Note that the delivery
manager 74 (FIG. 7) does not know about the server protocols.
[0076] The Santa Clara Connector 80 is going to forward the Tokyo
Connector 80. A thread handling the delivery request is eventually
started in the Connector 80. The thread knows the host, and has a
lock on the store item 48. The thread initiates the connection with
the Tokyo server 12n. If the thread cannot connect, it goes to
sleep for a while. Eventually, the connection opens, and the
connector 80 enters the protocol interpreter, which eventually
transfers the store item descriptor 36 (FIG. 3) and the associated
binary data files 34. Then the connector 80 (FIG. 7) closes the
connection and logs a successful forward to the Tokyo server 12n
(FIG. 2) in the logger 86 (FIG. 7). Then the connector 80 releases
the lock on the store item 48 (FIG. 4) in the store 42 after having
marked it as forwarded.
[0077] On release of the lock, the store 42 runs the store item
descriptor 36 (FIG. 3) against the event filter list and finds an
event filter that is handled locally. A successfully forwarded
store item 48 causes a reference count decreased by 1. In this
example, there is only one recipient 22 (FIG. 2), which means the
count goes to zero, Therefore, the store 42 (FIG. 4) can move the
store item 48 to a deletion list. A housekeeping thread of the
store 42 will then purge the Store Item 48 at some point.
[0078] A thread in the Tokyo connector receiver 80 (FIG. 7) is
begun, to handle the connection. Once the protocol interpreter
understands it as a forward, it asks the store 42 for a store item
ID 36 (FIG. 3) and the respective committed storage space. The
actual store item descriptor 36 and files have been written to disk
as it was receiving the data.
[0079] Once the connection is complete, the store item 48 (FIG. 4)
is inserted asynchronously into the store 42 of the Tokyo binary
file delivery server 12n (FIG. 2).
[0080] Tokyo Delivery Component begins. The Tokyo store 42 (FIG.
7), on insertion, has generated an event which is going to be
handled by a thread of the delivery. It has also logged the
insertion of the new item in the logger 86. The manager 102 in
delivery 74 realizes this has been forwarded, and that it will be
received from this server 12n (FIG. 2).
[0081] The server 12n queries the account manager 78 (FIG. 7) to
see if there is an account associated with the E-mail address of
Rob. If there is no associated account with Rob E-mail, then an
E-mail is sent to Rob, with an URL which indicates the store item
ID 36 (FIG. 3). It also queues an asynchronous request for the
connector 80 (FIG. 7) to notify the Santa Clara server 12a (FIG. 2)
that Rob has been notified. If Rob has an account here, then the
delivery puts an asynchronous update request with the account
manager 78 (FIG. 7) to mention the pending delivery; in this case
the scenario is continued.
[0082] Rob connects to the Tokyo Server to check on new documents.
When Rob opens its receive session, the session manager 102 (FIG.
9) synchronously checks the Rob account for validity, and in the
process it updates the session state, to remember that the account
is flagged with a pending receive. The BFD desktop of Rob
eventually asks for the document to be received. The session state
has the answer and says yes.
[0083] The Rob desktop 170 (FIG. 14) asks for the receive, and the
session manager 102 (FIG. 9) synchronously asks the store 42 (FIG.
4) for the lock on the relevant store item 48. Once granted,
session manager 102 (FIG. 9) can answer by sending the first
portion of data. Once the document is downloaded, session manager
102 (FIG. 9) asynchronously logs a successful receive with the
logger 86. Then session manager 102 (FIG. 9) puts an asynchronous
request with the connector 80 to notify the Santa Clara server 12a
of the final delivery.
[0084] At the receive session in Tokyo, the session manager 102
(FIG. 9) releases the lock, and puts an asynchronous delete request
to the store 42 (FIG. 4). The Rob receive session then terminates.
The connector 80 (FIG. 7) in Santa Clara runs the protocol
interpreter, which says that the notifications must be queued to
the logger 86.
[0085] Sam checks on Status. Sam connects to do a receive session
followed by a maintenance session. The maintenance session 72
receives a request to check on the status of the sent document. The
maintenance session 72 synchronously submits a query to the logger
86 using the store item ID 36 (FIG. 3) that was passed down to the
Sam desktop at send time. The query returns the lists of matching
records, which are processed and passed back to the desktop, which
can then update the user interface of sender 16 (FIG. 2).
[0086] Portable Document Delivery System. Electronic portable
documents are becoming increasingly popular. These files can be
distributed to different platforms without losing their original
look and feel. Adobe Systems' Acrobat PDF.TM. and Novell's
Envoy.TM. portable document formats have come into widespread use.
In a preferred embodiment of the invention, a portable document
delivery systems 160a,b (FIGS. 14 and 15) achieve a universal
solution to the delivery of electronic documents, by applying
portable document technology to the Internet. The portable document
delivery systems 160a,b provide complete compatibility with
portable electronic document formats, including Novell's Envoy.TM.
and Adobe System's PDF.TM. formats.
[0087] Recipients 22 of portable documents from the portable
document delivery systems 160a,b can view, search, print, archive,
or export information from their documents. Documents distributed
using Envoy.TM. or Acrobat.TM. in conjunction with the portable
document delivery systems 160a,b, preserve complete visual fidelity
and may be produced on high resolution output devices with the
highest level of quality and resolution. Portable document formats
allow preserve content and color of the information within a
document, and many formats allow indexing, searching, and hypertext
linking, while allowing the file to be stored in a compact
manner.
[0088] FIG. 14 is a functional block diagram which depicts a,
portable document delivery system 160a using a binary file delivery
server 12. FIG. 15 provides a functional block diagram depicting a
portable document delivery system 160b using two binary file
delivery servers 12a and 12n communicating over the Internet.
[0089] To address the limitations of the Web and electronic mail,
in addition to providing additional services, the portable document
delivery systems 160a,b include server software which runs on top
of existing electronic mail, HTTP server software, and database
systems. Thus, the portable document delivery systems 160a,b
combine industry standard solutions for the electronic mail, Web,
and database to enable corporations and users to direct the
delivery of documents to recipients.
[0090] The following disclosure elaborates on the requirements for
a universal document delivery solution, as well as the specific
components of the portable document delivery systems 160a,b.
[0091] The portable document delivery systems 160a,b combine three
basic components to provide a solution to universal document
delivery.
[0092] 1) Portable Document Send Client. A portable document send
client (PDSC) 192 (FIG. 16) integrates all desktop applications 190
directly with the portable document delivery systems 160a,b. The
PDSC 192 is not required for all embodiments of the invention.
Publishers who simply wish to leverage the BFD server 12 directly
are free to do so. The PDSC 192 is intended for the standard
corporate computer user who requires a point-to-point to the
delivery problem.
[0093] 2) Binary File Server. The binary file delivery server 12
works on top of Internet standards to deliver documents to
recipients. The BFD server 12 can be invoked transparently through
the portable document send client (PDSC) 192, or can be invoked and
customized directly using a server configuration user interface 198
(FIG. 17).
[0094] 3) Portable Document Receive Client. The portable document
receive client (PDRC) 194 is the software component which
recipients 22 of documents utilize to receive, view, and print
documents. Recipients 22 who do not have the PDRC software 194 will
be given links to access the software directly over the Internet.
In most cases, the, PDRC 194 will behave simply as a Netscape
NAVIGATOR.TM. Plug-in or a Microsoft ActiveX.TM. control or a Java
Applet, thus directly integrating the PDRC 194 with the recipient's
existing browsers.
[0095] FIG. 16 illustrates how a portable document send client
application and a portable document receive client application are
used in the invention. FIG. 17 illustrates how a server
configuration user interface application is used in the
invention.
[0096] Portable Document Delivery System Requirements. At the most
basic level, a document delivery solution must enable documents to
be directed to customers by the producers of those documents, or
"pushed". The portable document delivery systems 160a,b are
designed so that different types of recipients operating on
different computer systems, with different operating systems,
E-mail systems, and document types can all benefit from receiving,
reading, and using electronic portable documents. The various
design parameter categories that the portable document delivery
systems 160a,b are adapted for includes primary computer systems
(e.g. PCs, Workstations, Servers), primary operating systems (e.g.
Macintosh, Win 3.1, Win'95, NT, Unix, OS/2), electronic mail
systems (e.g. Microsoft, cc:Mail, Groupwise, Notes, Eudora),
document types (e.g. paper, Postscript, Quark, WordPerfect, Excel),
and user types (e.g. MIS, Legal, Financial, Consumers/Home,
MarketingCommunication (MarCom)).
[0097] A unique aspect of the portable document delivery systems
160a,b are the level of compatibility the solution provides with
all computer systems, operating systems, electronic mail systems,
and document types, In one embodiment of the invention, the sender
16 and the receiver 22 of a document are both connected to the
Internet. In a preferred embodiment of the invention, the portable
document delivery systems 160a,b provide not only an Internet
delivery solution, but also backward compatibility with facsimile
machines 172 (FIGS. 14 and 15) and printers 178, as well as forward
compatibility with future distribution print architectures.
[0098] Universal Delivery. Delivery solutions must enable users to
distribute documents to anyone, which requires support for a
variety of computing platforms, compatibility with facsimile 172,
and compatibility with future distributed printing architectures.
The portable document delivery systems 160a,b can support the
conversion and delivery of complex postscript files. Documents can
be delivered to any recipient 22 who has an E-mail account and
access to the Internet, regardless of the recipient's platform or
E-mail system.
[0099] Security. Typical applications of document delivery require
complete security from the origin of the document complete to the
destination. This requirement becomes more pervasive as documents
begin to travel across open and wide area networks. The portable
document delivery systems 160a,b employ several levels of security.
The Portable Document Send Client 192 (FIG. 16) authenticates and
creates a secure socket to upload information to the server 12.
Thus, non-BFD servers cannot intercept documents. Additionally, The
PDSC 192 allows the sender 16 to use private and or public
encryption to guarantee that only the intended recipients of a
document can access those documents. Even in cases where encryption
is not used, the portable document delivery systems 160a,b include
sophisticated algorithms to prevent unauthorized users from
accessing documents.
[0100] Account Management Services. In many instances, document
delivery applications cater to businesses where each sender 16 or
recipient 22 of a document must be maintained. Consider the case of
periodically delivering the documents to the same group of a
hundred thousand recipients 22. The sender 16 of the document
requires tools to update and manipulate the database of the large
subscription/distribution base.
[0101] The portable document delivery systems 160a,b enable
publishers 16 to create accounts on BFD servers 12 and then
associate transactions with specific accounts 132, 134, 136 (FIG.
11). The system also enables publishers to consolidate several user
accounts into a single billing account 134. Additionally, it allows
publishers to associate a specific billing code with transactions
which may be consolidated in transaction reports. For example, a
law firm could create an account and then a billing code for each
client, associating a billing code and account with each document's
transaction. The portable document delivery systems 160a,b maintain
and update the account information automatically. A portable
document delivery systems 160a,b reporting engine then allows the
user to create a report for a given account or for a specific
billing code. Such a scheme facilitates client management as well
as billing.
[0102] Transaction Management Services. Related to account
management is the requirement of transaction management. Not only
is it necessary to maintain the database of senders 16 and
recipients 22 of documents, it is also necessary to provide
services to manage the transaction of sending documents.
[0103] For example, a sender 16 may want to know if the document
was actually delivered and actually received, and perhaps who
received the document. In many instances, the publisher 16 would
like to charge postage for delivery and will therefore require
services to maintain and update accounting information associated
with the delivery transactions.
[0104] The portable document delivery systems 160a,b are able to
create logs associated with each send transaction, and maintain
these logs. Each transaction, or document send operation is
associated with a specific account. Users 16 can query transaction
information directly from the server.
[0105] Reporting. Account and transaction management provides no
value unless sophisticated means of reporting are provided, For
example, users 16 can be provided with a full report of a given
transaction, including such information as which documents were
delivered to whom, how many users have confirmed delivery of the
document, or for billing purposes, the costs associated with the
transaction.
[0106] Scalability and Bandwidth. Because of the large scope and
application of document delivery applications, the portable
document delivery systems 160a,b are capable of expanding their
capabilities to service millions of documents or recipients 22.
Several aspects of the delivery process occur in real time, while
other aspects may be deferred or scheduled. In many cases, the
portable document delivery systems 160a,b dynamically extend the
amount of bandwidth or sets of servers 12a-n deployed to achieve
the necessary throughput for document delivery.
[0107] The portable document delivery systems 160a,b are scalable
to conform with user requirements. The server software is designed
to support the sending of millions of documents per day, and is
able to exploit whatever bandwidth has been dedicated to a given
server. For example, one current BFD server 12 effectively utilizes
10 Megabit/second bandwidth. The various processes running on BFD
servers 12 operate asynchronously, thus allowing for optimal
performance on multi-processing servers 12, as well as
sophisticated scheduling of the servicing of a given transaction.
Special care is taken to operate in real time, particularly for the
access of documents from the server 12 by recipients 22.
[0108] BFD servers 12 can also distribute work loads across other
servers 12a-n (FIG. 15). A preferred embodiment of the invention
allows individual processes running on a single server 12 (FIG. 14)
to be distributed across a collection of servers 12a-n. In this
embodiment, account management processes could run on one server
(e.g. 12d), while the logging, reporting, transaction management,
send, propagate, and retrieve processes run on another server (e.g.
12h).
[0109] Portable Document Send Client Specification. The Portable
Document Send Client (PDSC) 192 (FIG. 16) allows any computer user
to distribute documents directly from the desktop of any personal
computer, such as a PC or Macintosh computer. The PDSC 192
integrates directly with all applications 190 through the uses of
virtual printer devices, thus enabling the PDSC 192 to be
compatible with all applications 192 and formats. Importantly,
because the PDSC 192 is integrated directly with portable document
technology, the sender 16 of a document need not make assumptions
about the capabilities of the intended recipient 22 of the
document.
[0110] The PDSC 192 allows two primary modes of usage: print or
"drag and drop". By print, a sender 16 can simply select the print
option from any application 190 and trigger the sequence of events
to generate a portable document, and then address and send that
document. From the user's perspective, they simply select the print
command and are then prompted for the destination of the document
using standard addressing interfaces and address books. A Microsoft
Mail.TM. user, for example, would be prompted with the standard
Microsoft Mail.TM. addressing dialog to direct where a document may
be sent. After selecting the destination of the document, the PDSC
192 automatically connects to a BFD server 12 and securely uploads
the documents 166 (FIGS. 14 and 15) and the intended list of
recipients 22, as well as any other attributes selected to
customize the send. "Drag and Drop" usage allows users 16 to avoid
launching applications and printing to send documents; the document
may simply be dropped on a PDSC 192 (FIG. 16) send icon, which is
accessible from the sender's desktop 164 (FIGS. 14 and 15).
[0111] Additional functionality and customization is one click
away. During the addressing process, users of senders 16 are free
to customize the options of their send by invoking advanced
options. By default, each send will reuse the existing parameters
for sending documents. Users of senders 16 can also use the
advanced options user interface 192 to customize their delivery
options, including, for example, security options and receipt
requirements. For example, if the user 16 desires to customize the
security options, including private and or public key encryption,
the user simply checks a "Public Encrypt" or "Private Encrypt"
option. Similarly, the user can select the "Notify on Receipt"
option, thus informing the BFD server 12 to confirm delivery when
the document is actually received.
[0112] BFD Server Configuration Options and User Interface. The BFD
Server 12 can be configured and customized directly from a sender
desktop 164 (FIGS. 14 and 15). The access to the BFD server 12 from
the desktop is achieved using an HTML forms user interface. This
user interface exists to give server administrators access and
control over the advanced options of the BFD server 12. For
example, a server administrator might update the database of the
100,000 recipients who are intended to receive a specific document,
and then directly invoke the send of the document to those
recipients. The server administrator might generate a report
regarding the send transactions which occurred during the previous
week.
[0113] To access the BFD server 12 from the desktop 166, a user 16
must have a special account created on the BFD server 12, which is
created ahead of time by the BFD server 12. Additionally, accessing
the BFD server 12 over this account requires several layers of
authentication and security, thus preventing unsolicited
access.
[0114] The Server Configuration User Interface 198 (FIG. 17) allows
the user 16 to access and control the server settings, which may
include transaction management, account management, reporting
facilities, direct upload and download of documents to distribute,
direct manipulation of recipient lists, and direct access to send
options.
[0115] Portable Document Receive Client. The recipient 22 (FIG. 16)
of a document can utilize the portable document receive client
(PDRC) 194 to access and manipulate documents which were sent to
the recipient 22 by the portable document send Client 192 or by the
BFD server 12 directly via the BFD server administrator. In the
event that the recipient 22 of a document does not already have a
PDRC 194, the software may be downloaded and installed directly
from the Internet. The architecture of the portable document
delivery systems 160a,b simplify this process, and employ dedicated
software and scripts, in addition to advents in new browser
architectures to enable first-time recipients 22 to be one click
away from accessing the necessary software to receive
documents.
[0116] The most basic case of the portable document receive client
194 can simply function as browser extension, such as a Netscape
NAVIGATOR.TM. plug-in or a Microsoft ActiveX.TM. control. For other
users, the PDRC 194 will behave as a stand alone application which
works as a helper application.
[0117] A third application exists for portable document delivery
systems 160a,b customers who prefer direct access to the portable
documents from the recipients desktop 170. In this configuration, a
dedicated portable document receive client 194 (FIG. 16) can be
downloaded directly from the Internet. This component will
continually monitor the activity of the portable document delivery
systems 160a,b, and will automatically extract any incoming
portable documents from BFD servers 12, and open them for immediate
document communication on the computer desktop 170 of the recipient
22.
[0118] Recipients 22 of portable documents from the portable
document delivery systems 160a,b, depending on the send
configuration options, will be allowed to view, search, print,
archive, or export information from their documents. Documents
distributed using Envoy.TM. or Acrobat.TM. in conjunction with the
portable document delivery systems 160a,b will preserve complete
visual fidelity and may be produced on high resolution output
devices with the highest level of quality.
[0119] FIG. 18 illustrates how a document can be sent by the fax
gateway 56 of a BFD server 12 to a printer 178. FIG. 19 illustrates
how a document can be sent by the department gateway 202 of a
dedicated corporate BFD server 200 through a LAN 204 to a
department printer 178.
[0120] Private, Trackable URLs for Directed Document Delivery. This
embodiment of the invention provides a unique means of delivering
documents electronically. Importantly, this embodiment of the
invention enables a number of value added services, in addition to
basic document delivery, including but not limited to tracking and
security.
[0121] The invention provides a document delivery architecture
which dynamically generates a private Uniform Resource Locator
(URL) to distribute information. Each private URL ("PURL") uniquely
identifies the intended recipient of a document, the document or
set of documents to be delivered, and (optionally) other parameters
specific to the delivery process. The intended recipient of a
document uses the PURL to retrieve a document (or documents). The
server, upon retrieval of the document, customizes the behavior of
the retrieval based upon attributes included in the PURL, as well
as log information associated with the retrieval in a data base.
This architecture and usage of PURLs enables secure document
delivery and tracking of document receipt.
[0122] The World Wide Web ("Web") enables consumers to retrieve
content from Web servers using Web browsers. In short, consumers
pull content from the Web. E-mail enables producers of content to
send that content to consumers. In other words, producers push
content with e-mail. E-mail Internet servers, as well as the SMTP
protocol (simplified mail transport protocol) which governs the
behavior of Internet servers, are limited capabilities they provide
to users of the Internet. For example; SMTP e-mail servers do not
know anything about binary file types, tracking, or security.
[0123] The Web and the associated HTTP protocol, by contrast,
provides a flexible protocol that enables the efficient, secure
transmission of binary information. HTTP, however, is a pull,
consumer driven protocol, and hence a producer or sender of
information cannot rely on HTTP exclusively to direct the delivery
of information.
[0124] By combining HTTP for the delivery, as well as using
SMTP/e-mail for notification, it is possible to build a solution
that allows the producer to be the driver, or to push, but that
does not suffer from the limitations and legacy issues associated
with SMTP/e-mail.
[0125] PURLs are temporary, dynamically generated uniform resource
locators which uniquely identify the intended recipient of a
document and the document itself, as well attributes associated
with the delivery of a document. PURLs avoid attaching information
to e-mail messages to send documents, but rather attach a general
reference to a document to be sent, and then enable the recipient
to access a document via the reference.
[0126] When the recipient accesses the document by using the
reference, a server can intercept the request to access the
document and provide value added services, such as tracking and
security. For example, a user can include a key in the PURL that
serves to unlock a document on a server, perhaps decrypting an
encryped document. Or, a user can include a unique identification
number in the PURL that identifies the recipient. In this case, the
server can notice that a specific individual has accessed a
specific document, can note that in a data base, and can make that
information available to the sender. This embodiment of the
invention can therefore provide document tracking.
[0127] FIG. 20 is a block diagram which depicts a document delivery
system that includes private, trackable URLs for directed document
delivery according to the invention. A document 310 is forwarded
from a sender 300 to a server 315. The server temporarily stores
the document. The server dynamically generates a URL for each
intended recipient of the document. In addition to encoding user
information and document information with the URL, the server also
encodes delivery parameters, or transaction identifiers in the URL.
Each generated personal URL (PURL) is then forwarded to each
intended recipient 320. The recipient is notified 325 that a given
document has been sent to him. This typically has the form of an
e-mail message which includes a private URL. The recipient, using
the PURL 330 and the Web, accesses the document.
[0128] When the recipient accesses the document via the PURL, the
recipient presents the PURL to the server. The server then has the
opportunity determine the next set of actions. For example, the
server could notice that the PURL specifies that a password must be
presented before the electronic document referenced by the PURL can
be accessed. The server may also identify the specific recipient
accessing the document by the PURL, and log the fact that the
specific recipient has attempted access the specific document,
again all identified by the PURL. The server may also log the fact
that the entire document was delivered successfully
[0129] Accordingly, a data base maintained on the server has a full
log describing the following, for example:
[0130] Who accessed the document;
[0131] When they accessed the document; and
[0132] Whether they successfully accessed the document.
[0133] This information which the server has logged can then be
reported back to the sender of a document. Hence, using a
combination of e-mail for notification, the Web for delivery, and
private URLs to identify recipients and documents, a delivery
server can be constructed to track documents and report the
delivery state of a document back to the sender. The actual
implementation of such 25 system may be in accordance with the
system herein described in connection with FIGS. 1-19, or it may
take other forms as appropriate.
[0134] In other embodiments of the invention, the server can log
other types of information. Thus, the server can log the IP address
associated with a given 30 recipient who is retrieving a document.
The server can also log the IP address of any subsequent accesses
to a given document with the same PURL. Thus, the server could
prevent multiple IPs from accessing the same document using the
same key. Alternatively, the server could provide a list to the
sender containing IP addresses which accessed a specific document
intended for a specific recipient.
[0135] The above described architecture for delivery also
facilitates security. A document can remain encrypted on the server
until a recipient presents a valid key to access and decrypt a
document. This key is presented as encoded in part of the PURL.
Alternatively, the PURL specifies that a key must be retrieved, in
which case the server requires that the recipient present a unique
password to decrypt the document. In the first case, retrieval of
the encrypted document is a one-step, automatic process because the
key is encapsulated in the PURL.
[0136] PURL Implementation.
[0137] First, consider the potential construction of a PURL. The
following diagram outlines one specific example of a PURL:
[0138] http://posta.tumbleweed.com/cgi/posta.dll?
pu=0-233-33982-FIAAAV4
[0139] The above PURL denotes the following:
1 Value Meaning http:/ Use the HTTP protocol to access.
posta.tumbleweed.com Name of the HTTP server. cgi/posta.dll Name of
HTTP server extension. pu = O Don't use a password. 233 Store item
Identifier. 33982 Recipient Identifier. FIAAAV4 Key to access the
document.
[0140] With further reference to FIG. 20, it should be noted that a
PURL 302 is shown having various fields. These fields include a
password identifier 331, a store item identifier 332, a recipient
identifier 333, a document key 334, and any other optional fields
that may be desired 335. These fields are discussed in greater
detail below.
[0141] Password Identifier. A password identifier specifies whether
a password is required to access a given document. In this case,
the value "0" indicates no password is required. A value of "1"
indicates a password is required.
[0142] Store Item Identifier. A store item identifier uniquely
identifies which document a given recipient desires to obtain. In
this case, the value "233" provides an index into a sparse table on
the server, identifying a value which, e.g. identifies where a
given document resides on the server and/or what a document is
named.
[0143] Recipient Identifier. A recipient identifier uniquely
identifies the intended recipient of a given document. In this
case, the value "33982" provides an index into a sparse table on
the server. The value at this table index contains recipient
information.
[0144] Document Key. The document key validates the PURL itself. In
this case, the key is a randomly generated number associated with
the given recipient and store identifiers. The key is used to
validate whether the given recipient identification number is
valid, whether the given store identification number is valid, and
whether the given recipient with the given store identification
number should be granted access to a document. In other embodiments
of the invention, the key also encodes an index into a table which
contains the validation information, as opposed to encoding the
validation information itself.
[0145] Importantly, the server has a Web extension, enabling the
HTTP processing of a document to be extended to provide
customization. Thus, the recipient accessing the document goes
through an HTTP server extension to communicate with an HTTP
server. This extension, for example, can decide to grant access to
a document, in which case it presents the user with a new PURL
which facilitates transmission of the specific document.
[0146] The server can use the above attributes and values of a PURL
to customize the behavior of document delivery. Specifically, the
server executes the following steps to deliver the document and
record the delivery transaction:
[0147] Decode the PURL into its various parts;
[0148] Validate each component of the PURL;
[0149] Authenticate the PURL using the key;
[0150] Determine which user is accessing the document by using the
Recipient Identifier;
[0151] Determine which document the user is accessing by using the
Store Item Identifier;
[0152] Determine whether the document, given the above, requires
additional input before it can be delivered;
[0153] Deliver the document to the recipient;
[0154] Log all attributes of the transaction, including, e.g time
of access, success of transmission, and IP of recipient.
[0155] Once information has been logged in a data base running on
the server which records transaction information, this data can be
accessed by the recipient and can even be dynamically transmitted
back to the recipient. For example, a given publisher (sender) asks
the server's data base for all documents which have been delivered
to a specific recipient. The publisher asks the server to generate
a report of the status of a given document sent to ten people. The
server reports back, for example, that the document has been sent
to all ten people at a specific time, but only three of the people
have actually retrieved the document. Each document retrieval may
include the specific time the document was accessed, the time it
was accessed, and whether it was accessed completely and
successfully. Hence, dynamically generated PURLs as broadcast over
email enable a robust means of tracking the delivery of documents
over wide area networks.
[0156] Although the electronic document delivery system and its
methods of use are described herein in connection with use in the
Internet, the invention may be applied to any of a wide variety of
networks, including internets, intranets, LANs and WANs, or any
combination thereof, as desired. As well, the invention may be
applied to a wide variety of computer platforms, communication
protocols, portable document formats, or any combination thereof,
as desired.
[0157] Although the present invention has been described in detail
with reference to a particular preferred embodiment, persons
possessing ordinary skill in the art to which this invention
pertains will appreciate that various modifications and
enhancements may be made without departing from the spirit and
scope of the claims that follow.
* * * * *
References