WO2003058493A1

WO2003058493A1 - Document management and multi party collaboration system

Info

Publication number: WO2003058493A1
Application number: PCT/AU2003/000024
Authority: WO
Inventors: Paul Antony Clark
Original assignee: Secure Document Exchange Pty. Limited
Priority date: 2002-01-11
Filing date: 2003-01-13
Publication date: 2003-07-17
Also published as: GB2401698A; AUPR994102A0; GB0417707D0

Abstract

The present invention provides a system and method for managing electronic documents. The invention generally provides a methodology enabling one or more users from within one of a plurality of discreet access groups to connect to a server via a network and enabling said one or more users in said access groups to modify and communicate a document within one or more of the access groups, wherein the ability of the users of said groups to access the document is determined by a permission level allocated to the users.

Description

DOCUMENT MANAGEMENT AND MULTI PARTY COLLABORATION SYSTEM

FIELD OF INVENTION

The present invention relates to an apparatus and a method for a document management and multi party collaboration system over a closed or open network such as the Internet .

BACKGROUND OF THE INVENTION

Document management systems which manage and permit multiple users to store and retrieve electronic documents on open and closed networks are known. Moreover, document management systems which are capable of tracking successive changes to documents (i.e. electronic filing systems which keep track of different versions of documents) are also known. These systems typically list an original document and subsequent versions of the original document sequentially.

In a variation on these electronic document management systems, some recent systems are further capable of assigning a user access level attribute to individual documents, giving an operator (i.e. a user who is responsible for managing a particular document in the document management system) the ability to assign an attribute to an individual document. For example, an operator may be able to set a user access level attribute such that another user may be able to read a document, but not edit the document. Alternatively, the other user may be denied access to the document.

As an example, Internet based "virtual deal rooms" such as ERoom™ provide a web-based environment which provides the aforementioned document management features. Moreover, ERoom™ also provides other work related functions and tools, such as a discussion forum, where users can post comments with regard to a particular document in the virtual deal room.

However, these virtual deal rooms have a single access group, and each member is assigned one of the access levels referred to above. That is, they are either able to a) read and edit the document, b) read the document but not edit it, or c) are denied access to the document. There is no facility for some but not all of the users in the virtual deal room to privately collaborate on a version of the document . When a user is allowed to both read the document and edit it, the typical process requires the user to download the document from a remote server to their local workstation.

When such a process takes place, a flag is set within the document management system, to indicate that the document has been "checked out" . When a document is checked out, it is locked, such that other users cannot edit the document, and at most can only read the document. Another user with writeable access to the document will only be allowed write access to the document when the original user has up loaded the same or a new version of the document back to the document management system.

Consequently, in order to amend a document, a user with writeable access must wait until the document is checked back in.

SUMMARY OF INVENTION

In a first aspect, the present invention provides a method for managing electronic document (s) comprising the steps of, enabling one or more users from within each one of a plurality of discrete access groups to connect to a server via a network, enabling said one or more users in said discrete access groups to modify and communicate a document within one or more of the access groups, wherein the ability of the users of said access groups to access the document is determined by a permission level allocated to said users.

The system enables any number of users to simultaneously download a copy of the document from a ^'remote server to their local workstation, edit the document , and upload the document to the remote server at their own discretion. Moreover, the system ensures that multiple versions of documents do not become confused or overwritten inadvertently.

The document exchange and multi party collaboration system allows a user to decide which other users will have access to a document, by being able to upload an amended version of a document with an attribute which limits those who have access to it. In effect, it allows a user to set the permission levels on a document such that the user may exclude selected other users from viewing or amending the document .

The system further allows for multiple groups of users ("access groups") with each access group being able to collaborate on and make a version of a document available internally only to users within the access group (so that other access groups cannot have access to the version) or available both internally as well as to one or more other specified access groups.

Preferably, a user may create an access sub-group, being the same or a smaller number of users within the discreet access group, and modify and communicate a document privately within the discreet access group and/or sub-groups or publicly with other discreet access groups or sub-groups.

