WO2000062220A1 - Collaborative creation, editing, reviewing, and signing of electronic documents - Google Patents

Abstract

A virtual signing room facilitates the collaborative creation, editing, reviewing, and signing of electronic documents by parties situated in remote locations. Access to selected parts of documents is provided. The virtual signing room accepts and processes digital signatures coupled with secure authentication of parties to implement document signing. Audit trails and revision tracking are also enabled.

Description

Collaborative Creation, Editing, Reviewing, and Signing of

Electronic Documents

Cross-Reference to Related Applications

Background of the Invention

Field of the Invention

The present invention relates generally to electronic documents, and more

particularly, to an Internet facility for the collaborative creation, editing, reviewing

and signing of electronic documents.

Identification of Copyright

A portion of the disclosure of this patent document contains material that is

subject to copyright protection. The copyright owner has no objection to the facsim¬

ile reproduction by anyone of the patent document or the patent disclosure, as it ap¬

pears in the Patent and Trademark Office patent file or records, but otherwise re¬

serves all copyright rights whatsoever.

Description of the Background Art

E-commerce, and more recently e-business, is rapidly becoming the watch¬

word for businesses in this millennium. The appeal of a completely paperless trans¬

action is obvious— reduced storage costs; instant global access to transaction data;

the creation of an audit trail; lower transaction costs and the merging, filtering, and mining of data. Not only will businesses benefit from paperless transactions, but also

a number of other institutions, such as courts, financial institutions and government

agencies.

A few problems need to be addressed, however, before widespread accep¬

tance of paperless transactions is possible. First, there is a need for an Internet facility

or "virtual space" that enables multiple users to share, edit and review documents,

wherein each user may be located at different geographical locations. Second, there

is a need for a virtual "signing room" that enables real-time access to each of the

documents that must be signed to complete a transaction. Finally, there is need to

monitor and store actions performed on the documents in order to monitor the

transaction for completeness and later legal review.

The problem of enabling multiple users to share, review and edit documents

is a key problem for establishing a forum for creating binding legal relationships be¬

tween geographically diverse entities. For example, a company in Utah may wish to

receive funding from several venture capitalist firms in California, Florida and New

York. As these agreements are often hotly contested, the ability to review the edits of

each of the other parties involved in the transaction, as well as the ability to further

modify the documents to bring them in line with expectations, is an essential re¬

quirement. In order to avoid the creation of conflicting documents in most transac¬

tions today, there is often a lead party that may attempt to represent these diverse

interests and serves as the document "holder". The document is often e-mailed to

each party whenever any revisions are made in spite of the fact that not every party

may be affected by or interested in the revisions. More importantly, the lead party may not accurately represent the interests of the junior parties; longer delays may

thus result due to individual edits performed by each party separately, each of

which must then be reviewed separately by each of the other parties and their re¬

spective legal counsel. By the time each party's counsel gets an opportunity to re¬

view the document, another party in the transaction may have revised the docu¬

ment. The traditional way to avoid these difficulties is to simply assemble all of the

parties together in a physical meeting room at a single geographical location. Such

an approach may be unfeasible or expensive (due to time and travel cost), and may

even result in termination of the deal as a result of the excessive burdens associated

with imposing such meetings on all parties involved.

A second problem associated with conventional methods for transacting

business is the difficulty in reviewing and agreeing to each of the deal documents

involved in the transaction in a timely manner. In a corporate acquisition, for exam¬

ple, there are often several separate agreements that may impact an executive of a

company being acquired. The agreements may include a stock transfer agreement,

an assignment of intellectual property, an employment agreement and the primary

acquisition agreement. Each of these agreements must be signed before the deal is

complete. It is standard practice today to fly each of the interested parties out to a

single geographical location and to use multiple legal assistants to track down each

party and await the review and signature of each party. This process is time-

consuming, as each party that signs the agreement must review the agreement and,

since several parties are often required to sign the same agreement, each must have

individual possession of the agreement during review. Additional problems ensue when last minute revisions are made to the document prior to a public announce¬

ment resulting in a frantic signing session.

This process can also result in errors and/ or omissions in the signed docu¬

ments. A required party may not be available at the time of the meeting. The wrong

party may inadvertently sign a document, or the wrong version of a document may

be signed by one or more of the parties.

In addition, since each party may need to sign off on a separate set of docu¬

ments, it is often difficult to ascertain whether all of the required signatures have

been properly captured on the correct versions of the documents. In order to mini¬

mize such errors, and in order to ensure that each of the agreements has been prop¬

erly executed, a time-consuming and expensive audit of the agreements is often per¬

formed.

What is needed, then, is a system and method for creating a virtual signing

room that enables parties to review and edit multiple agreement documents without

requiring that the parties be physically present at the same location. What is further

needed is a system and method for enabling different individuals to review and sign

each of the agreements pertaining to their role in the transaction. What is further

needed is a document processing system that provides an audit trail for the signing

room that confirms that each party has signed the necessary documents and records

each signature accordingly for later verification. Finally, what is needed is a system

and method for enabling multiple parties to review, modify, and execute multiple

agreements, that minimizes the above limitations and problems of the prior art, re¬

duces costs and burdens, and improves accuracy. Summary of the Invention

The present invention solves the foregoing problems by providing a virtual sign¬

ing room that provides real-time access to agreement documents, regardless of geo¬

graphical locations of the various parties involved, and provides a complete audit trail

for all activity occurring in the virtual signing room. The present invention provides

quick and easy access to all documents to be reviewed and/ or signed by each party, as

identified by each party's respective role, and also ensures that documents are signed in

the proper order as defined by various commercial standards or other requirements. In a

preferred embodiment, the virtual signing room of the present invention advanta¬

geously uses document-driven processing of digitally signed, electronic documents, as

disclosed in co-pending U.S. Patent Application Serial No. 09/335,443, to help achieve the

above-listed objectives.

In one aspect of the invention, a virtual signing room is provided that pro¬

vides real-time access to agreement documents. In one embodiment, the signing

room is a private room that can only be accessed by specified individuals, such as

the parties to the transaction. The system uses standard authentication technology,

such as digital certificates or biometric devices, to verify a party's identity prior to

transmission of the web page or other physical manifestation of the signing room. In

one embodiment, the invention includes a signing role identifier for associating the

identity of the party with one or more signing roles, a document management sys¬

tem for retrieving each of the necessary documents and providing access to the documents accordingly, and a deal management module for ensuring that the

proper signing sequence is followed and that each of the necessary signatures is re¬

ceived.

In another aspect of the invention, the document management system in¬

cludes a document privilege module that defines privileges for each of the parties,

such as permission levels for viewing, editing and modifying the document or speci¬

fied portions of the document.

In another aspect of the invention, the document management system in¬

cludes a notification module for notifying various parties of revisions to one or more

of the documents. Such notification may be provided, for example, upon entry into

the virtual signing room (e.g. by display of a dialog box, or an on-screen indicator

displayed adjacent to recently-modified documents), and/ or it may include an e-

mail notification to the party. Thus, for example, a party may be notified by e-mail

when portions of the documents identified as critical, such as portions affecting price

or term of the agreement, are modified but may only be notified upon entry into the

virtual signing room when less critical terms are modified. The party may designate

which forms of notification are desired for various types of document modifications.

In another aspect of the invention, the document management module in¬

cludes a document revision list that provides a complete record of the transaction.

This might include, for example, a listing of each of the revisions made to the docu¬

ment, the date and time of each revision, and the authenticated party responsible for

the revisions. This information could be used during negotiations over the agree- ment itself or could be used after the fact to help define the parties' intent at the time

of the transaction.

In another aspect of the invention, a deal management module is provided

that manages the steps associated with completing the deal and monitoring the per¬

formance of each of the parties to the deal. In one embodiment, the deal manage¬

ment module includes a list of items that must be accomplished to complete the

transaction. In the simplest case, this list might include, for example, a requirement

that the entry of contact information into a field of the document is completed and

the signature of a party is applied. In a more complex deal, the list might include the

requirements that several different agreements are signed at various times (and in a

particular order) during the transaction. For example, the deal may be initiated with

the application of the signature to a non-disclosure agreement and end with applica¬

tion of the signature to the final acquisition agreement. Furthermore, revisions in the

agreements can be used to trigger new items on the list as necessary to effectively

complete the transaction.

Brief Description of the Drawings

Figure 1 is a functional block diagram of a system for digitally signing an elec¬

tronic document according to one embodiment of the present invention.

Figure 2 is a physical block diagram of a system for digitally signing an elec¬

tronic document according to one embodiment of the present invention.

Figure 3 A is a block diagram of an Internet facility for reviewing, editing and

signing electronic documents according to one embodiment of the present invention. Figure 3B is a block diagram showing a four-tier architecture for implement¬

ing one embodiment of the present invention.

Figure 3C is a block diagram showing a four-tier architecture including an E-

Cabinet for implementing one embodiment of the present invention.

Figures 4A-4B are screenshots of a sample system for digitally signing an elec¬

tronic document according to one embodiment of the present invention.

Figures 5A-5B depict an example of an agreement document in paper form.

Figures 6A-6B depict an example of a screen display of an agreement docu¬

ment.

Figure 7 A is a flowchart illustrating the process of entering a virtual signing

room according to one embodiment of the present invention.

Figure 7B is a flowchart illustrating the process of reviewing and signing a

document according to one embodiment of the present invention.

Figures 8A-8B depict an example of a screen display of a completed and digi¬

tally signed agreement document.

Figure 9 is an example of a screen display of an ACH Authorization Form.

Figures 10A-10B depict an example of a screen display for a Change and En¬

rollment Form.

Figure 11 is an example of a screen display for passphrase entry and key gen¬

eration.

Figure 12 is an example of a screen display for private key retrieval.

Figure 13 is a flowchart showing a document signing method according to

one embodiment of the present invention. Figure 14 is a system block diagram of one embodiment of a document man¬

agement flow process in a signing room implemented according to the present in¬

vention.

Figure 15 is a system block diagram of one embodiment of a document man¬

agement flow process in a disclosure room implemented according to the present

invention.

Figure 16A is a flowchart showing a signing room logon and entry method

according to one embodiment of the present invention.

Figure 16B is a flowchart showing a signing room admittance procedure ac¬

cording to one embodiment of the present invention.

Figure 16C is a flowchart showing an account termination method according

to one embodiment of the present invention.

Figure 17 is a flowchart showing an example of an electronic signature collec¬

tion method according to one embodiment of the present invention.

Figures 18A-D are screen shots showing an example of a signing room accord¬

ing to one embodiment of the present invention.

Figure 19 is a flowchart showing a deed recording method according to one

embodiment of the present invention.

Figure 20 is a block diagram showing a mortgage signing room architecture

according to one embodiment of the present invention.

Figure 21 is a site architecture diagram of a mortgage signing room according

to one embodiment of the present invention. Detailed Description of the Preferred Embodiments

A preferred embodiment of the invention is now described with reference to

the Figures, where like reference numbers indicate identical or functionally similar

elements. The particular sequence of steps shown in the various methods described

below may be performed, for example, by a computer or set of computers following

a set of instructions specified in software code. One skilled in the art will recognize

that other mechanisms and implementations for performing such methods may also

be employed.

Referring now to Figure 1, there is shown a functional block diagram of a sys¬

tem 100 for digitally signing electronic documents 102. Although this system will be

used to describe one embodiment of the present invention, other document process¬

ing systems could also be used to implement the virtual signing room. As described

hereafter, each document 102 is preferably encoded using a markup language, such

as the February 1998 W3C Recommendation Extensible Markup Language (XML)

1.0, although the invention is not limited in that respect. For example, the standard

generalized markup language (SGML, ISO 8879) or another markup language could

be used without departing from the spirit of the invention. Preferably, the document

102 is indexed for full text searching, and the document data within tagged fields are

indexed for field searches. The indexing allows a user to easily perform document

queries using techniques well known to those skilled in the art.

The document 102 may represent any of a number of legal or commercial in¬

struments, such as sales contracts, licenses, non-disclosure agreements, patent appli¬

cations, court pleadings, mortgages, and the like. Appendix A is an example of a document type definition (DTD) in the context of an electronic court filing system.

Appendices B and C show an example of an XML-encoded document corresponding

to the agreement document depicted in Figures 6A-6B. Appendix B shows the

document in its initial state; Appendix C shows the document after it has been com¬

pleted and digitally signed. It should be recognized that a wide variety of applica¬

tions, instruments, and/ or document types may be provided within the scope of the

present invention.

Briefly, the principal components of the system 100 include a role identifier

104, a parser 106, and a signing module 108. In one embodiment, the foregoing com¬

ponents are implemented as software modules running on a conventional personal

computer employing, for example the Microsoft® Windows 98 operating system and

an Intel® Pentium microprocessor, although other implementations are possible. For

example, the components could be distributed among a plurality of computers

within a network. Alternatively, the components could be implemented as hardware

devices within an embedded system. Although the components are described herein

as separate functional units, those skilled in the art will recognize that various com¬

ponents may be combined or integrated into a single software application or device.

The role identifier 104 determines the role or capacity in which a signer is to

digitally sign the electronic document 102. Unlike conventional systems which are

limited to the signing of an entire document by a single person in a single role or ca¬

pacity, the present invention allows multiple individuals to sign different portions of

the document 102 in multiple different roles or capacities. Thus, the present inven¬

tion enables the signing of complex, real-world documents. In one embodiment, the role identifier 104 is implemented as a Web browser,

such as the Microsoft Internet Explorer, available from Microsoft Corporation of

Redmond, Washington. Preferably, the role identifier 104 receives input from the

signer to determine the signer's identity and/ or role. As discussed in greater detail

below, the input is obtained using conventional input mechanisms such as pull¬

down menus, radio buttons, text entry boxes, and the like.

In one embodiment, the role identifier 104 includes an authenticator 110,

which is used to authenticate the signer's identity, as well as the signer's authoriza¬

tion to sign the document 102 in the specified role. Although a variety of authentica¬

tion systems exist, a public key cryptosystem is preferably used to authenticate the

signer, as described hereafter. In one embodiment, the authenticator 110 is imple¬

mented as a "plug-in" module to a conventional Web browser. Although the authen¬

ticator 110 is illustrated herein as a component of the role identifier 104, it should be

recognized that the authenticator 110 could be implemented as a separate functional

unit.

Coupled to the role identifier 104, the parser 106 parses the document 102 to

identify the portion to be signed by the signer, i.e. the "to-be-signed" portion. In one

embodiment, the parser 106 is an XML parser adapted to parse an XML-encoded

document 102. As described in greater detail below, the parser 106 identifies within

the document 102 a "to-be-signed" tag 116 or other delimiter for indicating a portion

of the document 102 to be signed by the signer in the specified role or capacity. The

document 102 may include a plurality of such tags 116 corresponding to the plural¬

ity of signers and roles. In addition, the parser 106 may be used to identify one or more "accessible-by" tags 120 within the document 120, as described in greater detail

hereafter.

In a preferred embodiment, XML is used because it may be parsed using a

relatively simple parser 106. However, as noted above, SGML or another markup

language could be used without departing from the spirit of the invention. In one

embodiment, the parser 106 is a commercially available XML parser, such as the

XML parser available from Microsoft Corporation. However, a custom-designed

parser 106 could also be used within the scope of the present invention.

Coupled to the parser 106, the signing module 108 applies the signer's digital

signature to the identified to-be-signed portion of the document 102. In one em¬

bodiment, the signing module 108 applies the digital signature using the RSA Public

Key Cryptosystem, available from RSA Data Security, Inc. of San Mateo, California,

although the invention is not limited in that respect. The RSA Public Key Cryptosys¬

tem is well known to those skilled in the art, and has become a de facto standard for

cryptographic communications and digital signatures. In one embodiment, the sign¬

ing module 108 is implemented as a "plug-in" module to a standard Web browser,

although other implementations are possible without departing from the spirit of the

invention.

In one embodiment, the signing module 108 includes a message digest calcu¬

lator 112 for calculating a message digest for the to-be-signed portion. As noted

above, the message digest is a number or code that represents the to-be-signed por¬

tion of the document 102. Preferably, the message digest is calculated using a one¬

way hash function, such as the Secure Hash Algorithm (SHA) or Message Digest (MD5), whereby any change to the message will result in a different calculated mes¬

sage digest. SHA was developed by NIST as specified in the SHS (Secure Hash Stan¬

dard). The algorithm takes a message (less than 2⁰⁴ bits of length) and produces a

160-bit message digest. MD5 was developed by RSA and takes a message of arbi¬

trary length and produces a 128-bit message digest. Although the message digest

calculator 112 is illustrated herein as a component of the signing module 108, it

should be recognized that the calculator 112 could be implemented as a separate

functional unit.

The signing module 108 also includes an encryptor 114 for encrypting the

message digest with the signer's private key. The encrypted message digest is re¬

ferred to herein as a digital signature 118. In one embodiment, the digital signature

118 is stored within the document 102 and associated with the portion of the docu¬

ment 102 that was signed. Alternatively, the digital signature may be stored with

other document audit information for later verification. Although the encryptor 114

is illustrated herein as a component of the signing module 108, it should be recog¬

nized that the encryptor 114 could be implemented as a separate functional unit.

Referring now to Figure 2, there is shown a physical block diagram showing

the components used to implement the functionality of Figure 1, according to one

embodiment of the present invention. A central processing unit (CPU) 202 executes

software instructions and interacts with other system components to perform the

methods of the present invention. A storage device 204, coupled to the CPU 202,

provides long-term storage of data and software programs, and may be imple- mented as a hard disk drive or other suitable mass storage device. In one embodi¬

ment, the storage device 204 stores a plurality of documents 102 to be signed.

A network interface 206, coupled to the CPU 202, connects the system 100 to a

network (not shown), such as the Internet. Such connection is implemented accord¬

ing to techniques that are known in the art. A display device 208, coupled to the

CPU 202, displays text and graphics under the control of the CPU 202. An input de¬

vice 210, coupled to the CPU 202, such as a mouse or keyboard, facilities user control

of the system 100. A "smartcard" reader 211, coupled to the CPU 202, facilitates ac¬

cess to a smartcard for authentication purposes, as described in greater detail below.

An addressable memory 212, coupled to the CPU 202, stores software instruc¬

tions to be executed by the CPU 202, and is implemented using a combination of stan¬

dard memory devices, such as random access memory (RAM) and read-only memory

(ROM) devices. In one embodiment, the memory 212 stores the above-described docu¬

ment 102 and software modules, including the role identifier 104, parser 106, signing

module 108, authenticator 110, message digest calculator 112, and encryptor 114.

In one embodiment, the memory 212 also includes an operating system 214 for

managing and providing system resources to the above-mentioned software modules.

Preferably, Windows 98, available from Microsoft Corporation, is used, although a vari¬

ety of other operating systems 228, such as Windows 2000, MacOS 8, UNIX, or Linux

may be used within the scope of the present invention.

Referring now to Figure 3 A, there is shown a block diagram that illustrates one

embodiment of an Internet facility for reviewing, editing and signing electronic docu¬

ments according to the present invention. In one embodiment, the invention includes a virtual signing room 300 implemented as a web page using XML technology. Alterna¬

tively, other markup languages could be used. The signing room 300 comprises three

separate logical modules: a document management module 310; a party-to-document

mapping module 320; and a deal management module 330.

The document management module 310 serves to manage the documents associ¬

ated with the deal or transaction. Module 310 also monitors and maintains an audit trail

for any revisions or alterations made to the documents. In one embodiment, the docu¬

ment management module 310 establishes access rules for determining to what extent

each party in the deal room has permission to view and/ or modify each document.

Once a party is authenticated and enters the signing room, the document management

module 310 retrieves the documents that the party has permission to view by making

calls to the document-to-party mapping module 320. As described above, for each

document, permissions may be granted for the entire document or for a portion of the

document associated with the authenticated party. Furthermore, the document man¬

agement module 310 deteπriines whether any revision privileges exist for the party with

respect to retrieved documents. Again, such privileges may be defined with respect to an

entire document or may only apply to a portion of the document. For example, one

party may have the ability to modify the correspondence address used in the agreement

or the spelling of their own name but may not be permitted to make any revisions to

other material terms in the agreement.

In one embodiment, the document management module 310 includes an audit

module 315. The audit module 315 tracks and stores all revisions 318 to the documents

made by each party. By storing the revisions 318 to the documents, the audit module provides a roadmap beginning with the initial version 316 of the agreement and ending

with the final version incorporating revisions 318, thereby enabling better interpretation

of the resulting agreement by the parties. Furthermore, the functionality of the audit

module 315 can be used in conjunction with a notification module 317 to provide notifi¬

cation to the parties of any revisions to the documents.

In one embodiment of the invention, the notification module 317 may be used

to notify different parties of revisions to one or more of the documents. Such notifi¬

cation may be provided, for example, upon entry into the virtual signing room 300

(e.g. by display of a dialog box, or an on-screen indicator displayed adjacent to re¬

cently-modified documents), and/ or it may include an e-mail notification to the

party. Thus, for example, a party may be notified by e-mail when portions of the

documents identified as critical, such as portions affecting price or term of the

agreement, are modified but may only be notified upon entry into the virtual signing

room when less critical terms are modified. In one embodiment, the party may des¬

ignate which forms of notification are desired for various types of document modifi¬

cations.

In one embodiment, the party-to-document mapping module 320 includes a

role identifier 104 for generating and maintaining a map 322 assigning a role for each

party, and a map 324 for associating each role with one or more documents. As

noted earlier, the role identifier 104 receives input from the signer to determine the

signer's identity and/ or role. In one embodiment, the role identifier 104 uses con¬

ventional input mechanisms such as pull-down menus, radio buttons, or text entry

boxes to receive input specifying a role. The present invention thus facilitates man- agement of document privileges in the context of a complex transaction where each

party may be associated with multiple roles. For example, an executive in a company

may serve as a board member, a shareholder, an employee and an inventor. By pro¬

viding access to documents based on a role, the executive can review each agreement

separately by selecting each role in turn. Alternatively, the party may wish to simply

receive all documents that are associated with each of the roles that the party has

been assigned.

For example, in one embodiment as illustrated in Figures 4A and 4B, the

signer's role is specified by means of a pull-down menu 402. Likewise, in certain

embodiments, the identity of the signer may be obtained from a "cookie" or from

network login information. However, it should be recognized that the signer's iden¬

tity could be separately specified.

Once a role has been specified, the party-to-document mapping module 320

retrieves a list 404 of possible documents 102 to be signed by the party. For example,

as shown in Figure 4 A, the selection of the role of "Governor" from the pull-down

menu 402 results in a list 404 of bills to be signed by the Governor. Likewise, as

shown in Figure 4B, the selection of "Clerk" from the menu 402 results in a list 404 of

bills to be reviewed and approved by the Clerk.

While using the party-to-document mapping module 320 in conjunction with

a previously generated list is one method for determining the documents to be

signed by a party, the list 404 may be generated dynamically in a number of ways.

For example, as described more fully hereafter, the parser 106 may parse a plurality

of documents 102 (located either in the storage device 204 or in memory 212) to iden- tify each to-be-signed tag 116 contained therein. As noted earlier, each to-be-signed

tag 116 indicates a role of a signer. Thus, an index (not shown) of documents 102 and

roles may be created, which may then be used by the role identifier 104 to generate a

list 404 of documents 102 for a specific role. This enables the addition of documents

at a later time without requiring an administrator to recreate a new list with each

new document.

A deal management module 330 is also provided for managing a deal comple¬

tion list 332 of items that must be accomplished to complete the deal. In the simplest

case, this list might include, for example, a requirement that certain contact informa¬

tion be entered in a field of the document and that a signature be applied, or that

two signatures be applied to a document in a particular order. In a more complex

deal, the list might include, for example, application of one or more signatures to

several different agreements at various times during the agreement. For example,

the deal may be initiated with application of a signature to a non-disclosure agree¬

ment and end with application of a signature to a final acquisition agreement.

In one embodiment, a next step module 334 is provided that monitors and at¬

tempts to complete the next step in the deal. This might involve, for example, auto¬

matically sending an e-mail message to the party that is responsible for the next step

in the deal. Alternatively, the next step at a given stage of the deal may involve, for

example, retrieving a document from another server or generating a summary of the

agreement; the next step module 334 interactively makes requests as necessary to

complete the appropriate task. Additionally, the deal management module 330 may add new items to the list

responsive to revisions in one or more of the agreements in order to effectively com¬

plete the new transaction. The application of a signature to a project agreement, for

example, may dictate that a project description be added to the list to complete the

transaction.

Referring now to Figure 3B, there is shown a four-tier architecture as may be

used for implementing one embodiment of the present invention. The four tiers in¬

clude, for example:

• Client tier 341, such as a conventional browser;

• Presentation tier 341, including functionality for authentication, sign¬

ing room, E-Cabinet, and administration, as described in more detail

below;

• Business logic tier 343, including functionality, such as a Virtual File

Clerk (described in more detail below) for processing requests and per¬

forming other business functions; and

• Persistent storage tier 344, including database (RDBMS) and document

store.

Tiers interact with one another to perform the functionality of the network-

based application, as is known in the art. In one embodiment, the virtual signing

room of the present invention is implemented as part of presentation tier 341, along

with other functionality.

Referring now to Figure 3C, there is shown a block diagram illustrating the

functional modules of presentation tier 342, including authentication 352, signing room 300, and E-Cabinet 352. E-Cabinet 352 is a presentation-level tier application

that provides access to a repository of documents, such as may be stored in persis¬

tent storage tier 344 (on a database, for example). E-Cabinet 352 may be used, for

example, to archive documents after completion of a deal or other transaction. Ac¬

cess to particular documents within E-Cabinet 352 may be permitted or restricted

based on various characteristics, subject to verification of the user's identity.

Thus, for example, a user would provide a user name, password, and/ or ad¬

ditional identity verification such as digital signature and biometrics. The user then

selects a role from a list of available roles in connection with E-Cabinet 352. E-