Preferably, access to a document within a group and/or a sub-group is further determined by the document version type and the access group or sub-group to which the user who uploaded it belongs.

In addition to setting the permission levels to a particular group, a user who sets up a group and/or a sub- group, may also attach an attribute to a particular document within a group and/or a sub-group, to further limit the access that other users may have to the document . For example, a document may be given an attribute such that all users within a group may be able to view the document and amend the document. Alternatively, a user may provide the document with an attribute such that the document may be viewed by other members of the sub-group, but may not be altered by other members of the sub-group.

Preferably, a sub-set of groups and/or sub-groups may be grouped together to form a transaction group. The transaction group is effectively an "umbrella" group, which comprises all of the relevant parties in a "transaction" .

A transaction is designed to encompass any and all communications and documents which pertain to a particular matter. For example, in a legal environment, a transaction group may encompass all parties and legal advisors who are negotiating a particular contract. The "transaction" could include an electronic version of the original contract, all versions of the contract, and all discussions and ancillary communication with regards to the contract . Preferably, there is provided the further step of encrypting the documents and communications during transmission between a user's workstation and the server and vice versa. This allows documents and communications to be exchanged securely with other users. Preferably, there is also provided the further step of encrypting the documents and communications on the server to assist in preventing unauthorised access.

Preferably, threaded discussion forums for each document are associated with each group, sub-group and/or transaction group, where a user may create a threaded discussion on a document within a transaction group, access group and/or access sub-group. The provision of threaded discussion forums for each document allows a user to communicate securely with other users in the transaction group or a selected access group and/or access sub-group. Moreover, it allows all discussion forum communications on a document to be located adjacent to the document.

In other words, the provision of threaded discussion forums for each group provides a "paper trail" which allows a user to easily review not only the documents, but all ancillary information pertaining to the documents. Furthermore, the ancillary information is automatically created and stored, without the need for a user to take separate and time consuming notes. For example, traditionally a user may have kept manual records of each telephone conversation pertaining to a document, whereas now, if communication is conducted via the document exchange and multi party collaboration system, there is no need for a user to take separate notes. In a similar fashion to the permission levels attributed to documents, discussion "posts" in the discussion forum may also be attributed a permission level, so that only certain parties may be able to view a particular post.

Preferably, a messaging system is provided such that one user may privately send a message to another user.

As with the discussion forums, this provides the dual benefits of allowing one party to contact another conveniently, whilst concurrently providing an easily accessible record of all such messages. Preferably all messages in a transaction are attached to the transaction record.

Preferably, there is provided an archiving function arranged to archive all relevant access groups and/or subgroups within a transaction group. The archiving function allows a user to "bundle up" all relevant information when a transaction has been completed, and either copy the information to a "back up" at another secure location, or perhaps print out hard copies of all relevant information, such that it may be placed on a file, or archived in any other suitable way. This provides the advantage of allowing a user to easily transport all relevant information pertaining to a transaction.

Preferably, there is provided the further step of compressing a document when it is uploaded to the document management system. Preferably, there is provided the further step of uncompressing a document after it is downloaded to a user terminal .

This allows a user to upload and download documents more quickly using less bandwidth than if the documents were not compressed.

In a second aspect the present invention provides a method for managing electronic document (s) comprising the steps of, enabling a user from within a discrete access group, that is comprised of one or more users, to connect to a server via a network, enabling the user to access on the server document (s) of the discrete access group, wherein more than one user of a discrete access group may simultaneously download a copy of the document from the server and/or upload a modified or unmodified copy of the document to the server. In a third aspect, the present invention provides an apparatus for managing electronic documents comprising, an enabling means arranged to allow one or more users from within each one of a plurality of discrete access groups, to connect to a file server via a network, a modifying means arranged to allow said one or more users in discrete access groups to modify and communicate a document within one or more of the access groups, whereby the ability of the users of said access groups is determined by a permission flag allocated to said users . BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described, by way of example only, with reference to the accompanying diagrams, in which:

Figure 1 is a block diagram of a system for managing and collaborating on documents in accordance with an embodiment of the present invention which adopts a three tier architecture,