Cabinet 352 presents the user, via a browser, with a list of documents that are rele¬

vant to the user and his or her selected role.

In one embodiment, various views and modes of accessing documents may be

provided, including a search function 353, status report 354 as to selected docu¬

ments, and hierarchical display 355 of documents. Search function 353 may provide,

for example, full text indexing and searching, and/ or field-specific search functional¬

ity for documents in the E-Cabinet 352 (which are stored in persistent storage tier

344 such as a database). Business logic tier 343, such as a virtual file clerk, processes

requests made by the user, retrieves the appropriate data from persistent storage tier

344, filters the results so that they only contain information to which the user has ac¬

cess, and provides the documents for display in client tier 341.

One skilled in the art will recognize that the architecture shown in Figures 3B

and 3C, and the E-Cabinet functionality described above, are merely exemplary, and that other architectures and methods for implementing the present invention are

possible.

Referring now to Figure 7A, there is shown a flowchart illustrating the proc¬

ess of entering the virtual signing room 300. As an initial matter, the identity of the

party attempting to enter the Internet facility or signing room 300 is requested 702.

This might involve user entry of a user name with a password that can be issued to

log into all deals pending on that server or might involve entering a special code that

has been provided to the party for a single deal.

The method continues by authenticating 704 the party for the specified role.

The authenticator 110 verifies the identity of the party before the party is allowed to

sign the document 102 in the specified role or capacity. If the authentication is un¬

successful, the invention detects and prevents the unauthorized access.

Various forms of authentication may be performed in connection with the

present invention. For example, public key cryptography offers a particularly secure

method for authentication. In one embodiment, the party inserts a smartcard en¬

coded with his or her private key into the smartcard reader 211. Smartcards and

smartcard readers 211 are available from a variety of sources, such as Micromodular

Data Solutions of Santa Clara, California.

The authenticator 110 uses the private key encoded within the smartcard to

encrypt a standard message. Thereafter, the authenticator 110 attempts to decrypt

the message using the party's public key, which may be obtained from a public key

database or the like using a standard protocol, such as the Lightweight Directory

Access Protocol (LDAP), which is part of the X.500 standards. If the message is suc- cessfully decrypted, the smartcard is known to contain the private key of the author¬

ized signer.

For even greater security, the smartcard may contain previously-acquired

biometric data of the signer, such as digitized fingerprints, voiceprints, facial con¬

figurations, iris images, and the like, which may be compared with new biometric

data obtained at the time of authentication using a biometric data acquisition device

(not shown). Biometric data acquisition devices are well known in the art and may

be obtained from a variety of sources. For example, fingerprint identification sys¬

tems may be obtained from Digital Persona, of Redwood City, California. Likewise,

SAFlink Corp., of Tampa, Florida provides a system for voice, face and fingerprint

recognition. IriScan, Inc. of Marlton, New Jersey provides a system for iris scanning.

If the previously acquired data substantially matches the new biometric data

(within acceptable tolerances for noise and other effects), the party will be declared

authentic. In combination with the public key authentication system discussed

above, the foregoing technique makes the signer's digital signature far more reliable

and difficult to repudiate than its handwritten equivalent.

In alternative embodiments requiring a lesser degree of security, the party-

may provide a pass phrase or the like to the role identifier 104, after which the pass

phrase is compared against a database of pass phrases for various signing roles. If a

match is found, the party is authorized for the corresponding role and is allowed to

enter the signing room 300.

Referring now to Figure 7B, there is shown a flow chart illustrating the proc¬

ess of reviewing and signing a document. The method begins by obtaining 706 the private key of the signer. As noted earlier, the private key is used for generating the

signer's digital signature 118. In the smartcard embodiment described above, the

signer's private key is retrieved from the smartcard. Various security measures, well

known to those skilled in the art, may be used to prevent unauthorized access to and

retrieval of the signer's private key. In the case of the pass phrase embodiment, a

private key is preferably stored within the database for each pass phrase. When a

match is found, the corresponding private key is retrieved from the database.

After the private key is obtained, the method continues by locating 708 a to-

be-signed tag 116 within the document 102 corresponding to the specified role of the

signer. As explained above, the to-be-signed tag 116 is an XML tag used for indicat¬

ing a portion of the document 102 to be signed. In an alternative embodiment, an

XML attribute is used for the same purpose. The parser 106 parses the document 102

to find the to-be-signed tag 116 corresponding to the specified role. If the parser 106

is unable to find the tag 116, an error is preferably generated.

Thereafter, the to-be-signed tag 116 is used to identify 710 the to-be-signed

portion of the document corresponding to the role of the signer. In one embodiment,

each to-be-signed tag 116 comprises a beginning tag (comprising an identification of

a role) and an end tag. For example, a to-be-signed tag 116 has the following form in

one embodiment:

<TBSigned SigID= " Governor " >

</TBSigned>

The text between the beginning tag and end tag is the to-be-signed portion of

the document 102. The use of to-be-signed tags 116 allows various portions of a document 102 to be signed by different individuals, unlike some conventional sys¬

tems that are limited to signing an entire document by a single individual.

After the to-be-signed portion is identified, a check 712 is made whether ac¬

cess to any portion of the document 102 is restricted, indicating that the portion

should not be displayed to the signer. The ability to restrict the viewing of particular

portions of a document 102 is advantageous in many contexts. For example, an elec¬

tronically filed court document might include portions that are sealed by a court or¬

der, while the unsealed portions should still be available to be viewed by the public.

Similarly, certain agreements may include portions that are not relevant to certain

individuals, and thus should not be viewed by particular signers. Thus, in one em¬

bodiment, access restrictions may be placed on the document 102 in order to allow

the signer to view certain portions and not others. This is an advance over conven¬

tional systems in which a digitally signed word-processing or otherwise-encoded

document must be displayed to the signer in its entirety or not at all.

As described above, the document 102 may include one or more accessible-by

tags 120 for indicating access restrictions to portions of the document 102. In an al¬

ternative embodiment, XML attributes are used for the same purpose. Like the to-be-

signed tag 116, the accessible-by tag 120 includes a beginning tag and an end tag,

and the text between the tags is the portion of the document 102 that is access-

restricted. Preferably, the parser 106 is used to identify the access-restricted portions

of the document 102. In one embodiment, the accessible-by tag 120 includes an indication of one or

more roles, access levels, or the like, of individuals who may view the document 102.

For example, in one embodiment, an accessible-by tag 120 has the following format:

<AccessibleBy>

<ViewModifyχPersInf o Role= ' ' Judge ' ' ></ViewModif y>

<ViewxPersInf o Role= ' ' Plaintif f ' ' x/View>

</AccessibleBy>

In this example, the judge may both view and modify the document 102,

while the plaintiff may only view the document 102. Preferably, all other individuals

would not be able to view or modify the document.

If, in step 712, it is determined that the document includes access restrictions,

the method continues with step 714 by preventing unauthorized access to the access-

restricted portions, such as by masking the display of, and/ or preventing revisions

or modifications to, those portions. In one embodiment, one or more masked por¬

tions may be encrypted using the public key of the person authorized to access those

portions. As a result, if the signer is the authorized party, only she may use her pri¬

vate key to decrypt and display the masked portions.

After either steps 712 or 714, the method continues by displaying 716 the

document 102, excluding any masked portions, to the signer, and accepting any edits

or revisions to the portions accessible to the signer. This allows the signer to review

the document 102 and make any required selections or revisions before applying his

or her digital signature 118. After the document 102 has been displayed and edited, the method continues

by receiving 718 from the signer an indication to sign the document 102. This may be

accomplished in any of a variety of ways, as will be apparent to one skilled in the art.

For example, the signer may use the input device 210 to click on a "sign now" button

or the like.

Next, the method continues by storing 720 in the to-be-signed portion of the

document 102 the date and time at which the document 102 is signed. Preferably, the

current date and time is read from a system clock (not shown) or the like, which is

coupled to the CPU 202. The inclusion of a time and date stamp is useful for auditing

purposes, and for later verification of the validity and applicability of the signed

document 102, for example in a court or administrative proceeding. By providing

date and time stamps for individually-signed portions of the documents 102, the

present invention provides advantages over conventional systems which may not be

able to realistically model documents 102 that are signed at different dates and times

by different individuals.

In one embodiment, date and time tags are added to the to-be-signed portion,

identifying the date and time at which the signer signs the document 102. For exam¬

ple, the date and time tags have the following format in one embodiment:

<date>01 - 02 - 1999</date> <time>15 : 43 : 16 . 12</time>

By adding the date and time tags to the to-be-signed portion, the tags are digi¬

tally signed, so that the signer cannot later repudiate the date and time of the digital

signature. After the date and time are stored, the method continues by calculating a

message digest for the to-be-signed portion of the document 102. As noted above,

this is accomplished in one embodiment using a one-way hash function, such as

SHA or MD5, whereby any change to the message will result in a different calculated

message digest. Those skilled in the art will recognize that a variety of other hash

functions could be used without departing from the spirit of the invention.

Thereafter, the method continues by encrypting 722 the message digest using

the signer's private key to generate the signer's digital signature 118. While it is pos¬

sible to encrypt the whole document 102 without departing from the spirit or essen¬

tial characteristics of the present invention, it is typically not necessary to do so, be¬

cause many documents are non-private except for specific portions that may be

masked as described above. Moreover, since encrypting a document (such as by

public key cryptography, symmetric cryptography, or other means) can be relatively

slow, it is advantageous to minimize the amount of data encrypted.

After the digital signature 118 is created, the method continues by storing the

digital signature 118 within the document 102. In one embodiment, the digital signa¬

ture 118 is stored directly after the to-be-signed portion, although one skilled in the

art will recognize that the signature 118 can be stored at other locations.

In one embodiment, the document 102 includes a signing history portion for

storing the digital signature 118 of each signer of the document 102. The signing his¬

tory portion may be separately designated by an XML tag, such as < Signa -

turesx /Signatures > , and forms a convenient location for storage of informa¬

tion indicating which signers have signed the document 102. After the digital signature 118 is stored, the method continues by obtaining

728 and storing the signer's digital certificate. A digital certificate is an attachment to

a document 102 that provides additional verification that the signer is whom he or

she claims to be. An individual wishing to digitally sign a document applies for a

digital certificate from a Certificate Authority (CA), such as Verisign, Inc., of Moun¬

tain View, California. The CA issues an encrypted digital certificate containing the

individual's public key and a variety of other identification information. The CA

makes its own public key readily available, such as through print publicity and/ or

via the Internet. Thus, the recipient of an encrypted message uses the CA's public

key to decode the digital certificate attached to the document 102, verifies it is issued

by the CA, and then obtains the sender's public key and identification information

held within the certificate. The recipient thus obtains some assurance that the signer

is whom he or she claims to be. In one embodiment, the ANSI X.509 standard is used

for such digital certificates in connection with the present invention.

In one embodiment, the signer's digital certificate is obtained from the

signer's smartcard, as discussed above. In alternative embodiments, the certificate

may be obtained from a database after the signer is authenticated with a pass phrase

or the like. The digital certificate is preferably stored in the document 102 near the

associated digital signature 118. In one embodiment, the digital certificate is identi¬

fied within the document 102 by a <Cert x/Cert > tag.

After the digital certificate is stored, the method continues by displaying 730 a

visual indication of the signer's digital signature 118 in conjunction with the display

of the document 102. Any of a variety of techniques may be employed. For example, a digitized version of the signer's handwritten signature (not shown) may be applied

to the document 102. Likewise, in appropriate situations, a graphical seal (not

shown) could be displayed. This may be particularly appropriate, for example, in the

case of a "digital notary", who may perform a similar function as a notary public by

verifying a signer's digital signature and digital certificate with a CA. Moreover, an

ASCII or Base 64 representation (not shown) of the digital signature 118 could also

be displayed. Other representations and indications are also possible, such as

graphical overlays and the like. After the visual indication is displayed, the method

of Figure 7B is complete.

The present invention also facilitates collaborative document editing by re¬

mote-located parties. Previously stored revision privileges associated with a party

are retrieved, and revisions are permitted according to the level of privileges. In

some situations, a party may only have rights to modify a portion of the document.

Any number of conventional locking mechanisms may be employed to prevent

modifications or revisions to document data. For example, text fields may be marked

with "read only" attributes, and text entry fields, pull down menus, and radio but¬

tons may be "grayed out" to prevent modifications to the document 102 using tech¬

niques well known to those skilled in the art.

If a party wishes to modify the document, the audit module 315 may be initi¬

ated to track the revisions and to record the party's identity accordingly. Addition¬

ally, as described above with reference to Figure 3 A, the audit module 315 verifies

whether any notifications should be transmitted to one or more of the other parties

to the agreement. If so, the audit module 315 performs the action associated with the type of revision. For example, if a field has been tagged as "critical", then an e-mail

message may be immediately transmitted to one of the parties.

Referring now to Figure 20, there is shown a block diagram depicting a mort¬

gage signing room architecture according to one embodiment of the present inven¬

tion. For illustrative purposes, the block diagram of Figure 20 shows the various

parties and components that may interact with one embodiment of the present in¬

vention to implement a mortgage-related transaction. As can be seen from the Fig¬

ure, signing room 300 forms a central location for access to and modification of vari¬

ous documents, including for example, documents to be recorded 2102, title insur¬

ance 2104, mortgage closing documents 2108, certificate validations 2109, appraisals

and certificates 2111, and notarizations 2112. Signing room 300 also provides a

mechanism for initiating and managing electronic fund transfers 2110, such as be¬

tween a party and a bank 2008, as described in more detail below.

Various parties interact with the signing room 300 to create, modify, and/ or

sign any or all of the above documents, or to supply support services. Such parties

include, for example, a county recorder 2002, title company 2004, mortgage company

2006, digital certificate authority 2007, bank 2008, appraisers and inspectors 2009,

and notaries 2010. Additional parties involved in the transaction, such as the county

assessor 2001, the Internal Revenue Service 2003, lender 2005, and the like, may also

interact -with signing room 300 or may instead interact with other parties in a con¬

ventional manner, in connection with, for example, tax assessments and liens 2101,

federal tax liens 2103, loan documents 2107, and signed loan documents 2106. The

title company 2004 and county recorder 2002 may also share research 2105, if de- sired. One skilled in the art will recognize that many other parties, interactions, and

documents may be associated with or connected with a transaction implemented by

the present invention.

In one embodiment, key parties to the transaction, such as a buyer's real es¬

tate agent and/ or attorneys 2104, borrower 2105, and seller's real estate agent

and/or attorneys 2106, access signing room 300 via a "portal" website 2011 over the

Internet 2012. A conventional browser may be used for such interaction with the

system of the present invention. Additional parties, such as the buyer 2013 and the

seller 2017, may also interact with the present invention, or may be represented by

parties 2014 and 2016.

Referring now to Figure 21, there is shown a site architecture for a mortgage

signing room 300 according to one embodiment of the present invention. The site

architecture of Figure 21 may be implemented, for example in a web site as may be

accessible over the Internet. Signing room 300 contains several sections and areas for

implementing the systems and methods of the present invention, including for ex¬

ample:

• Administration 2201: Includes functionality for setting up an account,

identifying parties and roles, defining workflow, and transferring in

documents;

• Editing 2202: Includes functionality for opening documents, creating

virtual copies of documents, making revisions and changes, and initiat¬

ing new versions; • Verify 2203: Includes functionality for identifying documents to be

verified, checking certificates and a Certificate Revocation List (CRL),

and verifying by public key;

• Closing 2204: Includes functionality for monitoring application of sig¬

natures to documents, advising parties of the next requirements in the

transaction, verifying signatures as documents are signed (in conjunc¬

tion with verify 2203 area), transmitting deeds and mortgage to county

recorder, sending documents to all relevant parties, disbursing funds,

and archiving communications to database or CD-ROM;

• Archive 2205: Includes functionality for archiving, verifying, indexing,

compressing, retrieving by search, and the like;

• Signature 2206: Includes functionality for presenting unsigned docu¬

ments by e-mail, identifying the sender, requesting signature, and ap¬

plying signature;

• Certification 2207: Includes functionality for applying for a digital cer¬

tificate, selecting a security level and/ or strategy, issuing the certifi¬

cate, filing the security level and/ or strategy, and sending the certifi¬

cate to the party; and

• Notarization 2208: Includes functionality for presenting a document,

identifying the party, acknowledging the digital signature and/ or no¬

tarizing the signature. Such techniques are described, for example, in

U.S. Patent No. 5,872,848, for "Method and apparatus for witnessed authentication of electronic documents," issued February 16, 1999, the

disclosure of which is incorporated herein by reference.

Referring now to Figures 5A-5B, there is shown an example of an agreement

document 500 in paper form according to the prior art. Various entry fields 501 and

signature fields 502 are provided for manual entry of information and signatures.

The document is divided into several sections 503-511, each containing various types

of information and fields 501 and/ or 502. In addition, terms and conditions 512, as

well as application instructions 513, are provided, as may appear on the back of the

printed copy of document 500.

As can be seen from the example of Figures 5 A-5B, some sections of document

500 may not be applicable or relevant to some parties to the agreement, or may be

more suitable for completion and/ or signing at different times than other sections of

document 500. For example, placement information 505 may not be relevant or

available at the time the agreement is initially filled in, but may be suitable for later

completion when such information is known. Also, such information 505 may be

more suitably completed by a different party than the party responsible for complet¬

ing the other sections of document 500.

One disadvantage of paper forms such as that shown in Figures 5A-5B is that

such distributed completion and signing of the document is cumbersome and diffi¬

cult to implement satisfactorily. For example, the party filling in placement informa¬

tion 505 may see credit card information 508 that has previously been filled in, when

such information is not relevant to that party. In addition, particular sections of terms and conditions 512 may only apply to particular parties, but the paper form

does not permit selective "signing off" on such individual sections.

In addition, supplementary forms or other requirements may not easily be

provided or associated with the document 500. For example, if an Automated Clear¬

ing House (ACH) authorization form is required because a third-party credit card is

to be used, such a form may inadvertently be omitted because the party signing

document 500 may not be aware of such a requirement, even though paragraph 514

of instructions 513 states that such a supplementary form is required.

Referring now to Figures 6A-6B, there is shown an example of a screen dis¬

play 600 of an agreement document corresponding to the paper document 500 of

Figures 5 A and 5B. The screen display 600 may be displayed using a conventional

browser as is known in the art. As can be seen from the screen display 600, many of

the problems and limitations associated with paper documents are eliminated or

minimized. Various fields 601 are provided for entry of information corresponding

to fields 501 in document 500. If appropriate, fields 601 only include a subset of

fields 501, depending on the particular items of information to be collected from the

party viewing the display 600. Thus, for other parties providing other items of in¬

formation, a different set of fields 601 might be displayed, corresponding to the

items of information being sought.

Note buttons 604 are provided for accessing or providing additional informa¬

tion as may be relevant to fields 601 adjacent to buttons 604. Generate keys button 602 provides access to functionality for generating pub¬

lic and private keys, as described below in connection with Figure 12. Explain but¬

ton 603 provides additional information regarding the function of button 602.

Enroll button 605 specifies that the party viewing the screen display 600

wishes to enroll in an auto-shipment program. This is an example of an application

of the present invention, whereby a button 605 is used to activate a secondary form

or agreement (described below in connection with Figures 10A-10B) that is only ap¬

plicable in certain circumstances. Thus, the additional information to be collected in

association with the auto-shipment program can be relegated to the secondary form

rather than presented in the primary form. This helps to make the primary form less

confusing, as the party need not be concerned with areas on the form that are not

applicable to his or her particular situation or specified requests. In the example

shown, sections 507 and 508 of the paper document 500 of Fig. 5 A can be eliminated

from the primary display 600, since they are only applicable if the user clicks on but¬

ton 605 to specify an interest in the auto-shipment program.

Similarly, checkbox 606 allows the party viewing the screen display 600 to se¬

lect whether he or she is a nonresident alien. If so, another secondary form (not

shown) may be provided to obtain further information on such a situation. Like¬

wise, ACH button 607 provides access to another form for collecting ACH data, as

described below in connection with Figure 9Scrolling text box 608 displays the text

of the terms and agreement. The party indicates his or her assent to the terms, and

asserts the accuracy of the provided information, by clicking on Sign button 609. As described above, authentication of the signer's identity may be verified by whatever

means are appropriate.

Referring now to Figures 8A-8B, there is shown an example of a screen dis¬

play of a completed and digitally signed agreement document. This screen may be

provided, for example, when a user or party wishes to view a previously signed

document or agreement. Fields 801 are populated with data as was entered previ¬

ously in fields 601 of Figures 6A-6B. Note buttons 604 are also provided, enabling

access to supplemental information regarding various fields 801. Statement 806 pro¬

vides an affirmative statement reflecting the party's entry in checkbox 606. Field

802, showing the credit card number of the party, is partially obscured so as to hide

sensitive data from the viewer. Depending on the identity of the person viewing

screen 800, and the degree to which that identity can be verified, fields such as 802

displaying sensitive data may be omitted, obscured, or displayed in part or in full.

Parameters for such display may be specified in advance, if desired.

A hexadecimal representation of the signer's digital signature 803 is provided,

giving the viewer of screen 800 some assurance that the digital signature has in fact

been obtained. In addition, in the example of Figures 8A-8B, a hexadecimal repre¬

sentation of the certificate 804 corresponding to the signer and verifying his or her

identity, is also shown. This certificate 804 provides an additional level of certainty

as to the identity of the signer. One skilled in the art will recognize that many other

representations of the digital signature and/ or certificate may instead be displayed,

including for example a simple notification or graphical element. Referring now to Figure 9, there is shown an example of a screen display of an

ACH Authorization Form 900. Form 900 may be displayed, for example, when a

party indicates payment by ACH using button 607 of document 600. In this manner,

the additional information 901 sought in form 900 is only collected when applicable.

In addition, the particular digital signature that is affixed by clicking on button 902 is

applicable to the particular fields and text shown in form 900. Thus, the present in¬

vention provides a mechanism for digitally signing portions of documents as appli¬

cable or appropriate. In one embodiment, upon signing (by clicking on button 902),

the party is again presented with document 600 for collection of additional informa¬

tion.

Referring now to Figures 10A-10B, there is shown an example of a screen dis¬

play for a Change and Enrollment Form 1000. Form 1000 may be displayed, for ex¬

ample, when a party indicates that he or she clicks on button 605 (shown in Figure

6 A) to begin the process of enrolling in an "AutoShip" program. One skilled in the

art will recognize that form 1000 is merely exemplary of a secondary form that is ac¬

tivated by user selection of an element of a primary form.

Additional information 1001 is collected, and the user may select from various

options 1002 for the AutoShip program by clicking on checkboxes. A further option

for discontinuing membership in the program is also provided 1003. Payment in¬

formation is provided in 1004, and the party may digitally sign the document by

clicking on button 1005. In one embodiment, upon signing (by clicking on button

902), the party is again presented with document 600 for collection of additional in¬

formation. As will be apparent to one skilled in the art, the various primary and secon¬

dary forms and agreements can be presented as applicable to any party or combina¬

tion of parties. Thus, different types of information may be collected from different

parties, and some sensitive information may not be displayed to all parties. The pre¬

sent invention facilitates such flexibility of document review, access, and execution.

Referring now to Fig. 11, there is shown a screen display 1100 for passphrase

entry and key generation. In one embodiment, the party is presented with screen

1100 after he or she clicks on button 602 (shown in Figure 6A). The party enters a

passphrase in input field 1101 and confirms entry in field 1102. Optionally, the party

may specify a file name and/ or path for a file containing the private key in field

1103. The private key is preferably stored on removable media, such as a floppy

disk, so that it can be stored in a secure location; though in alternative embodiments

the private key may be stored in fixed media. The party clicks on Generate button

1104, and the private key is generated and stored on the specified media, according

to the file name and/ or path specified in field 1103 (if applicable), while the public

key is sent to the Certificate Authority.

Once the keys have been generated and stored, the user may be prompted for

the location of the private key (and asked to insert the removable media, if applica¬

ble) when the key is needed for authentication purposes, as described below. Addi¬

tional security and/ or authentication measure may also be taken, such as asking the

user to re-enter the passphrase at the appropriate time.

Referring now to Figure 12, there is shown an example of a screen display

1200 for private key retrieval. In one embodiment, screen 1200 is shown whenever a party clicks a Sign document button or otherwise indicates that he or she wishes to

digitally sign a document. For authentication purposes, the party is asked to insert

the floppy disk containing the previously generated private key. If appropriate, the

user is asked to specify the filename and/ or path for the private key in field 1201.

Optionally, the user may be asked to enter a passphrase (previously selected in the

example of Figure 11) in field 1202. The party then clicks on Sign button 1203 to affix

the digital signature to the document.

Referring now to Figure 13, there is shown a flowchart of a document signing

method according to one embodiment of the present invention. The flowchart of

Figure 13 is merely illustrative of a particular method as may apply to the processing

of the examples of Figures 6A-6B and 8 A through 12. One skilled in the art will rec¬

ognize that other variations and methods are possible and applicable to different

types of documents in accordance with the present invention.

Once a document has been initiated and a party has digitally signed the

document, the document is assigned 1302 a Digital Object Identifier (DOI) — a unique

number or other identifier that is used to track the document. The digital signature

is verified 1303 to make sure that the document is an original and that no tampering

has taken place. If a digital certificate has been asserted with respect to the docu¬

ment, the appropriate certificate authority is contacted to determine 1304 whether

the asserted certificate has been revoked. If the digital signature is reliant upon on a

certificate, this step ensures that the certificate is valid and trustworthy. The data entered by the party is checked 1305 for completeness and accuracy;

such a check may include verification of a correct syntax or number combination for

various fields and the like.

If, in steps 1303, 1304, or 1305 any problems are found with the signature, cer¬

tificate, or completeness of data, processing may stop and the user may be alerted as

to the status of the document. Otherwise, processing continues with step 1306.

Data is extracted 1306 from the completed form and provided to a back-end