Figure 2 is a diagram of the components of the database in that embodiment,

Figure 3 is a diagram depicting some elements of a sample transaction in accordance with an embodiment of the present invention,

Figure 4 is a table that depicts which of documents 32 to 32f can be seen by and are available to users in each of the access sub-groups, as well as the document version types and the status of the documents at the conclusion of the sample transaction, and

Figure 5 is a flow chart depicting the methodology of determining whether a user has access to a particular document version and the type of access available and what attributes the user may assign to the modified copy of the document when it is subsequently uploaded.

DESCRIPTION OF PREFERRED EMBODIMENT

In the following description of an embodiment of the invention, it will be understood that the invention may be implemented as hardware and/or software using an appropriate platform such as a computing system in any one of a number of configurations and architectures.

The present invention in its preferred form relates to a system and method for providing a document management and multi party collaboration system.

Referring to the drawings, in figure 1 there is shown a system for managing and permitting multi party collaboration on documents. On a computing system 1 resides an application and file server 2 providing numerous functions including document management and collaboration, discussion forums, messaging, workflow management and archiving, supported by a common database 3.

In figure 2 the main components of the database 3 are shown. The database 3 is arranged to include a table of all users of the system, information relating to each user, grouping of documents in Transactions, details of users who are participants in each Transaction, information in relation to the access group, access subgroup and permission levels for each participant in the Transaction, information on the documents in the

Transaction, information on the versions of each document in the Transaction including the attributes of each version (called the "version type" and "status"), information on discussion forums for each document and information on messages between Transaction participants. It will be noted that the electronic documents may be in any appropriate format, and may take the form of text documents, images, sound files, video files, or any other form. In this embodiment a user interface 5, or alternatively 5 and 7 or alternatively 5 and 8 is arranged to allow a remote terminal 6 ("client") to obtain and/or download and upload documents and other information from the computing system 1. It will be understood that the computing system may be any appropriate computing system in any suitable, configuration or architecture, and may include a web server application, a database, and a file server, the computing system being arranged to reside on a network such as the Internet, an internal intranet or extranet or on any other suitable network.

The application and file server 2, in addition to - Sh allowing a number of access groups in a transaction, also allows users in certain access sub-groups ("primary subgroups" ) to add other users to the access group and assign the sub-group of the access group to which each is to belong and to remove other users from the access group. The application and file server 2 also allows either a user or any member of an access sub-group to add and/or remove other users to or from the access sub-group. The application and file server 2 further allows a user in a primary sub-group, when adding users to that or any other sub-group within the access group, to allocate permission levels to those users. In one embodiment of the invention those permission levels cannot exceed the allocating user's permission levels. When a user with an appropriate permission level downloads a copy of a document and modifies the document, the user may subsequently upload the modified document copy to the server, and may assign an attribute (or "version type") to the document copy. The attribute controls whether the modified document copy can itself subsequently be modified and, combined with the document status and the access group or sub-group of which the user is a member, controls which other users can access the modified document copy in accordance with their permission levels.

Figure 3 exemplifies an embodiment of the document management system by providing a specific example of the present invention as applied to a legal transaction. In the present example there are two access groups, one (18) comprising law firm A (20) (see Figure 3) and client A (22) and the other (19) comprising law firm B (21) and client B (23) (see Figure 3) . Each of those access groups comprises two access sub-groups. The first mentioned access group (18) comprises a firm sub-group law firm A (20) (which is the primary sub-group) comprising two users, namely lawyer Al (24) and lawyer A2 (25) and a client subgroup client A (22) comprising client Al (26) and client A2 (27) . The second access group (19) similarly comprises two access sub-groups namely a firm sub-group law firm B (21) (which is the primary sub-group) comprising lawyer Bl (28) and lawyer B2 (29) and a client sub-group client B (23) comprising client Bl (30) and client B2 (31) .

Each of the users in the Transaction is allocated a permission level as shown. Referring to Sheet 1, in Step 1 a first draft of a legal document 32 is uploaded to the server. In Step 2 each of Client Al (26) and lawyer Bl (28) subsequently and simultaneously downloads a copy of the document 32 to his/her local computing system. Each then makes amendments to the copy of document 32. Client Al (26) then uploads his/her amended copy to the server, assigning to it the attributes of an internal draft 32a such that it can only be seen and is only available to members of the client A (22) sub-group, namely clients Al and A2. A copy of the document 32a can subsequently be downloaded and modified by client Al (26) and client A2 (27) and may thereafter be uploaded either as an overwrite of the internal draft 32a or as a new internal or a new private draft. Lawyer Bl (28) may simultaneously upload his/her modified copy of document 32 to the server assigning to it the attributes of a private draft 32b such that it can only be seen and is only available to members of lawyer Bl's (28) access group (19) (namely law firm B (21) and client B (23) ) and cannot subsequently be modified.

Referring to Sheet 2, in Step 3 client A2 (27) subsequently downloads a copy of internal draft 32a, causing that internal draft to be given a "checked out" status. Client A2 (27) may then amend and upload the document to the server, assigning to the document the attributes of a private draft document 32c. Therefore, it can only be seen by, and is only available to, members of client A2 ' s (27) access group (18) (namely law firm A (20) and client A (22)). Moreover, the document cannot subsequently be modified. Internal draft 32a and private draft document 32c are consequently assigned a "checked in" status.

Simultaneously client Bl (30) may download a copy of private draft document 32b from the server, modify the document, and upload it to the server, assigning to the document the attributes of a new private draft document 32d. Referring to Sheet 3, in Step 4 Lawyer Bl (28) may then download a copy of the private draft 32d from the server, modify the document and upload the document to the server, assigning to the document the attributes of a public review draft document 32e such that it can be seen and accessed by all users in the Transaction.

In Step 5 Lawyer Al (24) may download a copy of private draft document 32c from the server and subsequently download a copy of public review draft document 32e from the server, make amendments to private review draft 32c, and upload the document to the server, assigning to the document the attributes of a new version 32f such that it can been seen and accessed by all participants in the Transaction but cannot be modified.

Referring to Sheet 4 in Step 6, lawyer Bl (28), lawyer B2 (29) , client Bl (30) and client B2 (31) may all separately download a copy of document 32f. Lawyer Bl (28) may upload document 32g without modification, assigning to the document the attributes of "public review draft, no amendment". In this example, the Transaction is complete .

Concurrently, (i.e. during steps 1 to 6) , lawyer A2 (25) may post a comment on the document to a private discussion forum on the document such that only members of that user's access group (18) (namely law firm A (20) and client A (22) ) may access and post a reply to the comment in the discussion forum. Lawyer B2 (29) may also post a comment on the document to a public discussion forum so that the comment may be viewed by all members of both access groups, but a reply may only be posted by users with "write public draft/version" or greater permission level, namely users in law firm A (20) and law firm B (21) .

It will be understood that the preceding example is only given to provide a simplified account of a typical transaction that may be conducted by an embodiment of the present invention. This example merely represents one of a large number of possible actions available to a user, and it will be understood that a user may take many other possible actions, as allowed by the present embodiment and by other embodiments that fall within the scope of the present invention. It will further be understood that in the embodiment described in the example, any combination of permission levels may be set, any number of access groups and access sub-groups within each access group may be created, any number of users may reside in each group or sub-group and a transaction may contain any number of documents, as is needed in the circumstances.

In Figure 5, there is shown a flow chart depicting the methodology of determining whether a user has access to a particular document version and the type of access available to the user, in addition to the attributes the user may assign to the modified copy of the document when it is subsequently uploaded. In this example, when a user initially uses the same document management and multi party collaboration system, (hereinafter referred to as "the system"), the system checks whether a transaction exists (1) . If the transaction does not exist, then access to the transaction is denied (2) . If the transaction exists, then the system checks whether the document requested belongs to the transaction (3) . If it does not, then access is denied (2) . If the document belongs to the transaction (3) , then the version type is checked (4) . If the version type of the document is not acceptable, then access is denied (2) . If the version type is acceptable, then the system will check whether the user is allowed to participate in the transaction (5) . If the user cannot participate in the transaction (that is, the user is not a member of the transaction group) then access is denied (2) . If the user is a valid participant in the transaction, then the system will check which party (i.e. which access group or sub-group) the user belongs to (6) , as well as checking the version type of the document (i.e. whether the document is an internal, private or public version) (7) .