database (not shown). In one embodiment, the data is transmitted via Open Data¬

base Connectivity (ODBC) calls as are known in the art. The back-end database

stores the extracted data for later retrieval when the document is to be reviewed or

otherwise output.

Credit card, ACH, or other Electronic Funds Transfer (ECF) is issued 1307 in

accordance with user-supplied account information, as collected in various fields as

described above.

In some circumstances, human review of the document may be desirable be¬

fore processing continues. If applicable, the document is displayed 1308 for human

review.

In the example shown, a new identification number is generated 1309 for the

applicant represented by the party signing the document. One skilled in the art will

recognize that such a step is merely exemplary, and that any type of identification or

other generated data element may be provided, as appropriate to the particular ap¬

plication. A back-end server (not shown) then records 1310 that the document has been

accepted and signed, and the document is stored 1311 in a database or other persis¬

tent storage. As described above, E-Cabinet 352 permits selective access to the entire

document or parts thereof, in accordance with various permissions and other pa¬

rameters associated with the document and/ or the person seeking access. Thus,

when requested by a user and in accordance with permissions, authentication re¬

quirements, and security levels, the document is retrieved from the database and

displayed 1312, for example on a browser under the user's control. Referring now to

Figure 14, there is shown a system block diagram of one embodiment of a document

management flow process in a signing room implemented according to the present

invention. One skilled in the art will recognize that the process shown in Figure 14

is merely exemplary of a particular application of the present invention in one em¬

bodiment.

A client, who may be one of the parties to a transaction, and who may be ac¬

cessing the system of the present invention from a remote location, originates 1404

the signing room documents, either by generating the documents in a word proces¬

sor or similar software application, or by uploading and converting existing docu¬

ments. The process of creating and/ or converting such documents is known in the

art.

Virtual File Clerk 1405, which is a business logic tier 343 functional module

which forms an interface between presentation 342 and persistent storage 344 (in¬

cluding database 1409), processes the originated or converted documents and man¬

ages the document flow. As described above, presentation tier 352, implements signing room 300, E-

Cabinet 352, and the like, for hosting and presenting documents, signing rooms, and

the like.

Presentation tier 352 may contain any number of virtual signing rooms 300.

In the example of Figure 14, three such signing rooms 300 are shown for illustrative

purposes: a Proposition 209 room 300A for implementing a transaction involving

government legislation; an Investment Banking Transaction room 300B for imple¬

menting an investment transaction; and a Real Estate room 300C for implementing a

real estate transaction. One skilled in the art will recognize that many other types of

virtual signing rooms 300 can be provided according to the present invention.

Each signing room 300 contains information describing roles 1401, content

1402, and transactions/ documents 1403. For example, the Proposition 209 room

300 A contains four roles 1401 A (originator, moderator, participant, and observer),

five content items 1402A (documents of commerce, reports, white papers, discussion

threads, and multi-dimensional links), and four sets of transactions/ documents

1403 A (petition, supporting/ opposing documents, discussions, documents to sign).

The Investment Banking Transaction room 300B contains four roles 1401B (origina¬

tor, moderator, participant, and observer), six content items 1402B (documents of

commerce, reports, white papers, discussion threads, multi-dimensional links, and

high security items), and six sets of transactions/ documents 1403B (offer, supporting

documents, letter of intent, evolving contract, digital signatures, and archive). The

Real Estate room 300C contains four roles 1401C (originator, moderator, participant,

and observer), five content items 1402C (documents of commerce, reports, white pa- pers, discussion threads, and multi-dimensional links), and six sets of transac¬

tions/documents 1403C (listing, sale contract, loan applications, appraisals, loan

documents, and deeds).

In one embodiment, an archive 1410 is provided for long-term storage of any

or all elements of signing rooms 300. The archive 1410 may include, for example, a

chronology of events, revision logs, drafts, and the like. The archive 1410 may be

stored, for example, on a compact disc read-only memory (CD-ROM) device or the

like, for convenient access at a later time.

Referring now to Figure 15, there is shown a system block diagram of one

embodiment of a document management flow process in a disclosure room imple¬

mented according to the present invention. One skilled in the art will recognize that

the process shown in Figure 15 is merely exemplary of a particular application of the

present invention in one embodiment.

In several respects, the disclosure room process of Figure 15 is similar to the

signing room process previously described in connection with Figure 14, although in

general, in a disclosure room, no application of digital signatures takes place. The

client originates 1404 the disclosure room documents, either by generating the

documents in a word processor or similar software application, or by uploading and

converting existing documents. As before, the process of creating and/ or converting

such documents is known in the art. Virtual File Clerk 1405 processes the originated

or converted documents and manages the document flow. Presentation tier 342 im¬

plements signing room 300, E-Cabinet 352, and the like, for hosting and presenting documents, interfacing with database 1502. In addition, traffic relating to the disclo¬

sure room can be archived 1507, if desired.

Presentation tier 342 may contain any number of virtual disclosure rooms

1503. In the example of Figure 15, one such signing room 1503 is shown for illustra¬

tive purposes: a Technology Preview room 1503. One skilled in the art will recog¬

nize that many other types of virtual disclosure rooms 1503 can be provided accord¬

ing to the present invention.

Each disclosure room 1503 contains information describing roles 1504, content

1505, and transactions/ documents 1506. For example, the Technology Preview

room 1503 contains four roles 1504 (originator, moderator, participant, and ob¬

server), six content items 1505 (documents of commerce, reports, white papers, dis¬

cussion threads, multi-dimensional links, and high security items), and five sets of

transactions/ documents 1506 (confidential specifications, documentation, disclosure

agreement, digital signatures, and archives).

As with the example of Figure 14, in one embodiment, an archive 1410 is pro¬

vided for long-term storage of any or all elements of signing room 1503. The archive

1410 may include, for example, a chronology of events, revision logs, drafts, and the

like. The archive 1410 may be stored, for example, on a compact disc read-only

memory (CD-ROM) device or the like, for convenient access at a later time.

Referring now to Figure 16 A, there is shown a flowchart showing a signing

room logon and entry method according to one embodiment of the present inven¬

tion. In one embodiment, the steps of Figure 16A are performed by presentation tier

342 as described above in the context of the overall architecture. A user logs on 2301 to the signing room to obtain access to documents and other materials. As described

above, the user access the system of the present invention over a network such as the

Internet, using, for example, a browser. The user is presented with a contract de¬

scribing terms of use of the virtual signing room, which he or she reads 2302. If the

user deems the terms to be satisfactory, he or she indicates agreement 2303 to the

terms, for example by clicking on an onscreen button.

Once the user has indicated agreement, he or she arranges for payment 2304

for the virtual signing room service, such as for example by supplying a credit card

number or enabling electronic funds transfer. The system of the present invention

collects payment in accordance with the user's specifications, using techniques that

are known in the art.

The user then selects 2305 a security level for the virtual signing room. In one

embodiment, the user can select from five security levels, though one skilled in the

art will recognize that any number of security levels may be provided. In one em¬

bodiment, each of the security levels is associated with a different level and/ or type

of party authentication, including for example verification by passphrase, biometric

data, smartcard, IP address, processor ID code, and the like.

The user then selects 2306 a signing room to enter. This step may entail vari¬

ous substeps as described in more detail in connection with Figure 16B. The user is

then given an opportunity to calendar 2307 discussion, editing, and signing events

within the context of the virtual signing room. Thus, various transaction-related

events and items can be scheduled, depending on the nature and structure of the

particular deal. In one embodiment, the calendared events are stored so that an overall schedule of the events can be retrieved, modified, or otherwise accessed

when needed.

The user enters 2308 a signing room, for example by selecting from a dis¬

played list of available rooms to which the user has access. The user may select one

of the displayed rooms, for example by clicking on an onscreen button or link. The

user then verifies his or her identity, providing the appropriate input in accordance

with the signing room's security level, and further verifies the role to which the user

has been assigned. The present invention then allows the user to actively participate

in the signing room activities, including viewing, modification, and signing of

documents as his or her access level permits.

If desired, and if the access level permits such an operation, the user may cre¬

ate 2309 a new document within the virtual signing room. In one embodiment, the

user creates a new document by selecting from a number of available document

templates, filling in additional information as appropriate for the selected template,

attaching a digital signature (if applicable), and submitting the document to the vir¬

tual signing room. The document may then be made available to other users in the

room, if appropriate.

Referring to Figure 16B, there is shown a flowchart depicting a signing room

admittance procedure according to one embodiment of the present invention. In one

embodiment, the steps of Figure 16B are performed by presentation tier 342 as de¬

scribed above in the context of the overall architecture. The method of Figure 16B

may be performed, for example, in the context of selecting a signing room as in step

2306 of Figure 16A. When a user selects a signing room for access, the present invention verifies

2401 the permissions associated with the signing room, to ensure that the user is in

fact permitted to access the specified room. The user selects 2402 a role, as described

above, for his or her interaction with the documents and other parties in the signing

room. Other participants in the room are then notified 2403 of the presence of the

user, either by display of a dialog box, or an icon or other indicator, or by some other

means. If appropriate, the user is also added 2404 to any discussion groups that may

be taking place in the context of the room.

The user is also given an opportunity to check in documents that he or she

may have been creating and/ or modified in an off-line environment. The user sets

up 2405 permissions for the documents being checked in, and defines 2406 any re¬

quired processes associated with the documents (such as a signing sequence or other

transaction-related steps). The user also identifies 2407 the location or DOI of the

documents being checked in. A test may be performed 2408 of the virtual form of

the document (in other words, the representation of the document within the context

of the virtual signing room).

In addition, the user may define 2409 the outputs for the signing room, in¬

cluding for example whether templates, document creation or editing, and/ or trans-

actional signatures are to be provided in the context of the signing room.

Referring now to Figure 16C, there is shown a flowchart depicting an account

termination method according to one embodiment of the present invention. The

method of Figure 16C may be performed, for example, when a user wishes to termi¬

nate a signing room, such as when a transaction is completed or aborted. Upon re- ceipt of a user's request to terminate a signing room, the user's identity is verified

2501, as are the user's rights in connection with account termination. If the identity

rights are verified appropriately, the signing room is archived 2502 (such as to a CD-

ROM), and the signing room is deleted 2503.

In one embodiment, participants in the room are warned of the impending

deletion of the room. In alternative embodiments, the assent of other participants is

sought prior to deletion. Each party may then request a copy of the archive (CD-

ROM), if desired and appropriate.

Referring now to Figure 17, there is shown a flowchart depicting an example

of an electronic signature collection method according to one embodiment of the

present invention. The method of Figure 17 illustrates a particular application of the

present invention to the electronic collection of signatures for a petition. As such,

the various elements and specific components of Figure 17 are merely exemplary.

The invention presents a welcome screen 1701, as may be provided using a

web page viewable in a browser application. The welcome screen 1701 includes a

link or button allowing the user to access a selected initiative for viewing and/ or

signing. Once the user has selected an initiative, he or she selects 1702 a county from

a displayed list. In some cases, the displayed petition will vary depending on the

selected county.

The user is then presented with an entry screen 1703 for the virtual signing

room. The user is asked to select one of four roles, depending on the activity he or

she would like to perform with respect to the signing room. In the example of Fig- ure 17, the four available roles are petition viewer, petition signer, circulator (whose

function is to witness signatures and answer questions), and administrator.

If in screen 1703 the user selects the petition viewer role, the invention dis¬

plays a view petition screen 1704 from which the user can select various items for

viewing. In the context of a petition, examples include a proponent's statement, an

opponent's statement, press releases, and the like. In addition, a chat room facilitat¬

ing real-time communication may be provided and accessible from screen 1704, us¬

ing techniques that are known in the art.

If in screen 1703 the user selects the petition signer role, the invention deter¬

mines 1705 whether the user has previously set up a digital signature, as described

above. If so, the signature is verified 1706, and the user is given an opportunity to

sign 1708 the petition. In the context of a petition signing application, certain items

of information may be presented and/ or collected in the course of the signing opera¬

tion of step 1708, as shown in Figure 17. In one embodiment, drop-down lists may

be provided in the sign petition screen 1708, allowing the signer to "place" identify¬

ing information within the petition document itself in the course of signing it.

If in step 1705 the invention determines that the user has not previously set