If the document version type is "public", then the first branch of the decision tree (8) will be followed. However, if the document version type is "private" or "internal", the second branch of the decision tree (9) will be followed.

Turning to the first branch of the decision tree (i.e. where the document version type is "public"), it is shown that the system will check whether the document is a published version or a public review version (10) . If the document is a published version, the system will then check whether the document has the most recent version number (11) . If the document does not have the most recent version number, then the user may only copy out the document (12) . If, however the document does have the most recent version number, then the system will check whether the user has write permission on the particular document (13) . If the user does not have write permission, then the user may only copy out the document (12) . If the user does have write permission, then the system will check whether another user in the same access group and/or sub-group has "checked out" (i.e. downloaded the document with the intention of modifying and subsequently uploading the modified document) the same version number of the document (14) . If another user in the same access group and/or sub-group has checked out the same version number of the document, then the user may only copy the document (12) . If another user in the same access group or sub-group has not checked out the document, then the user may check out this version on behalf of the access group and/or sub-group (i.e. the user may read the document and modify the document) (15) .

If, however the document version type is "public review", then the system will check whether the public review version was uploaded by a member of the same access group and/or sub-group that the user belongs to (16) . If the document version was not uploaded by a member of the same access group and/or sub-group as the user (16) , then the user may copy the document or download it as a private version depending on the permission levels assigned to the user (17) . If however, the document version was not uploaded by a member of the same access group and/or subgroup, then the system will determine whether the document version is the most recent version (18) . If it is not, then the user may only copy out the document (19) . If the document version is the most recent version, then the system will check whether another user in the same access group and/or sub-group has checked out the document (20) . If another user in the same access group and/or sub-group has checked out the document, then the user may only copy out the document (19) . If, however, another user in the same access group or sub-group has not checked out the document, then the system will check whether the user has write permission (21) . If the user does not have write permission, then the user may only copy out this version

(19) . If the user, however, does have write permission, then the user may check out this version (22) .

Returning to the status of the document version, if the document is a "private" or "internal" version type, then the second branch of the decision tree (9) is followed. The system will firstly check whether the user belongs to the same access group as the user who uploaded the document version (23) . If the user does not belong to the same access group then access will be denied (24) . If the user does belong to the same access group, then the system will check whether the document is "checked in" or "checked out" (25) . If the document is checked in, then the system will check whether the document is an internal version or a private version. (26) . If the document type is "private version", then the system will check whether the user has write permission (27) . If the user does not have write permission, then the user may only copy out a version of the document (28) . If the user has write permission, then the system will further check whether the document is the current version (29) . If it is not the current version, then the user may only copy out the document (28) . If it is the current version, then the system will further check whether another user in the same access group and/or sub-group has checked out this version of the document (30) . If a user in the same access group and/or sub group has checked out this version of the document, then a user may only copy out this version of the document (28) . However, if no other user in the same access group and/or sub-group has checked out this version of the document, then the user may check out this version of the document (31) . Returning to step 26, if the document is an internal draft, then the system will further check whether the user is in the same access sub-group as the user who uploaded the document (32) . If the user is not within the same access sub-group, then the user is denied access to the document (33) . If however, the user is within the same access sub-group, then the system will further determine whether the user has write permission for internal drafts (34) . If the user does not have write permission, then the user may only copy out the document (35) . If the user has write permission, then the system will check whether the document is the most current version (36) . If the document is not the most current version, then the user may only copy out the document (35) . If, however the document is the most current version, then the system will further check whether another user in the same access subgroup has checked out the internal draft (37) . If another user in the same access sub-group has checked out the internal draft, then the user may only copy out this version of the document (38) . If however another user in the same access sub-group has not checked out this version of the document, then the user may check out the document (39) .