up a digital signature, the user is prompted to enter identifying information (such as

driver's license number, social security number, and the like) to initiate the process

of configuring a new digital signature. Once the digital signature has been enabled,

the invention proceeds with step 1708.

After step 1708 has been completed, the invention determines 1709 whether

the registration data supplied by the user is valid. If so, the petition is signed 1710. Registration is reported as complete, the user is prompted to click a button to apply

the signature, a key pair is generated, the petition is signed with the private key, the

private key is deleted, a public key is attached to the petition, and the petition is

stored. If in step 1709 the registration data is not valid, the petition is not signed

1711. Registration is reported as not complete, a chat is initiated with the circulator

to resolve the registration problem, new registration data is obtained, and data is

submitted for matching with a registered voter list. Step 1709 may then be re-

attempted with the new registration data.

If in screen 1703 the user selects the circulator role, a logon/ logoff screen 1712

is presented allowing the user to specify whether he or she wishes to log on or log

off. If logon is selected, the user is presented with a logon screen 1713. If logoff is

selected, he or she is presented with a logoff screen 1714. Once the circulator has

logged on, he or she is able to perform relevant activities as are applicable, such as

witness signatures and the like.

If in screen 1703 the user selects the administrator role, several administrator

functions become available 1715, such as:

• setting up a new initiative;

• creating a new circulator;

• generating reports on signatures;

• generating totals;

• generating county subtotals;

• generating disk-based signature lists; • generating holographic labels for circulator use (where states may re¬

quire that the circulator prepare a label in his or her own handwriting);

• generating tools for county election officials to tabulate, verify, and/ or

withdraw signatures.

As mentioned previously, the specific items listed above in connection with

the example of Figure 17 are merely exemplary of one embodiment of the present

invention.

Referring now to Figures 18A-D, there are shown screen shots depicting an

example of a signing room according to one embodiment of the present invention.

Home page 1800 provides the user with options for selecting roles such as petition

viewer, petition signer, circulator, and administrator, as described above in step 1703

of Figure 17. Signing room 1801 shows an example of a petition as displayed in ac¬

cordance with the petition signer role. The title and a summary of the petition are

displayed, and the user is given an opportunity to digitally sign the petition as de¬

scribed in step 1708 of Figure 17. In the example of Figure 18B, the user is prompted

for a first name, middle name or initial, last name, address, city, ZIP code, and either

a social security number or California driver's license number, in order to initialize

the digital signature.

Page 1802, which may be displayed in connection with step 1710 of Figure 17,

confirms to the user that he or she is registered and may sign the petition by clicking

on the appropriate on-screen button 1804.

Page 1803, which may be displayed in connection with step 1711 of Figure 17,

opens a chat session with the circulator in order to resolve registration issues. The user can then communicate with the circulator over the chat channel, in accordance

with known techniques for on-line instant messaging or "chat".

Referring now to Figure 19, there is shown a flowchart depicting a deed re¬

cording method according to one embodiment of the present invention. The particu¬

lar sequence of steps shown in Figure 19 may be performed, for example, by a com¬

puter or set of computers following a set of instructions specified in software code.

The sample method of Figure 19 illustrates an application of the present invention to

a simple deed recording transaction, though one skilled in the art will recognize that

other types of transactions, including more complex transactions, could be enabled

using the present invention. A user prepares 1901 the deed using a conventional

browser interface with form fields and the like. Upon completion, the deed is auto¬

matically e-mailed 1902 to a recorder and received 1903 at a central server (not

shown). The invention parses 1904 the received deed in order to extract information

for storage in the database 1409; in addition, if the deed has been digitally signed,

information describing or confirming the digital signature is stored. If in 1905 a fil¬

ing fee is to be collected, the fee is collected 1906, for example by charging the user's

credit card or by effecting an electronic funds transfer.

If in 1907 the deed is not recordable, it is returned 1908 to the originator with

an explanation of the rejection. If it is recordable, the invention verifies 1909 the

document integrity 1909 and the digital signature 1910. If in 1911 the document is

not approved (e.g. due to problems with document integrity and/ or signatures), it is

returned 1912 to the originator with an explanation of the rejection. If the document is approved, the deed is recorded 1913 and a notice of record¬

ing is returned 1914. The deed, in digital form, is stored 1915 in database 1409 for

future use and access. Database 1409 is updated 1916 to reflect the recorded deed.

In addition, if desired, the deed is transmitted 1917 to the assessor, printed 1918 to

paper, and/ or printed 1919 to microfiche.

The above description is included to illustrate the operation of the preferred

embodiments and is not meant to limit the scope of the invention. The scope of the

invention is to be limited only by the following claims. From the above discussion,

many variations will be apparent to one skilled in the art that would yet be encom¬

passed by the spirit and scope of the present invention.

Appendix A

The following is an example of an XML-encoded document 102 correspond¬

ing to the agreement document depicted in Figures 6A-6B. One skilled in the art will

recognize that the document may be encoded by other means and in other languages

adapted to numerous specific applications and contexts.

<XML>

^ <BODY background="sandstrip_bkg_frame.gif"> <TABLE width="500"> - <TR>

- <TD>

<IMG alt="" src="logo_midsize.gif" /> </TD>

- <TD alιgn="right"> powered by <BR />

<IMG alt="" src="Hi Res Logo5trans.gif" style="HEIGHT: 31px; WIDTH: 137px" /> <BR />

Patents Pending <BR /> </TD> </TR> </TAB E>

- <FONT face="Ta oma">

<STRONG>U.S. Distributor Application & Agreement</STRONG> </FONT> <P />

- <TBS id="Morinda"> <TBS id="Applicant">

- <TABLE> ^ <TR>

- <TD alιgn="right">

<STRONG>Personal Information</STRONG> </TD>

- <TD>

(

<FONT color="red">*</FONT> Required Information) </TD> </TR>

- <TR>

- <TD>

- <AppName>

<INPUT value="*Last, First, Middle" s__ze="30" style="BACKGROUND-COLOR: bisque" /> </AppName> </TD> </TR>

- <TR>

<TD alιgn="right">Applicant's SS Number</TD>

- <TD> _ <AppSSN>

<INPUT sιze="ll" sty_e="BACKGROUND-

COLOR: bisque" vaiue="*nnn-nn-nnnn" /> </AppSSN>

<INPUT type="button" va_._e="Note" style="BACKGROOND-COLOR: tan" on- Clιck="alert( 'The Social Security Number is absolutely required. ' ) " /> </TD> </TR> <TR>

<TD alιgn="right">Spouse (or Co-Applicant's Name) </TD>

- <TD> _ <CoAppName>

<INPUT s__ze="30" sty_e="BACKGROUND- COLOR: bisque" va_ue="Last, First, Middle" /> </CoAppNa e>

<INPUT type="button" val_e="Note" style="BACKGROUND-COLOR: tan" on- Clιck="alert( 'Having a co-applicant is optional . It is highly recommended that the spouse information be filled out as the spouse is considered as having a beneficial interest in the distributorship.')" /> </TD> </TR> <TR>

<TD a1_.gn="right">Spouse (or Co-Applicant's) SSN</TD>

- <TD>

- <CoAppSSN>

~ <INPUT s_-ze="ll" styιe="BACKGROUND- COLOR: bisque" value="nnn-nn-nnnn" /> </CoAppSSN> </TD> </TR> <TR>

<TD alιgn="right">U.S. Mailing Address</TD>

- <TD>

- <AppAdd>

<INPUT sιze="30" value="*" style="BACKGROUND-COLOR: bisque" /> </AppAdd>

<INPUT type="button" value="Note" style="BACKGROUND-COLOR: tan" on- Clιck="alert( 'We must have a second address for shipping if your mailing address is a PO Box, or if you would like your AutoShip sent to an alternate address . ' ) " /> </TD> </TR> <TR>

<TD alιgn="right">City, State, Zip Code</TD> <TD>

- <AppCιty>

<INPUT sιze="10" value="*" style="BACKGROUND-COLOR: bisque" /> </AppCιty>

- <AppST>

^_ - <SELECT sιze="l" style="BACKGROUND- COLOR: bisque"> <OPTION>AL</OPTION> <0PTI0N>AK</0PTI0!!> <OPTION>AZ</OPTION> <OPTION>AR</OPTION> <OPTION SELECTED="">CA</OPTION> <0PTI0N>CO</0PTIO > <OPTION>CN</OPTIO_l> <0PTI0N>DE</0PTI0N> <OPTION>FL</OPTION> <OPTION>GA</OPTION> <OPTION>HA</OPTION> <OPTION>ID</OPTION> <OPTION>IL</OPTION> <OPTION>IN</OPTION> <OPTION>IO</OPTION> <OPTION>KA</OPTION> <OPTION>KY</OPTION> <OPTION>LO</OPTION> <OPTION>ME</OPTION> <OPTION>MD</OPTION> <OPTION>MA</OPTION> <OPTION>MK/OPTION> <OPTION>MN</OPTION> <OPTION>MO</OPTION> <OPTION>MT</OPTION> <OPTION>NE</OPTIO > <OPTION>NV</OPTION> <OPTION>NH</OPTION> <OPTION>NJ</OPTION> <OPTION>NM</OPTION> <OPTION>NY</OPTION> <OPTION>NC</OPTION> <OPTION>ND</OPTION> <OPTION>OH</OPTION> <OPTION>OK</OPTION> <OPTION>OR</OPTION> <OPTION>PN</OPTION> <OPTION>RK/OPTION> <OPTION>SC</OPTION> <OPTION>SD</OPTION> <OPTION>TN</OPTION> <OPTION>TX</OPTION> <OPTION>UT</OPTION> <OPTION>VT</OPTION> <OPTION>VK/OPTION> <OPTION>WA</OPTION> <OPTION>WV</OPTION> <OPTION>WI</OPTION> <OPTION>WY</OPTION> </SELECT> </AppST>

- <AppZip>

<INPUT style="BACKGROUND-COLOR: bisque" size="8" value="*nnnnn-nnnn" /> </AppZip> </TD> </TR> <TR>

<TD align="right">Date of Birth</TD> - <TD>

- <AppDOB>

- <SELECT size="l" styie="BACKGROUND- COLOR: bisque">

<OPTION selected=" ">Jan</OPTION> <OPTION>Feb</OPTION> <OPTION>Mar</OPTION> <OPTION>Apr</OPTION> <OPTION>May</OPTIOh>

<OPTION>Jun</OPTION>

<OPTION>Jul</OPTION>

<OPTION>Aug</OPTION>

<OPTION>Sep</OPTION>

<OPTION>Oct</0PTI0N>

<OPTION>Nov</OPTION>

<OPTION>Dec</OPTION> </SELECT>

<SELECT sιze="l" style="BACKGROUND- COLOR: bisque">

<OPTION selected="">01</OPTION>

<OPTION>02</OPTION>

<OPTION>03</OPTION>

<OPTION>04</OPTION>

<OPTION>05</OPTION>

<OPTION>06</OPTION>

<OPTION>07</OPTION>

<OPTION>08</OPTION>

<OPTION>09</OPTION>

<OPTION>10</OPTION>

<0PTI0N>1K/0PTI0N>

<0PTI0N>12</0PTI0N>

<OPTION>13</OPTION>

<OPTION>14</OPTION>

<OPTION>15</OPTION>

<OPTION>16</OPTION>

<OPTION>17</OPTION>

<0PTI0N>18</0PTI0N>

<OPTION>19</OPTION>

<OPTION>20</OPTION>

<OPTION>2K/OPTION>

<OPTION>22</OPTION>

<0PTI0N>23</0PTI0N>

<OPTION>24</OPTION>

<OPTION>25</OPTION>

<OPTION>26</OPTION>

<OPTION>27</OPTION>

<OPTION>28</OPTION>

<OPTION>29</OPTION>

<0PTION>30</OPTION>

<OPTION>3K/OPTION> </SELECT> ,19 <SELECT s__ze="l" style="BACKGROUND-

COLOR: bisque">

<OPTION selected="">0</OPTION>

<option>l</opt_.on>

<optιon>2</optιon>

<optιon>3</optιon>

<optιon>4</optιon>

<optιon>5</optιon>

<opt--θn>6</opt--θ-i>

<optιon>7</optxon>

<optιon>8</optιon>

<option>9</option> </SELECT>

<SELECT sιze="l" style="BACKGROUND- COLOR: bisque">

<optιon selected="">0</optιon>

<optιon>K/optιon>

<optιon>2</optιon>

<optιon>3</optιon>

<optxon>4</option>

<opt--on>5</option>

<optιon>6</optιon> <optιon>7</optιon> <opt_.on>8</opt-_on> <optιon>9</optιon> </SELECT> </AppDOB>

<I_IPUT type="button" va-.--e="Note" s yle="BACKGROUND-COLOR: tan" on- C__.ck="alert ( 'This is needed as verification that the new distributor is of legal age to be a distributor n the state of their residency. ') " /> </TD> </TR> <TR>

<TD alιgn="right">Daytιme Phone</TD>

- <TD>

- <AppDPh>

<INP0T sιze="10" style="BACKGROUND- COLOR: bisque" value="*nnn-nnn-nnnn" /> </AppDP >

<INPUT type="button" va!ue="Note" sryle="BACKGROUND-COLOR: tan" on- Clιck="alert ( 'Please indicate the numbers where you may be reached. ' ) " /> </TD> </TR> <TR>

<TD alιgn="right">Alternate Phone</TD>

- <TD>

^ <AppOPh>

<INPUT sιze="10" styie="BACKGROUND- COLOR: bisque" value="*nnn-nnn-nnnn" /> </AppOPh> </TD> </TR> <TR>

<TD alxgn="right">Evening Phone</TD>

- <TD>

- <AppEPh>

<INPUT sιze="10" style="BACKGROUND- COLOR: bisque" value="*nnn-nnn-nnnn" /> </AppEPh> </TD> </TR> <TR>

<TD alιgn="right">Cellular Phone</TD>

- <TD> <AppCPh>

<INPUT sιze="10" style="BACKGROUND- COLOR: bisque" value="nnn-nnn-nnnn" /> </AppCPh> </TD> </TR> <TR>

<TD alιgn="right">FAX</TD> <TD> <AppFAX>

<INPUT sιze="10" style="BACKGROUND- COLOR: bisque" valι_e="nnn-nnn-nnnn" /> </AppFAX> </TD> </TR> <TR> <TL alιgn="right">E-Mail Address</TD> <TD>

_ <AppEM>

<INPUT style="BACKGROUND-COLOR: bisque" sιze="30" /> </AppEM> </TD> </TR> <TR>

<TD alιgn="right" /> 2 <TD>

<INPUT type="button" vaiue="Generate Keys" onclιck="navigate ( 'morindagenerate.htm' ) " style="BACKGROUND-COLOR: tan" /> <INPUT type="button" va!ue="Explain" on- click="navigate ( 'http: //www.whatis.com/pki .htm')" style="BACKGROUND-COLOR: tan" /> </TD> </TR> <TR>

<TD align="right" /> <TD /> </TR> <TR> <TD alιgn="right">

<STRONG>*Personal Sponsor's Infor a- tion</STRONG> </TD>

- <TD>

The distributor that referred you to the company. <BR />

Placement and personal sponsors may be the same.

<INPUT style="BACKGROUND-COLOR: tan" orielick="alert ( 'Your placement and personal sponsor may be the same distributor if you are on the personal sponsors first level and have not been placed.')" type="button" value="Note" /> </TD> </TR> <TR>

<TD align="right">Name</TD> 2 <TD> <PSIName>

<INPUT size="30" style="BACKGROUND- COLOR: bisque" value="*Last, First, Middle" /> </PSIName> </TD> </TR> <TR>

<TD align="right">Phone</TD>

- <TD>

- <PSIPh>

<INPUT size="10" style="BACKGROUND-

COLOR: bisque" vaiue="nnn-nnn-nnnn" /> </PSIPh> </TD> </TR> <TR>

<TD align="right">ID Number</TD> <TD>

- <PSINum> < INPUT s ι ze="8 " styι e= "BACKGROUND-COLOR: bisque" value= "nnnnnnnn" /> </PSINu > </TD> </TR> <TR>

<TD al ιgn="right" /> <TD /> </TR> <TR>

- <TD alιgn="right">

<STRONG>Placement Informatιon</STRONG> </TD> <TD>

It is highly recommended that you <STRONG>

<EM>NOT</EM> </STRONG> fill out placement information upon sign-up . <INPUT one1ιck="alert ( 'The Placement Sponsor is the distributor that you are placed directly under . Placement sponsor must be in the downline of your Personal sponsor. It is highly recommended that you NOT fill out placement information upon sign-up. Leaving it blank will give your personal sponsor 120 days to determine where to place you using a placement sponsor change form. This is your one placement. If you are placed anywhere other than your Personal Sponsors first level , you cannot be moved.')" style="BACKGROUND-COLOR: tan" type="button" value="Note" /> </TD> </TR> <TR>

<TD alιg-.="right">Name</TD> 2 <TD>

- <PIName>

<INPUT s-_ze="30" style="BACKGROUND- COLOR: bisque" value="Last, First, Middle" /> </PIName> </TD> </TR> <TR>

<TD al_.gn="right">Phone</TD>

- <TD>

2 <PIPh>

<INPUT sιze="10" style="BACKGROUND-

COLOR: bisque" value="nnn-nnn-nnnn" /> </PIPh> </TD> </TR> <TR>

<TD al-.gn="right">ID Number</TD>

- <TD>

- <PINum>

<INPUT sιze="8 " style="BACKGROUND-COLOR: bisque" value="nnnnnnnn" /> </PINuιn> </TD> </TR> <TR>

<TD al_.gn="right" /> <TD /> </TR>

<TR>

2 <TD alιgn="πght">

<STRONG>Case AutoShip Program</STRONG> </TD>

- <TD>

<I on) "

me in Morinda ' s Case AutoShip Program. </TD> </TR> <TR>

<TD alιgn="πght" /> <TD /> </TR> <TR>

- <ΥO lιgn="rιght">

<STRONG>Nonresιdent Alien Distπbu- tors</STRONG> </TD>

- <TD> <AppAlιen>

<INPUT type="checkbox" style="BACKGROUND-COLOR: bisque" /> </AppAlιen>

I am living n the United States, but am not a U.S. Citizen . Nonresident Aliens in the U.S. are required by law to submit an IRS Form W-8 </TD> </TR> <TR>

<TD alιgn="πght" /> <TD /> </TR> <TR> <TD alιgn="πght">

<STRONG>Sιgn-up fee</STRONG> </TD>

<TD>non-refundable $20.00</TG> </TR> <TR>

<TD

of payment</TD> 2 <TD> <AppPay>

- <SELECT sιze="l" style="BACKGROUND- COLOR: bisque">

<0PTI0N selected="">VISA</OPTION> <0PTI0N>M/C</0PTI0N> <OPTION>DISCOVER</0PTION> </SELECT> </AppPay> OR

<INPUT type="button" value="ACH" on-

( 'morindaACH.htm' ) " style="BACKGROUND-COLOR: tan" /> </TD> </TR> <TR>

<TD alιgn="πght">Credιt Card #</TD> <TD> <AppCCN>

<INPUT style="BACKGROUND-COLOR: bisque" /> </AppCCN> Exp Date <AppED>

2 <SELECT sιze="l" style="BACKGROUND- COLOR: bisque">

<OPTION selected="">Jan</0PTION> <OPTION>Feb</OPTION> <OPTION>Mar</OPTION> <OPTION>Apr</OPTION> <OPTION>May</OPTION> <OPTION>Jun</OPTION> <OPTION>Jul</OPTIO > <OPTION>Aug</OPTION> <OPTION>Sep</OPTION> <OPTION>Oct</OPTION> <OPTION>Nov</OPTION> <OPTION>Dec</OPTION> </SELECT> <SELECT sιze="l" style="BACKGROUND- COLOR: bisque">

<OPTION selected="">1999</OPTION> <OPTION>2000</OPTION> <OPTION>200K/OPTION> <OPTION>2002</OPTION> <OPTION>2003</OPTION> <OPTION>2004</OPTION> </SELECT> </AppED> </TD> </TR> <TR>

<TD alιgn="right" /> <TD /> </TR> <TR> <TD alιgn="right" valιgn="top"> <STRONG>Signature</STRONG> </TD>

<TD>The undersigned hereby applies to become an independent distributor of Morinda, Inc. As an independent distributor, I agree to the Terms and Conditions and in the Morinda Distributor Manual. </TD> </TR> <TR>

2 <TD colspan="2" alιgn="middle">

<TEXTAREA readOnly="" style="BACKGROUND- COLOR: bisque; HEIGHT: 122px; WIDTH: 500px">TERMS AND AGREEMENT: Distributor and Morinda Inc. (Morinda) hereby agree to the ollowing terms and conditions : </TEXTAREA>

</TD> </TR> <TR>

<TD alιgn="right" /> <TD>

<INPUT type="button" value="Sign Document" style="BACKGROUND-COLOR: tan" on- clιck="navigate ( 'morindasignl .htm' ) " /> </TD> </TR> </TABLE> </TBS>

<SIGN xd="Applicant" /> </TBS> <SIGN ιd="Morinda" /> <CERT ιd="Applicant" /> <CERT ιd="Morinda" /> /BODY>

</XML>

Appendix B

The following is an example of an XML-encoded document 102 correspond¬

ing to the agreement document depicted in Figures 6A-6B, after it has been com¬

pleted and digitally signed. One skilled in the art will recognize that the document

may be encoded by other means and in other languages adapted to numerous spe¬

cific applications and contexts.

<XML>

2 <BODY background="sandstrip_bkg_frame.gif"> 2 <TABLE wιdth="500"> <TR> - <TD>

<IMG alt="" src="logo_midsize.gif" /> </TD> <TD alιgn="right"> powered by <BR />

<IMG alt="" src="Hi Res Logo5trans.gif" style="HEIGHT: 31px; WIDTH: 137px" /> <BR />

Patents Pending <BR /> </TD> </TR> </TABLE>

- <FONT face="Tahoma">

<STRONG>U.S. Distributor Application & AgreementsSTRONG> </FONT> <P />

- <TBS id="Morinda"> _ <TBS ιd="Applicant"> <TABLE> <TR>

- <TD alxgn="right">

<STRONG>Personal Informatιon</STRONG> </TD>

- <TD>

(

<FONT color="red">*</FONT> Required Information) </TD> </TR> - <TR>

<TD alxgn="right">Applicant's Name</TD> <TD>

<AppName>BROWN, BRUCE</AppName> </TD> </TR> 2 <TR>

<TD alxgn="right">Applicant's SS Number</TD> <TD> <ApDSSN>529-66-2094< /AppSS > < /TD> </TR> <TR>

<TD alιgn="πght">Spouse (or Co-Applicant ' s Name) </TD> _ <TD>

<CoAppName>BROWN , PATTK /Cc -opNa e> </TD> </TR> <TR>

<TD al ιgn="πght">Spouse (or Co-Applicant ' s) SSN< /TD> <TD>

<CoAppSSN>528-76-2759</Co^ -.cSSN> </TD> </TR> _ <TR>

<TD alιgn="πght">U. S . Mailing Address</TD>

- <TD>

<AppAdd>1684 North Sage Hen Road</AppAdd> </TD> </TR> <TR>

<TD alιqn="πght">Cιty, State, Zip Code</TD>

- <TD>

<AppCιty>OREM</AppCιty> <AppST>UT</AppST> <AppZιp>84097-2317</AppZιp> </TD> </TR>

- <TR>

<TD al ιgn="πght">Date of Bιrth</TD>

- <TD>

<AppDOB>FEB 01, 1952</AppD0B> </TD> </TR> <TR>

<TD

Phone</TD>

- <TD>

<AppDPh>801-852-8800</AppDPh> </TD> </TR>

- <TR>

<TD alιgn="rιght">Alternate Phone</TD> <TD>

<AppOPh /> </TD> </TR> <TR>

<TD alιgn="πght">Evenιng Phone</TD>

- <TD>

<AppEPh>801-225-0983</AppEPh> </TD> </TR>

- <TR>

<TD alxgn="πght">Cellular Phone</TD>

- <TD>

<AppCPh>801-376-0983</AppCPh> </TD> </TR>

- <TR>

<TD alιgn="rιght">FAX</TD>

- <TD>

<AppFAX>801-852-8810</AppFAX> </TD> </TR> <TR>

<TD alιgn="right">E-Mail Address</TD> <TD>

<AppEM>bruce@ilumin.com</_--;-;EM>

</TD> </TR> <TR>

<TD alιgn="right" />

<TD /> </TR> <TR> 2 <TD alιgn="right">

<STR0NG>*Personal Sponsor's Information/STR0NG>

</TD>

- <TD>

The distributor that referred you to the company. <BR />

Placement and personal sponsors may be the same.

<INPUT style="BACKGROUND-COLOR: tan" on- clxck="alert ( 'Your placement and personal sponsor may be the same distributor if you are on the personal sponsors first level and have not been placed. ')" type="button" value="Note" /> </TD> </TR> <TR>

<TD alxgn="right">Name</TD> 2 <TD>

<PSINa e>ISRAELSEN, D. BRENT</PSINa e> </TD> </TR> <TR>

<TD alxgn="right">Phone</TD> <TD>

<PSIPh>801-376-6166</PSIP > </TD> </TR> <TR>

<TD alxgn="right">ID Number</TD> <TD>

<PSINum>11223344</PSINum> </TD> </TR> <TR>

<TD alιgn="right" /> <TD /> </TR> <TR>

- <TD alxgn="right">

<STRONG>Placement Information</STRONG> </TD>

- <TD>

It is highly recommended that you <STR0NG>

<EM>NOT</EM>

</STR0NG> fill out placement information upon sign-up.

<INPUT onclxck="alert('The Placement Sponsor is the distributor that you are placed directly under. Placement sponsor must be in the downline of your Personal sponsor . It is highly recommended that you NOT fill out placement information upon sign-up. Leaving it blank will give your personal sponsor 120 days to determine where to place you using a placement sponsor change form. This is your one placement. If you are placed anywhere other than your Personal Sponsors first level, you cannot be moved.')" style="BACKGROUND-COLO : tan" type="button" value="Note" /> </TD> </TR> <TR>

<TD alxgn="right">Name</TD> <TD>

<PIName /> </TD> </TR> <TR>

<TD alxgn="right">Phone</TD> 2 <TD>

<PIP /> </TD> </TR> <TR>

<TD alxgn="right">ID Number</T0> <TD>

<PINum /> </TD> </TR> <TR>

<TD align="right" /> <TD /> </TR> <TR>

<TD alιgn="right" /> <TD /> </TR> <TR>

- <TD alxgn="right">

<STRONG>Nonresident Alien Distribu- tors</STRONG> </TD>

- <TD>

<AppAlxen>no</AppAlιen>

I am living in the United States, but am not a U.S. Citizen. Nonresident Aliens in the U.S. are required by law to submit an IRS Form W-8 </TD> </TR> <TR>

<TD alιgn="right" /> <TD /> </TR> <TR>

- <TD alxgn="right">

<STRONG>Sign-up fee</STRONG> </TD>

<TD>non-refundable $20.00</TD> </TR> <TR>

<TD alxgn="right">Method of payment</TD> <TD>

<AppPay>VISA</AppPay> </TD> </TR> <TR>

<TD alιgn="right">Credιt Card #</TD> _ <TD>

<AppCCN>3752-xxxxx-xxxx</ApcCCN> Exp Date

<AppED>Jan 2002</AppED> </TD> </TR> <TR>

<TD alιgn="right" /> <TD /> </TR> <TR>

- <TD alιgn="right" valιgn="top"> <STRONG>Sιgnature</STRONG> </TD>

<TD>The undersigned hereby applies to become an independent distributor of Morinda, Inc. As an independent distributor, I agree to the Terms and Conditions and in the Morinda Distributor Manual. </TD> </TR> 2 <TR> _ <TD colspan="2" alιgn="middle">

<TEXTAREA readOnly="" styιe="BACKGROUND- COLOR: bisque; HEIGHT: 122px; WIDTH: 500px">TERMS AND AGREEMENT: Distributor and Morinda Inc. (Morinda) hereby agree to the following terms and conditions : </TEXTAREA>

</TD> </TR> 2 <TR>

<TD alιgn="right" /> <TD /> </TR> </TABLE> </TBS>

Digital Signature of Applicant <BR />

<SIGN xd="Applicant">la 11 7c 4b c9 00 c3 dc 54 6e 3d c7 lb c4 6a 30 b7 54 5a lc 71 48 c8 ec be f8 dd fd ce fO 17 3d 17 05 d7 cd fb 47 37 d3 9c de ff 3b 64 0b la 4c 15 5b 7e cb a3 c4 bb le 84 37 2b 20 60 9c 83 0c</SIGN> <BR /> </TBS>

<SIGN ιd="Morinda" /> Certificate of Applicant <BR />

<CERT ιd="Applicant">e9 be 75 71 74 30 f2 96 8f 73 47 ee 43 c9 71 ec 27 98 6d 16 5b ec 55 e4 e5 81 9c c2 30 52 la f9 31 b3 55 06 02 dc 15 dl 02 11 41 b6 be 5a 9f d8 54 97 3a 02 8d 7c ca 2a 2c 7c fl 9a 8c 79 fe 54</CERT> <CERT ιd="Morinda" /> </B0DY> </XML>

Claims

ClaimsWhat is claimed is:

1. A computer-implemented virtual signing room for providing access to at

least one document by a plurality of users from a plurality of remote locations, compris¬

ing:

a document management module, for managing the at least one docu¬

ment, the document management module comprising a docu¬

ment-to-party mapping module for specifying access rights to

the at least one document; and

a deal management module, coupled to the document management

module, for maintaining a deal completion list containing

document-related task items.

2. The virtual signing room of claim 1, wherein the at least one document

is encoded in an extensible markup language (XML) format.

3. The virtual signing room of claim 1, wherein the document manage¬

ment module further comprises an audit module for tracking revisions to the at least

one document.

4. The virtual signing room of claim 3, wherein the document manage¬

ment module further comprises a notification module for automatically notifying at

least one user of a revision to the at least one document. AMENDED CLAIMS

[received by the International Bureau on 13 September 2000 (13.09.00); original claims 1 and 4. amended; new claims 5-50 added; remaining claims unchanged (11 pages)]

What is claimed is:

1. A computer-implemented virtual signing room for providing access to

at least one document by a plurality of users from a plurality of locations,

comprising:

a document management module, for managing the at least one document;

a party-to-document mapping module for specifying access rights to the at

least one document; and

a deal management module, coupled to the document management module,

for maintaining a deal completion list containing document-related

task items;

wherein the document management module permits access to the at least one

document responsive to the party-to-document mapping module indicating that a

user has access rights to the at least one document.

2. The virtual signing room of claim 1, wherein the at least one document

is encoded in an extensible markup language (XML) format.

3. The virtual signing room of claim 1, wherein the document

management module further comprises an audit module for tracking revisions to the

at least one document.

A M E N D E D S H έ¹E T (ARTICLE 19)

4. The virtual signing room of claim 1, wherein the document

management module accepts and applies a revision to the at least one document;

and wherein the document management module further comprises a

notification module for automatically notifying at least one user of the revision.

5. The virtual signing room of claim 4, wherein the notification module

notifies the at least one user of the revision by displaying a dialog box responsive to

the user accessing the virtual signing room.

6. The virtual signing room of claim 4, wherein the notification module

notifies the at least one user of the revision by transmitting an electronic mail

message to the user.

7. The virtual signing room of claim 4, wherein the notification module

retrieves an indicator specifying a notification medium for a portion of the document

corresponding to the revision, and wherein the notification module notifies the at

least one user of the revision via the specified notification medium.

8. The virtual signing room of claim 1, wherein the document

management module accepts and applies a revision to the at least one document

responsive the party-to-document mapping module indicating that a user has access

rights permitting revision of the at least one document.

9. The virtual signing room of claim 1, wherein the party-to-document

mapping module specifies access rights to a portion of at least one document.

10. The virtual signing room of claim 9, wherein the document

management module further accepts a revision to the portion of the at least one

document responsive to the party-to-document mapping module indicating that a

user has access rights permitting revision of the portion.

11. The virtual signing room of claim 1, wherein the party-to-document

mapping module specifies access rights to a first portion of a document and different

access rights to a second portion of the document.

12. The virtual signing room of claim 1, wherein the party-to-document

mapping module comprises:

a role identifier for defining a signing role for each of at least one user; and

a map, coupled to the role identifier, for associating each signing role with at

least one document.

13. The virtual signing room of claim 12, wherein the role identifier

comprises an authenticator for authenticating the identity of the at least one user,

and for verifying the authority of the user to sign the document.

14. The virtual signing room of claim 13, wherein the authenticator

authenticates the identity of the user by public key cryptography.

15. The virtual signing room of claim 13, further comprising:

a smartcard reader, coupled to the authenticator, for reading a private key

from a smartcard provided by the at least one user;

A M E N D E D S H E T (ARTICLE 19) and wherein the authenticator authenticates the identity of the user by

validating the private key.

16. The virtual signing room of claim 13, wherein the authenticator

authenticates the identity of the user by receiving and validating biometric data of

the user.

17. The virtual signing room of claim 13, wherein the authenticator

authenticates the identity of the user by receiving a passcode from the user and

validating the received passcode.

18. The virtual signing room of claim 12, wherein the role identifier

receives input from a user specifying a signing role.

19. The virtual signing room of claim 12, wherein the role identifier

retrieves data from a stored cookie specifying a signing role.

20. The virtual signing room of claim 12, wherein the party-to-document

mapping module further retrieves a list of documents available for signing by the at

least one user, based on the defined signing role.

21. The virtual signing room of claim 20, further comprising:

a parser, coupled to the role identifier, for identifying at least one portion of

the at least one document, to be signed by the at least one user;

and wherein the party-to-document mapping module retrieves the list of

documents available responsive to the identification by the parser.

22. The virtual signing room of claim 1, wherein the deal completion list

comprises document-related task items including at least one selected from the

group consisting of:

at least one signature to be applied to a document;

at least one data item to be provided;

a deadline date for applying a signature to a document; and

a signing sequence for a document.

23. The virtual signing room of claim 1, wherein the deal management

module further comprises a next step module for monitoring a current status and

next step specified by the deal completion list.

24. The virtual signing room of claim 23, wherein the deal management

module updates the deal completion list responsive to at least one selected from the

group consisting of:

application of a signature to a document;

revision of a document;

deletion of a document; and

creation of a document.

25. The virtual signing room of claim 1, wherein the virtual signing room

is accessible to at least one of the users over a network.

26. A computer-implemented collaborative document editing system,

comprising:

a document management module, for managing at least one document; an input device, for receiving user input specifying at least one revision to the

at least one document;

a storage device, coupled to the document management module, for storing

revision privileges for at least one user;

a party-to-document mapping module, coupled to the storage device, for

retrieving revision privileges from the storage device;

a revision module, coupled to the input device, to the document management

module, and to the party-to-document mapping module, for,

responsive to the revision privileges permitting the user to edit the

document, modifying the document according to the specified

revision; and

an audit module, coupled to the revision module, for, responsive to the

revision privileges permitting the user to edit the document, tracking

the specified revision to the document.

27. The system of claim 26, wherein the storage device stores revision

privileges corresponding to at least a portion of the at least one document.

28. The system of claim 26, further comprising a notification module,

coupled to the audit module, for automatically notifying at least one user of a

revision to the at least one document.

29. The system of claim 26, wherein the input device receives user input

from a remote user over a network.

30. The system of claim 26, wherein the party-to-document mapping

module comprises:

a role identifier for defining a role for each of at least one user; and

a map, coupled to the role identifier, for associating each role with at least one

document;

and wherein each retrieved revision privilege corresponds to least one role.

31. The system of claim 30, wherein the role identifier comprises an

authenticator for authenticating the identity of the at least one user, and for verifying

the authority of the user to edit the document.

32. The system of claim 31, wherein the authenticator authenticates the

identity of the user by public key cryptography.

33. The system of claim 31, further comprising:

a smartcard reader, coupled to the authenticator, for reading a private key

from a smartcard provided by the at least one user;

and wherein the authenticator authenticates the identity of the user by

validating the private key.

34. The system of claim 31, wherein the authenticator authenticates the

identity of the user by receiving and validating biometric data of the user.

35. The system of claim 31, wherein the authenticator authenticates the

identity of the user by receiving a passcode from the user and validating the

received passcode.

36. The system of claim 26, wherein the party-to-document mapping

module retrieves revision privileges for each of at least two portions of the

document, and wherein the revision module modifies the document responsive to

the revision privileges for a portion of the document corresponding to the specified

revision permitting the user to edit the portion.

37. The system of claim 36, wherein each portion corresponds to a field.

38. The system of claim 26, further comprising an output device, coupled

to the party-to-document mapping module;

wherein the party-to-document mapping module further retrieves viewing

privileges for the at least one document;

and wherein, responsive to the viewing privileges for a document permitting

the user to view the document, the output device outputs the document.

39. The system of claim 26, further comprising an output device, coupled

to the party-to-document mapping module;

wherein the party-to-document mapping module further retrieves viewing

privileges for at least a portion of the at least one document; and wherein, responsive to the viewing privileges for a portion of a document

permitting the user to view the portion, the output device outputs the portion.

40. The system of claim 39, wherein each portion corresponds to a field.

41. The system of claim 26, further comprising a check-in module, coupled

to the document management module, for receiving at least one document from an

off-line source.

42. The system of claim 26, wherein the input device accepts input

specifying privileges for at least one document.

43. A computer-implemented method for collaborative document editing,

comprising:

storing revision privileges for at least one user;

receiving user input specifying at least one revision to the at least one

document;

retrieving revision privileges;

responsive to the revision privileges permitting the user to edit the document:

modifying the document according to the specified revision; and

tracking the specified revision to the document.

44. The method of claim 43, further comprising notifying at least one user

of a revision to the at least one document.

45. The method of claim 43, further comprising:

defining a role for each of at least one user; and associating each role with at least one document;

and wherein each retrieved revision privilege corresponds to least one role.

46. The method of claim 45, further comprising:

authenticating the identity of the at least one user; and

verifying the authority of the user to edit the document.

47. A computer program product comprising a computer-usable medium

having computer-readable code embodied therein for collaborative document

editing, comprising:

computer-readable program code configured to cause a computer to store

revision privileges for at least one user;

computer-readable program code configured to cause a computer to receive

user input specifying at least one revision to the at least one document;

computer-readable program code configured to cause a computer to retrieve

revision privileges;

computer-readable program code configured to cause a computer to,

responsive to the revision privileges permitting the user to edit the

document:

modify the document according to the specified revision; and

track the specified revision to the document.

48. The computer program product of claim 47, further comprising

computer-readable program code configured to cause a computer to notify at least

one user of a revision to the at least one document.

49. The computer program product of claim 47, further comprising:

computer-readable program code configured to cause a computer to define a

role for each of at least one user; and

computer-readable program code configured to cause a computer to associate

each role with at least one document;

and wherein each retrieved revision privilege corresponds to least one role.

50. The computer program product of claim 49, further comprising:

computer-readable program code configured to cause a computer to

authenticate the identity of the at least one user; and

computer-readable program code configured to cause a computer to verify

the authority of the user to edit the document.

STATEMENT UNDER PCT ARTICLE 19(1)

The above amendments to the Claims are being submitted in accordance with the Patent Cooperation Treaty Article 19.

The above-described amendments include the amendments made to the related U.S. case which is pending.

The above-described amendments do not go beyond the disclosure of the international application as filed, and entry of these amendments is respectfully requested.

Replacement sheets effecting the above-described amendments are being transmitted herewith.