Returning now to step 25, if the document has been checked out, then the system will check which other user has checked out the document (40) . If the user making the inquiry is the same user who has checked out the document, then the system will check whether the user has public write permission (41) . If the user does not have public write permission, then the system will check whether the document is an internal draft (42) . If the document is an internal draft, then question 8 will be asked (43) . Otherwise, if the document is not an internal draft, then question 7 will be asked (44) .

If the user has write permission, then the system will determine whether the user belongs to the same access group and/or sub-group as the document author (the original user who created the document) of the document

(45) . If the user does not belong to the same access subgroup, then the system will further determine whether the document is an internal draft (42) . If the document is an internal draft, then question 6 will be asked (46) . If the document is not an internal draft, then question 5 will be asked (47) . If the user, however, belongs to the same access sub-group as the document author, then the system will further ask whether the user has new version publication rights (48) . If the user does not have new version publication rights, then the system will ask whether the document is an internal draft (42) . If the document is an internal draft then question 4 will be asked (49) . If the document is not an internal draft, then question 3 will be asked (50) . If the user has new version publication rights, then the system will ask whether the document is an internal draft (51) . If the document is an internal draft, then question 2 will be asked (52) . If the document is not an internal draft then question 1 will be asked (53) .

Returning to step 40, if the document has not been checked out by the user making the request, then the system will check whether the document is an internal or private draft (54) . If the document is a private draft, then access to the document is denied, and the system will display a message to notify the name of the user who has checked out the document (55) . If, however the document is an internal draft, then the system will ask whether the user is in the same access sub-group as the user who uploaded the internal draft (56) . If the user is not in the same access group, then access will be denied, and the system will inform the user that the document is under internal review (57) . If the user is part of the same access sub-group, then access is denied to the document, but the system will alert the user as to the identity of the other user in that sub-group who has checked out the document . In the preceding paragraphs, reference has been made to "questions" that may be asked by the document management and multi party collaboration system. For example, there is a reference to a "question 1" being asked, "question 2" being asked, etc. These questions are multiple choice questions asked of the user at the time of upload of a document version and relate to the checking in of a document. The answer to the question given by the user attributes a pre-determined version type to the document. In questions 1 to 8, the same question is asked of the user, namely "upload this file as?" . The questions differ not in the question asked of the user, which is the same in each case, but in the responses available to the user.

There are six possible options which the user may choose from, and it will be understood that the user may not always be able to choose from all six options. The options are: 1. Internal draft

2. Update of internal draft

3. New private review draft

4. New public review draft 5. New public version

6. No amendments

Question 1 (53) is a combination of the above mentioned options, 1, 3 and 5. Question 2 (52) is a combination of 1, 2, 3 and 5. Question 3 (50) is a combination of 1 and 3. Question 4 (49) is a combination of 1, 2 and 3. Question 5 (47) is a combination of 1, 3, 4 and 6. Question 6 (46) is a combination of 1, 2, 3 and 4. Question 7 (44) is a combination of 1 and 3. Question 8 (43) is a combination of 1, 2 and 3. Therefore, for example, if the user were to terminate at step 53, then question 1 would be asked. The user would be presented with an option to upload the file as either, 1 - a new internal draft, 3 - a new private review draft, or 5 - a new public version. In another example, if the user were to terminate at step 44, question 7 would be asked, namely "upload file as?" with the user being presented with the options of 1 - new internal draft or 3 - new private review draft .

It will also be noted that in the present embodiment, question 5 also has a follow up question regarding the length of time to wait before "comments are due" .

It will be understood that the preceding decision tree merely describes one embodiment of the invention, and moreover, that numerous variations to the decision tree, to the outcomes, and to the questions asked of the user are within the scope of the invention.

The components of the document management and multi party collaboration system will now be described in more detail. The first component is the access group. Each user is a member of a pre defined access group.

Each access group is divisible into sub-groups one of which may be termed the "primary group" (in the legal environment these may be law firms) and the other/s of which are subordinate groups (which could be one or more clients and/or other groups such as accountants, consultants and external advisors) . The second component of the document management system is the permission level structure.

There is a range of document permission levels that may be assigned, either to all members of a primary or subordinate group or to an individual member of a group. The permission levels determine whether a user may read documents only or may also amend them and, if so, the document version types which a user can upload as well as whether the user can upload new documents to the Transaction. The permission levels in an embodiment of the present invention are:

• Level 1 - Read only

• Level 2 - Read and write internal and private drafts

• Level 3 - Read and write internal, private and public drafts/versions • Level 4 - Read and write internal, private and public drafts/versions and publish new documents

The range of permission levels available to a user may depend upon and be further defined by the user' s status (i.e. the access sub-group of which the user is a member) .

For example, in one embodiment, only the document author or members of the author' s primary group with Level 4 or 5 permission would be permitted to upload a new version of a document. In that embodiment other users with Level 4 or 5 permission would only be entitled to upload a public review draft of the document at most.

The third component of the document management and multi party collaboration system is the document version type. The initial and each subsequent version of a document is given a unique identifier and may have a defined version type (which gives the document predefined attributes) and a document state. In an embodiment of the invention the following are the available version types of a document version:

•Internal draft - available only to users in the same access sub-group and can be later modified •Private draft - available only to users in the same access group and cannot be later modified

•Public draft - available to all access groups and cannot be later modified; •Public version - available to all access groups and cannot be later modified. The version type given to a document version applies attributes which regulate which users can access the version and whether or not the version can be later modified.

In an embodiment of the invention the document states are "current" for the latest public version of the document, "old" for prior public versions of the document, and for all other document types, either "checked in" or "checked out" .

"Checked out" applies where a user has downloaded a copy of the document and has not uploaded it as an overwrite of that version (which is available in the case of an internal draft) or as a new version. Otherwise the document status is "checked in" .

The "current" public version of a document is neither "checked in" nor "checked out" because in one embodiment it is available to all users with Level 2 permission or greater.

In another embodiment it is available to one user with Level 2 permission or greater from each access group to copy out and modify.

In an embodiment of the invention there is a further document state, namely "no amendment", which applies to a public review draft which makes no modification to the current public version.

Public versions with "old" status can only be copied out as "read only" copies. Available actions on a document version are a function of:

• The document version type and state

In an embodiment of the invention the available documents version types and states are: 1. Public version current 2. Public version old

3. Public review draft checked out

4. Public review draft checked in

5. Public review draft no amendment

6. Internal draft checked out 7. Internal draft checked in

8. Private draft checked out

9. Private draft checked in

• The user's permission level, and

• The user' s access sub-group Each combination of a variable from each of the aforementioned 3 components gives a range of predetermined outcomes that are:

• Whether the user has access to that document version

• If so, whether that document version is available and, if so, for what purpose; and

• If uploading a copy of the document version previously downloaded and modified by the user is available to the user, the combination of the three variables will indicate a range of available version types for the modified document copy when uploaded.

The user selects one of those version types and the modified document copy is uploaded as that version type.

The system provides further advantages . Documents which are related or connected to each other can be grouped together. In an embodiment of the invention related documents are grouped in a "Transaction" .

Primary and subordinate access sub-groups, permission levels and document version types can be the same or different for each document in a document group. In an embodiment of the invention:

• All documents in a Transaction have the same access groups and sub-groups and each user has the same permission levels for each document • The same document version types are available for all documents in a Transaction and all Transactions. Additionally, when participants have completed their collaboration on a document or a group of documents, on a user initiated command the system creates a series of folders for all or each of a number of predetermined access sub-groups. Copies of document versions and discussion forum posts to which the members of each such access sub-group has access and copies of messages to, from or copied to any member of that access sub-group are placed in those folders which are then placed in a principal folder which can be downloaded to one or more members of the defined access sub-group upon command.

The copies of the document versions which are placed in the document folder for a defined access sub-group is a function of the permission levels for the members of the access sub-group and the document version types and the access group or sub-group of the user who uploaded each version.

The copies of discussion forum posts which are placed in the discussion forum folder for a particular access sub-group is a function of the permission levels for the members of the relevant access sub-group and discussion forum types (ie in an embodiment of the invention, public or private) . Copies of all messages which are sent to or from a member of the sub-group or which are copied to a member are placed in the messages folder. All folders are then placed in a primary folder that can be downloaded to a member of the sub-group on command. Additionally, computer software which is available to be installed on a user's remote computer system or terminal ("client"), will provide three folders on the client, namely:

•Copied out documents •Checked in documents •Checked out documents Documents which are copied out to the user (i.e. copies of documents to which the user has read only access or to which the user has a greater permission level but where the document is checked out by another user) , upon download are placed in the copied out folder as read only documents.

Documents which are checked out by the user (i.e. copies of documents which can be modified by the user) are placed in the checked out folder.

When a checked out document is checked in (i.e. uploaded to the server) by the user it is moved from the checked out folder and a read only copy placed in the checked in folder.

Additionally, while a client is connected to the server, if the user gives the command to the server to open a document which the user has previously checked out and not checked in or has previously copied out, the system first searches the client to identify whether the document is in the appropriate copied out or checked out folder on the client and if so, opens the document from that place rather than downloading it. This is able to occur because each document version is given a unique identifier and is downloaded with that identifier.

Modifications and variations as would be apparent to a skilled addressee are deemed to be within the scope of the present invention.

Claims

1. A method for managing electronic document (s) comprising the steps of, enabling one or more users from within each one of a plurality of discrete access groups to connect to a server via a network, enabling said one or more users in said discrete access groups to modify and communicate a document within one or more of the access groups, wherein the ability of the users of said access groups to access the document is determined by a permission level allocated to said users.

2. An method in accordance with claim 1, wherein a user may create an access sub-group, being the same or a smaller number of users within the discrete access group, and modify and communicate a document privately within the discrete access group and/or sub-group (s) , or publicly with other discrete access group (s) and/or sub-group (s) .

3. A method in accordance with claim 1 or 2 , wherein access to a document (s) within a group (s) and/or a subgroup (s) is further determined by the document version type and the group or sub-group of which the communicating user is a member.

4. A method in accordance with claim 1, 2 or 3, wherein a sub-set of group (s) and/or sub-group (s) may be grouped together to form a transaction group.

5. A method in accordance with claim 1, 2, 3 or 4 , wherein there is provided the further step of encrypting the document (s) and information prior to communication and on the server.

6. A method in accordance with any one of the above- referenced claims, wherein there is provided a discussion forum for each document associated with each of the group (s), sub-group (s) and/or transaction group (s).

7. A method in accordance with claim 6, wherein a user may create a discussion forum within a transaction group(s), group(s) and/or sub-group (s) .

8. A method in accordance with claim 7, wherein the ability to access information within the discussion forum is determined by a permission level set by a user.

9. A method in accordance with any one of the above referenced claims, wherein there is provided a messaging system such that one user may privately send a message to another user.

10. A method in accordance with any one of the above referenced claims, wherein there is provided an archiving function arranged to permit each relevant group (s) and/or sub-group (s) within a transaction group to archive copies of all document versions, discussion forums and messages to which members or any member of the relevant group or sub-group has access.

11. A method in accordance with any one of the above- referenced claims, wherein there is provided the further step of compressing a document prior to upload to the document management and multi party collaboration system.

12. A method in accordance with any one of the above- referenced claims, wherein there is provided the further step of uncompressing a document after it is downloaded to a user terminal .

13. A method for managing electronic document (s) comprising the steps of, enabling a user from within a discrete access group, that is comprised of one or more users, to connect to a server via a network, enabling the user to access on the server document (s) of the discrete access group, wherein more than one user of a discrete access group may simultaneously download a copy of the document from the server and/or upload a modified or unmodified copy of the document to the server.

14. An apparatus for managing electronic documents comprising, an enabling means arranged to allow one or moreusers from within each one of a plurality of discrete access groups, to connect to a file server via a network, a modifying means arranged to allow said one or more users in discrete access groups to modify and communicate a document within one or more of the access groups, whereby the ability of the users of said access groups is determined by a permission flag allocated to said users.