U.S. patent application number 10/441941 was filed with the patent office on 2004-02-05 for method and system for role-based access control to a collaborative online legal workflow tool.
Invention is credited to Dinsdale, David, Porcari, Damian O..
Application Number | 20040025048 10/441941 |
Document ID | / |
Family ID | 31191076 |
Filed Date | 2004-02-05 |
United States Patent
Application |
20040025048 |
Kind Code |
A1 |
Porcari, Damian O. ; et
al. |
February 5, 2004 |
Method and system for role-based access control to a collaborative
online legal workflow tool
Abstract
A computer system and method for distributed legal workflow
security provides role-based access control to a collaborative
online workflow tool. The system includes a computer network having
one or more computers operably programmed and configured to receive
input defining computer system access privileges for a plurality of
distributed legal workflow participants. The system receives input
associating one or more legal workflow role types defined by users
with one or more of the distributed legal workflow participants to
define the role-based access. Permission privileges are input and
associated with a plurality of legal workflow graphical interface
functions based on the one or more legal workflow role types. Based
on the permission privileges associated with the role type of the
participant, the system provides legal workflow graphical interface
functionality to the one or more distributed legal workflow
participants.
Inventors: |
Porcari, Damian O.;
(Farmington Hills, MI) ; Dinsdale, David; (London,
GB) |
Correspondence
Address: |
BROOKS KUSHMAN P.C./FGTL
1000 TOWN CENTER
22ND FLOOR
SOUTHFIELD
MI
48075-1238
US
|
Family ID: |
31191076 |
Appl. No.: |
10/441941 |
Filed: |
May 20, 2003 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60381841 |
May 20, 2002 |
|
|
|
Current U.S.
Class: |
726/1 ; 705/310;
705/311 |
Current CPC
Class: |
G06Q 50/184 20130101;
G06Q 50/18 20130101; G06Q 10/10 20130101 |
Class at
Publication: |
713/200 ;
705/8 |
International
Class: |
G06F 017/60 |
Claims
What is claimed:
1. A computer system for distributed legal workflow security, the
computer system providing central administration of legal workflow
conducted by a plurality of distributed workflow participants, the
system comprising a computer network including one or more
computers operably programmed and configured to: (i) receive input
defining computer system access privileges for a plurality of
distributed legal workflow participants; (ii) receive input
associating one or more legal workflow role types with one or more
of the distributed legal workflow participants; (iii) receive input
associating permission privileges for a plurality of legal workflow
graphical interface functionality with one or more of the legal
workflow role types; and (iv) provide legal workflow graphical
interface functionality to the one or more distributed legal
workflow participants according to the permission privileges
associated with the participants respective legal workflow role
types.
2. The system of claim 1 wherein the legal workflow includes
intellectual property legal workflow.
3. The system of claim 2 wherein the intellectual property legal
workflow includes patent legal workflow.
4. The system of claim 2 wherein the intellectual property legal
workflow includes trademark legal workflow.
5. The system of claim 2 wherein the intellectual property legal
workflow includes conflict legal workflow.
6. The system of claim 2 wherein the intellectual property legal
workflow includes agreement legal workflow.
7. The system of claim 2 wherein the intellectual property legal
workflow includes legal financial workflow.
8. The computer system of claim 1 wherein the permission privileges
are selected from a group consisting of active, inactive, hidden,
greyed, edit, no edit, add, delete and grant.
9. The computer system of claim 1 wherein the graphical interface
functionality is selected from a group consisting of text,
graphics, hyperlinks, form fields, buttons, drop-down lists,
tables, menu items and page sections.
10. The computer system of claim 1 wherein the distributed legal
workflow participants are selected from a group consisting of
attorneys, support staff, customers, customer clients, internal
employees and suppliers.
11. The computer system of claim 1 wherein the one or more
computers are additionally programmed and configured to filter data
records according to legal workflow role type.
12. The computer system of claim 1 wherein the one or more
computers are additionally programmed and configured to filter data
records according to distributed legal workflow participant.
13. The computer system of claim 1 wherein the permission
privileges are associated based on a geographical location of the
distributed legal workflow participants.
14. A method for providing legal workflow security conducted by a
plurality of distributed workflow participants, the method
comprising: receiving input defining computer system access
privileges for a plurality of distributed legal workflow
participants; receiving input associating one or more legal
workflow role types with one or more of the distributed legal
workflow participants; receiving input associating permission
privileges for a plurality of legal workflow graphical interface
functionality with one or more of the legal workflow role types;
and providing legal workflow graphical interface functionality to
the one or more distributed legal workflow participants according
to the permission privileges associated with the participants
respective legal workflow role types.
15. The method of claim 14 further comprising providing a computer
network including one or more computers operably programmed and
configured to input user access commands.
16. The method of claim 15 further comprising the step of filtering
data records with the one or more computers according to legal work
role type.
17. The method of claim 15 further comprising the step of filtering
data records with the one or more computers according to
distributed legal workflow participant.
18. The method of claim 15 further comprising the step of filtering
data records with the one or more computers according based on a
geographical location of the distributed legal workflow
participants.
19. The method of claim 14 wherein the step of providing legal
workflow graphical interface functionality comprises interfaces for
intellectual property legal workflow.
20. The method of claim 14 wherein the step of receiving permission
privileges further comprises inputting permission privileges
selected from a group consisting of active, inactive, hidden,
greyed, edit, no edit, add, delete and grant.
21. The method of claim 14 wherein the step of providing graphical
interface functionality further comprises generating functionality
selected from a group consisting of text, graphics, hyperlinks,
form fields, buttons, drop-down lists, tables, menu items and page
sections.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. provisional
application Serial No. 60/381,841 filed May 20, 2002.
BACKGROUND OF THE INVENTION
[0002] 1. Field of the Invention
[0003] This invention relates to a collaborative online legal
workflow tool and more particularly, to a method and system for
role-based access control to a collaborative online legal workflow
tool.
[0004] 2. Background Art
[0005] A variety of legal workflow tools are currently available in
the marketplace which allow users to manage an intellectual
property portfolio. Typical information managed by these systems
include filing and prosecution information for patent and trademark
applications filed around the world. Many of these systems are
based upon well known client-server architecture and provide
limited ability for internal users to collaborate with external
service providers without complex hardware and networking
architecture.
[0006] Recently, developers have modified existing client-server
systems to incorporate online collaborative tools, such as web
access plugins, to allow a variety of users in various locations to
access common information stored in the tool. One of the challenges
associated with this collaborative exchange of information is the
level of access and control users have to the information stored in
the tool.
[0007] In today's legal arena, corporations, institutions and firm
clients typically rely on multiple distributed firms and agencies
to assist with or independently conduct their legal workflow. It is
not uncommon for a single corporation to have several private law
firms handling hundreds of co-pending legal matters ranging from
basic transactional work to larger projects such as litigation,
negotiation, etc. In the intellectual property area, for example, a
corporation often relies on outside counsel to independently manage
all searches and applications for trademarks, patents etc.
[0008] For example, a corporate attorney may provide access to one
or more external service providers to records stored in the
corporate workflow tool for which the external service provider is
responsible for managing on a day to day basis. Current portfolio
management solutions have security tools which restrict the
external service provider's access only to records assigned to the
external service provider. The external service provider is unable
to access information entered by other service providers which may
be related to the matters handled by that individual. This
inability to collaborate with other service providers limits the
level of service provided to the client and may create additional
support burdens for both the corporation and the service
provider.
[0009] A variety of companies currently offer software applications
for managing or otherwise automating workflow in both the legal and
non-legal arenas. One example is Aspen Grove's ipWorkflow. Aspen
Grove is located at 101 Federal Street, Suite 1900, Boston, Mass.
02110 (www.aspengrove.net). Another example is offered by Vinsoft
Solutions located at 1155 West Chestnut Street, Suite 2-C, Union,
N.J. 07083 (www.vinsoftsolutions.com). Another example is offered
by FoundationIP located at 830 TCF Tower, 121 South 8th Street,
Minneapolis, Minn. 55402 (www.foundationip.com). Another example is
Inproma offered by Computer Patent Annuities North America LLC
located at 225 Reinekers Lane, Suite 400, Alexandria, Va. 22314
(www.cpajersey.com). Another example is offered by iManage located
at 950 Tower Lane, Suite 500, Foster City, Calif. 94404
(www.imanage.com).
[0010] Embodiments and features of the present invention include an
alternative to or valuable improvement upon conventional legal
workflow applications. Without limiting the scope or applicability
of the present invention, one goal of the present invention is to
provide a collaborative online legal workflow tool which overcomes
the limitations described above. It would also be advantageous to
provide a method and system for role-based access control to
information in the collaborative online legal workflow tool which
provides central administration of legal workflow conducted by a
plurality of distributed workflow participants.
SUMMARY OF THE INVENTION
[0011] Accordingly, a computer system and method for distributed
legal workflow security is disclosed allowing role-based access
control to a collaborative online workflow tool. The computer
system provides central administration of legal workflow conducted
by a plurality of distributed workflow participants. The system
includes a computer network having one or more computers operably
programmed and configured to receive input defining computer system
access privileges for a plurality of distributed legal workflow
participants.
[0012] The system receives input associating one or more legal
workflow role types defined by users with one or more of the
distributed legal workflow participants to define the role-based
access. Permission privileges are input and associated with a
plurality of legal workflow graphical interface functions based on
the one or more legal workflow role types. Based on the permission
privileges associated with the role type of the participant, the
system provides legal workflow graphical interface functionality to
the one or more distributed legal workflow participants.
[0013] Advantages of the present invention include a reduction in
the time, cost and risk associated with conventional
distributed/remote management of legal workflow. Via the online
collaboration tool, integrated parties cooperate with real-time
knowledge access and visibility to work product and status. By
applying business/legal logic to this integrated pool of knowledge,
a value-added workflow results.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] FIGS. 1 and 2 illustrate online legal workflow collaboration
between organizations (e.g., brand owners, law firms, law firm
clients, brand owner clients, etc.), business processes and
information systems in accordance with one embodiment or aspect of
the present invention;
[0015] FIG. 3 is a flowchart illustrating a workflow for adding a
new user to the system;
[0016] FIG. 4 is an example of a graphical user interface for
adding a new user to the system;
[0017] FIG. 5 is a flowchart illustrating a workflow for
maintaining user workflow;
[0018] FIG. 6 is an example of a graphical user interface for a
user search;
[0019] FIG. 7 is an example of a graphical user interface for
displaying user search criteria;
[0020] FIG. 8 is an example of a graphical user interface for
amending user details;
[0021] FIG. 9 is an example of a graphical user interface for
granting roles to users;
[0022] FIG. 10 is a flowchart illustrating a workflow for defining
user preferences;
[0023] FIG. 11 is an example of a graphical user interface
displaying user preferences;
[0024] FIG. 12 is a flowchart illustrating a workflow for user
login procedures;
[0025] FIG. 13 is an example of a graphical user interface for user
login;
[0026] FIG. 14 is an example of a graphical user interface for
displaying terms and conditions of user login;
[0027] FIG. 15 is an example of a graphical user interface for
changing password features for user login;
[0028] FIG. 16 is a flowchart illustrating a workflow for role
maintenance;
[0029] FIG. 17 is an example of a graphical user interface for
selecting a user role to maintain;
[0030] FIG. 18 is an example of a graphical user interface for
defining attributes of the user interface;
[0031] FIG. 19 is a block diagram illustrating a preferred entity
relationship diagram setting forth user roles and access
rights;
[0032] FIG. 20 is an example of a graphical user interface for
maintaining legal workflow details;
[0033] FIG. 21 is an example of a graphical user interface for
trademark application legal workflow details;
[0034] FIG. 22 is an example of a graphical user interface for
conflict legal workflow details;
[0035] FIG. 23 is an example of a graphical user interface for
defining organizational details; and
[0036] FIG. 24 is an example of a graphical user interface for
defining contact information.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S)
System Overview
[0037] Embodiments of the present invention relate to an online
legal workflow collaboration tool and methodology. In today's legal
arena, corporations, institutions and firm clients typically rely
on multiple distributed firms and agencies to assist with or
independently conduct their legal workflow. It is not uncommon for
a single corporation to have several private law firms handling
hundreds of co-pending legal matters ranging from basic
transactional work to larger projects such as litigation,
negotiation, etc. In the intellectual property area, for example, a
corporation often relies on outside counsel to independently manage
all searches and applications for trademarks, patents etc.
[0038] Advantages of such an online legal workflow collaboration
tool and methodology include a reduction in the time, cost and risk
associated with conventional distributed/remote management of legal
workflow. Via the online collaboration tool, integrated parties
cooperate with real-time knowledge access and visibility to work
product and status. A law engine implements or otherwise applies
business/legal logic to this integrated pool of knowledge to
produce a value-added workflow.
[0039] FIG. 1 illustrates an overview of environment 10 in which
embodiments of the present invention may operate. A central online
leal workflow and knowledge management system 12 operably
interfaces or is otherwise in operable communication with a
plurality of local or distributed workflow participants (e.g.,
brand owners 14, agents/law firms 16, law firm clients 18, brand
owner clients 20, etc.). More specifically, and as illustrated in
greater detail in FIG. 2, workflow participants (e.g. agent/law
firm 22, legal department 24, etc.) and associated workflow
applications (e.g. document management system 26, finance system
28, etc.) productively collaborate with one another via central
online leal workflow and knowledge management system 12. Notably,
an unlimited number of participants may collaborate with one
another in an unlimited number of different fashions.
[0040] One aspect of the present invention is a system and
methodology for controlling user access to the online legal
workflow collaboration tool, or portions thereof. The system
comprises a computer network including one or more computers
operably programmed and configured to allow access to the
collaborative online workflow tool. This aspect is easy to manage
and a flexible user permissioning model that relies on the
definition of generic roles for multiple users.
[0041] As evidenced by the variety and breadth of existing computer
architectures hosting or otherwise supporting knowledge and
management workflow applications, those of ordinary skill in the
art recognize that such applications may be implemented on or over
a multitude of different computing platforms and networks.
According to one embodiment, functional aspects of the present
invention may be centrally hosted from one or more web servers to
web browsers located at a plurality of local or distributed
workflow participant locations. Alternately, aspects of the present
invention may be implemented according to a more
dedicated/localized client-server architecture over a local or wide
area network.
[0042] Example role types include a Customer User, an External
Counsel (or agent) User, a Customer Client User, a Customer Client
User with an anonymous log in, and an Inventor with an anonymous
log in. In one embodiment, a Customer is a company who is using the
system to store and manage their IP data. Preferably, where a
Customer has subcontracted part of their service provision to an
agent, the agent's users will still be Customer Users as they are
essentially fulfilling the role of a Customer User.
[0043] In addition to a user ID/password, access to the system may
be restricted at levels such as Menu level (e.g. create
trademark--main screen, create trademark--based on etc.), and
section of a page level (e.g. proprietor details on trademark not
visible to External Counsel). While section of a page may be
regarded at it's largest as a whole page, at it's smallest as a
single data field or button, or somewhere between. The business
users define the permissionable sections for each page.
[0044] A pragmatic approach may be taken as to whether it is best
to create a complex permissioning scenario for a particular screen,
or just create two or more screens. For example, for Trademarks, it
may be simple to develop separate Trademark pages for Customer
Users and External Counsel Users, than to create a complex
permissioning model for a simple page.
[0045] External Counsel Users and Customer Client Users have the
ability to see only the records for which their company has
responsibility. A protocol may be followed that allows a user to
view (read only) the diary of any other user from the same External
Counsel organization and they may re-allocate tasks to other users
in their organization.
Security Principles
[0046] The present invention assumes that people will attempt to
hack the computer system or access areas outside their granted
level of permission. To prevent this, security principles may be
applied. For example, content for which a user is not permissioned
may not be returned to the user from the server.
[0047] In another example, all permissionable actions (menus,
pages, buttons, hyperlinks, etc.) will check (server side) before
executing business logic that the user has permission to execute
the action. This functionality will prevent hackers from guessing
action calls, etc. Where appropriate, if the system detects any
possible security issue, an e-mail may be sent to a system
administrator. The activity may also be logged for further
investigation.
User Trust Requirements
[0048] User Trust Requirements relate to the business process
necessary to ensure that the person who is being added to the
system has been verified as a valid user of the system for the
permissions granted to them. The general principle is that a user
with the appropriate permissions may create other users of their
own user type (e.g., Customer User, External Counsel User or
Customer Client User, etc.).
[0049] External Counsel may have the ability to create and maintain
their own users. In one embodiment, they will not have the ability
to modify the definitions of the roles for which they are
permissioned. A Creating User is defined as a user who is logged in
and who is creating a new user.
User Types
[0050] In accordance with a preferred embodiment of the present
invention different access rights are provided for different types
of users. Table 1 contains example user types in accordance with
the present invention. It is envisioned that an unlimited number of
user types may be defined.
1 TABLE 1 User Type 1 Customer User User Type 2 External Counsel
(or agent) User User Type 3 Customer Client User User Type 4
Customer Client User - self-created log in User Type 5 Inventor -
self-created log in
[0051] The Customer User will generally be an employee. Examples
include a Counsel/Attorney/Paralegal or other administrative staff.
Some companies may have outsourced aspects of the management of
their IP or other legal work to External Counsel; hence it is
possible that a Customer User is from an External Counsel.
[0052] External Counsel are those companies instructed to do
something by the Customer User in relation to the registration,
renewal, maintenance, etc. of one or more of the Customer's
records. As a general principle, External Counsel should only be
able to access records that are allocated to the company to whom
the user belongs.
[0053] The Customer Client User represents the client of the
Customer. This could be an employee of an operating company.
Customer Client Users are generally interested in a subset of
records that relate to their company only.
[0054] Prior to display, each page checks that the user has the
necessary authority to access the main record being displayed. If
the record belongs to the Customer Client to whom the user also
belongs, the record should be displayed. The Client field on the
main record identifies the Customer Client User.
Permission Based on Model
[0055] Once an agent or client has been added to a particular
record, a permission database is updated to reflect this
automatically. Preferably, a user can add and remove rights to any
particular record.
Menu Permissions
[0056] In a preferred embodiment of the present invention, a common
menu is provided on each screen. The content of this menu will be
specific to a role profile. Main Menu items not permissioned for a
particular role are preferably de-activated, hidden, or greyed out.
The Add Users and Maintain Roles permissions are maintained at the
user level (on the user table).
[0057] Even if a role allocated to a user has been permissioned to
add new users/maintain roles, the user setting will override this
setting if there is a conflict. I.e., if the role allows access to
the Add User capability, but the user account is flagged with the
setting `Add New User`=No, the user will be prevented from
accessing this capability.
[0058] By default, if there is not a specific grant of permission
for a menu item against a role, the permission to access that menu
item is assumed to be no. A check on each page will also check if
the user's ,account suspended flag is set to yes. If they are, the
user should be shown the account suspended page and logged off the
system. Suspended accounts will not be allowed to log onto the
system.
Sections of a Web Page Permissions
[0059] Preferably, each web page sections. These sections may
contain one or more data fields and/or buttons etc. The sections
for a particular screen are defined in the Workflow Specification
for that screen. As each page is processed, the permissions for
each section are applied.
[0060] Table 2 contains example permissions in accordance with one
embodiment of the present invention.
2TABLE 2 No View/Execute No View applies to data (text boxes/list
boxes, etc.) and sections. No Execute applies to buttons, links,
etc. These two permissions have been grouped together as they are
effectively the same, i.e., if a No View/Execute permission applies
to a section of a web page, then the content of that section shall
not be returned to the client at all Where the section includes
executable items (buttons, links, etc.) the system must ensure at
the server that these items are not executable (e.g., where a
hacker guesses an action from a button on a page). No Update
Applies to data. If the permission `No Update` is flagged for a
particular section, the data must not be allowed to be updated by
the system. The system must both disable the user's ability to
change the data on the page, and protect from a hacker calling a
HTTP get/post action with modified data. No Restrictions The
section of the page is fully permissioned. Add The ability to add a
record is controlled at either the menu level (2.1.1 above), page
level (2.1.2 above) or, if there is an add button on a page, via a
No Execute permission on the button. Delete The ability to delete a
record is controlled at page level (2.1.2 above) or via a No
Execute permission on the Delete button on pages. Grant The ability
to grant permissions is controlled by the User Trust Architecture -
see below.
[0061] Permissions may be applied in an optimistic way. E.g., the
user is allowed the maximum possible access (all permissions
granted) unless a permission exists to restrict access.
Vertical Data Filtering
[0062] To prevent users from seeing data that they are not
authorized/required to see, the present invention may filter data
for difference user categories such as those contained in Table
3.
3 TABLE 3 Type of user Filter required Customer User None External
Counsel The ability to see only records allocated to (or agent
User) that external counsel. Customer Client The ability to see
only records where the User Customer Client is the proprietor.
[0063] Additional user types may be added to the system requiring
some kind of vertical data filtering (e.g., inventors, patent
committee members, etc.).
Vertical Data Filtering--External Counsel (or Agent) User
[0064] Prior to display, each page may check that the user has the
necessary authority to access the main IP record being displayed.
If the record belongs to the External Counsel to whom the user also
belongs, the record should be displayed. If the record does not
belong to External Counsel to whom the user belongs, the user will
be directed to an error page.
[0065] In some circumstances, an External Counsel may access to
other records related to their own (e.g., based on, basis for,
priority, etc.). External Counsel may subcontract a piece of work
to another External Counsel.
Vertical Data Filtering--Customer Client User
[0066] Prior to display, each page may check that the user has the
necessary authority to access the main IP record being displayed.
If record belongs to the Customer Client to whom the user also
belongs, the record should be displayed. If the record does not
belong to the Customer Client to whom the user belongs, the user
will be directed to an error page. Certain users may update certain
records in a particular territory.
How Changes to Permissions and Roles are Implemented
[0067] Changes to the definition of a role may actioned the next
time a user logs in (for permissions held at server or session
level) or the next time a user tries to access a capability (for
permissions that are dynamically derived from the database).
[0068] FIG. 3 is a preferred workflow diagram for adding a new
user. At step 40, information about the new user is entered into
the user create screen illustrated as FIG. 4. A prerequisite to
this process may require that the creating user AND creating user's
role have been flagged as having the ability to add new users.
Preferably, any role may be allocated to the new user with the
exception that only System Technical Support users may add other
System Technical Support users.
[0069] FIG. 4 is an example user interface for adding a new user.
The graphical user interface is generally illustrated as reference
numeral 42. Table 4 defines example attributes for the different
aspects of the user interface illustrated in FIG. 4.
4TABLE 4 Label Table/Field Mandatory Type Details and validation
All fields are from the User table unless otherwise specified
Salutation Salutation Optional Text First Name FirstName Mandatory
Text Surname Surname Mandatory Text Job Title JobTitle Mandatory
Text Tel No TelephoneNo Mandatory Text Fax No FaxNo Optional Text
Mobile Tel No MobileNo Optional Text Role Profile UserRoleID
Mandatory Dropdown Default is creating users role profile Dropdown
list from role profile table defaulting to creating users role
profile. If the user is an External Counsel User, they should only
see roles flagged as available to External Counsel. User Class
UserClassID Mandatory Dropdown No Default. Dropdown list from User
Class table ((Mandatory) (Attorney, Inventor, Searcher, etc.). This
field is used to help searching. Welcome Message None Optional Text
A message to the user that will be sent in the welcome e-mail. If
the creating user has role System Technical Support, the following
fields may be displayed: User Type UserTypeID Mandatory Dropdown
Defaults to Customer User'. Pick list of Customer User', `External
Counsel User`, `Customer Client User` Organization OrganisationID
Mandatory Picklist No default. If User Type = `External Counsel`,
the creating user is required to enter the External Counsel Company
from a pick list If User Type = `Customer Client`, the creating
user is required to enter the Customer Client Company from a pick
list If the user being created is a Customer User Users
DepartmentID Optional Dropdown No default. Department/Team Only for
Customer Users.
[0070] In one embodiment of the present invention, the "Create
User" button creates the user according to the following
process:
[0071] Action 1--Validate that the e-mail is not already in use. If
it is, the Add New Users page is re-displayed (data preserved) with
an error message.
[0072] Action 2--Generate an initial password for the user.
[0073] Action 3--Create the user on the system with the allocated
role profile and password.
[0074] If the creating user has role System Technical Support, the
new user will have user type as defined by the User Type field,
with the Organization being set to the organization entered from
the Organization pock list.
[0075] If the creating user is a Customer User, the new user will
also be a Customer User and belong to the Customer
organization.
[0076] If the creating user is an External Counsel, the new user
will be an External Counsel User and belong to the same External
Counsel organization as the creating user.
[0077] If the creating user is a Customer Client, the new user will
be a Customer Client User and belong to the same Customer Client
organization as the creating user.
[0078] Example default values for user fields are listed in Table
5.
5TABLE 5 Details Label Table/Field Mandatory Type and validation
None LockedOut Mandatory Default set to No None BadPWDAttempts
Mandatory Default set to 0 None T&CVersionSigned Mandatory
Default set to 0 None T&CNameTyped Mandatory Default set to
null None ChangePWDNextLogin Mandatory Default set to Yes None
LastLoginDate Mandatory Default set to null None UserCanAddUsers
Mandatory Default set to No None UserCanAddRoles Mandatory Default
set to No
[0079] Action 4--e-mail--E-mail to the user with the e-mail text
set forth below in Table 6.
6TABLE 6 E-mail Specification WSD011-001 To: New User E-mail From:
<Helpdesk e-mail> Cc: None Bcc: None Title: Welcome to the
<Customer Name> System Details: I am pleased to notify you of
your login details for the <Customer Name> System Password:
<Password> You can access the system at the following URL
<System URL> <Message to the user> Attachments:
None
[0080] At step 44, the create user process is completed and the
user returned to the user home page.
[0081] FIG. 5 is a preferred workflow diagram for maintaining user
workflow. In order to access the user maintain user workflow, the
user should be flagged as having permission to the maintain users
menu item. On accessing this menu item the user accesses a search
page to find the users. At step 46, a system user enters criteria
into a search screen to locate a user to maintain. FIG. 6 is an
example user interface 48 for a user search.
[0082] Preferably, criteria entered in more than one field are
combined with a logical and. Wild cards are allowed. Names may be
wild carded without the user knowing. External Counsel users may
only find user details of that External Counsel's users. Customer
Client users may only find details of that Customer Client's
users.
[0083] The data of the original search should be preserved for the
convenience of the user. If the user records are found at step 50,
they should be displayed as a list below the search criteria and
buttons, as illustrated generally by reference number 52, in FIG.
7.
[0084] FIG. 8 is an example user interface 56 for amending user
details. In one embodiment of the present invention, the system
will first check whether the user has any chasers allocated to
them. If they do, the system will not allow the deletion, returning
the user to the modify users page with an error message. Next at
step 54, the system will physically delete the user and all records
from the login history table. The list of roles that is presented
should be the list of roles that the currently logged in user is
authorized to grant.
[0085] Table 7 defines example attributes for aspects of the user
interface illustrated in FIG. 8.
7TABLE 7 Label Table/Field Mandatory Type Details and validation
All fields are from the User table unless otherwise specified
Salutation Salutation Optional Text First Name FirstName Mandatory
Text Surname Surname Mandatory Text Job Title JobTitle Mandatory
Text E-Mail address EmailAddress Mandatory Text Tel No TelephoneNo
Mandatory Text Fax No FaxNo Optional Text Mobile Tel No MobileNo
Optional Text Role Profile UserRoleID Mandatory Dropdown Default is
creating user's role profile Dropdown list from role profile table
defaulting to creating user's role profile. If the user is an
External Counsel User, they should only see roles flagged as
available to External Counsel. User Class UserClassID Mandatory
Dropdown No default. Dropdown list from User Class table
((Mandatory) (Attorney, Inventor, Searcher, etc.)). This field is
used to help searching. Suspend User SuspendUserDate Mandatory Date
Date User Is LockedOut Mandatory Dropdown Yes/No Suspended Failed
Login BadPWDAttempts Optional Read Only Attempts Change Password
ChangePWDNextLog Mandatory Dropdown Yes/No at next login on Show Ts
& Cs at NONE Mandatory Calculation If T&CversionSigned <
next login <current system terms and conditions> then Yes
else No T & C version T&CversionSigned Optional signed Name
Typed T&CnameTyped Optional Read only when T&Cs signed
Secret Question SecretQuestionID Mandatory Dropdown Dropdown from
SecretQuestion table Secret Question SecretQuestionAn Optional Text
Answer swer Last Login Date LastLoginDate Optional Read Only If the
modifying user has role System Technical Support, the following
fields will be displayed: User Type UserTypeID Mandatory Dropdown
Defaults to `Customer User`. Pick list of `Customer User`,
'External Counsel User`, `Customer Client User` Organization
OrganisationID Mandatory Picklist No default If User Type =
`External Counsel`, the creating user is required to enter the
External Counsel Company from a pick list If User Type = `Customer
Client`, the creating user is required to enter the Customer Client
Company from a pick list. If the user being created is a Customer
User Users DepartmentID Optional Dropdown No default. Department/
Only for Customer Team Users. If the modifying user can add new
users User can add UserCanAddUsers Mandatory Checkbox new users If
the modifying user can maintain roles Users can UserCanMaintainR
Mandatory Checkbox maintain roles oles
[0086] At step 58, the `Save` Button saves the changes and returns
the user to Step 2. The `Back` Button returns the user to step 2.
The `Cancel` Button cancels any changes and re-presents the user's
record. If the user chooses to `Delete` a user, a follow-up process
may be followed.
[0087] FIG. 9 is an example user interface 60 for granting roles to
another user. Table 8 defines example attributes for various
aspects of the user interface illustrated in FIG. 9.
8TABLE 8 Label Table/Field Mandatory Type Details and validation
Users e-mail User. Mandatory Text address EmailAddress All Fields
from UserRoleMayGrant table unless specified User Role UserRoleID
Mandatory Readonly User May Grant Optional Checkbox Derived from
the UserRoleMayGrant table. If a record exists for the User ID/
Role ID combination, then User May Grant is true. If a record does
not exist, then User May Grant is false.
[0088] FIG. 10 is a preferred workflow diagram for defining user
preferences, illustrated as 62. User preferences may include
business information, such as telephone number and email address,
as well as a secret question and answer, which are used to retrieve
secured information. FIG. 11 is an example user interface 64 for
defining user preferences. Table 9 defines example attributes for
aspects of the user interface illustrated in FIG. 11.
9TABLE 9 Label Table/Field Mandatory Type Details and validation
All fields are from the User table unless otherwise specified
Salutation Salutation Optional Text First Name FirstName Mandatory
Text Surname Surname Mandatory Text Job Title JobTitle Mandatory
Text Tel No TelephoneNo Mandatory Text Fax No FaxNo Optional Text
Mobile Tel No MobileNo Optional Text Role Profile UserRoleID
Mandatory Read only User Class UserClassID Mandatory Dropdown
Dropdown list from User Class table ((Mandatory) (Attorney,
Inventor, Searcher, etc.)). This field is used to help searching.
Secret Question SecretQuestionID Mandatory Dropdown Dropdown from
SecretQuestion table Secret Question SecretQuestionAnswer Mandatory
Text Answer Organization OrganisationID Mandatory Read only If the
user being created is an Anaqua Customer User Users DepartmentID
Optional Dropdown No default. Department/Team Only for Anagua
Customer Users
[0089] In one embodiment of the present invention, the `Save`
Button saves the changes and returns the user their home page. The
`Cancel` Button cancels any changes and returns the user to their
home page.
[0090] FIG. 12 is a preferred workflow diagram for user login. The
user login workflow comprises five primary steps. At step 66, the
user enters a user identification and password into fields on the
screen 68. FIG. 13 is an example user interface for Step 1 of user
login. In one preferred aspect of the invention, the user
identification is the user's email address. Table 10 defines
example attributes for aspects of the user interface illustrated in
FIG. 13.
10TABLE 10 Details Label Table/Field Mandatory Type and validation
All fields are from the User table unless otherwise specified
E-mail Address EmailAddress Mandatory Text Password Password
Mandatory Text Text entered should be displayed as *s
[0091] The `Sign On` Button proceeds the user to step 2. The
`Forgotten Password` Link redirects to a Forgotten Password
Page.
[0092] At number 70, the second step of the user login workflow is
user validation. The identification and password are checked
against stored user information in the workflow tool. If the user
identification (ID) exists and the password is incorrect, the
following actions will be taken.
[0093] Action 1--Increment the user's <failed login attempts>
counter by 1
[0094] Action 2--Error Page--The user is re-directed back to the
login page with an error message at the top of the pages.
[0095] If the user's new <failed login attempts> counter is
greater than the <system login attempts allowed> system
parameter, the user is redirected to a page with the following
text:
[0096] You have failed to correctly provide your user ID and
password several times, so your account has been suspended. Please
go to the forgotten password page to re-set your password.
[0097] The page may have two buttons;
[0098] Cancel--which returns the user to the www.domain.com
site.
[0099] Forgotten Password--takes the user to the Forgotten Password
page.
[0100] If the user ID is incorrect, the user is re-directed back to
the login page with an error message at the top of the page.
[0101] If the User ID and Password are validated, and the user's IP
address does not belong to the `blocked IP-address` table, then the
user's <failed login attempts> counter shall be set to 0, and
the user may progress to step 3.
[0102] At step 72, the user login workflow checks the terms and
conditions of the user's account. If the user's account has its
<terms and conditions signed> greater than or equal to the
<current system terms and conditions>, the user may progress
to step 4, referenced by numeral 76. If the user's account has its
<terms and conditions signed> less than the <current
system terms and conditions>, the user may be redirected or may
progress to step 4.
[0103] Preferably, a page is displayed requiring the user to read
the terms and conditions, and give notice of their acceptance. FIG.
14 illustrates an example user interface 74 for displaying terms
and conditions for a particular user account. According to one
embodiment of the invention, upon selecting the "I agree" button,
the system will do the following validations:
[0104] Validation 1--If the name typed does not match the first
name and surname of the account, the system will re-display the
terms and conditions page with an error message.
[0105] Validation 2--If the name typed matches the first name and
surname of the account, the system will
[0106] store the name typed in the <name typed at last terms and
conditions acceptance> attribute of the user accounts,
[0107] set to <terms and conditions signed> equal to the
<current system terms and conditions> for the user account,
and
[0108] allow the user to progress to Step 4.
[0109] The fourth step of the user login workflow is change
password, illustrated as step 76. If the user's <change password
on next login> is set to No, the user will proceed to Step 5,
which is the user's system home page 80.
[0110] If the user's <change password on next login> is set
to Yes, the system will prevent the example user interface
illustrated as numeral 80 in FIG. 15. Table 11 defines example
attributes for aspects of the user interface illustrated in FIG.
15.
11TABLE 11 All fields are from the User table unless otherwise
specified Label Table/Field Mandatory Type Details and validation
Current Password Mandatory Text Text entered should be Password
displayed as *s New Password None Mandatory Text Text entered
should be displayed as *s Passwords stored in the database should
be encrypted so that no-one can view the password. Confirm New None
Mandatory Text Text entered should be Password displayed as *s
Passwords stored in the database should be encrypted so that no-one
can view the password. Secret SecretQuestionID Mandatory Dropdown
Dropdown from Question SecretQuestion table Secret
SecretQuestionAnswe Mandatory Text Question r Answer
[0111] If the user presses the Change Password button, the system
will check if the length of the New Password less than <system
min password length> or the password does not contain at least
one Alpha character (a-z,A-Z) and one number character (0-9), the
system will re-display the page with an error message. If the
Current Password does not match the password on the user's account,
or the New Password does not match the re-entered password, the
system will re-display the change password page with an error
message, and increment the users <failed login attempts> by
1.
[0112] If the user's new <failed login attempts> counter is
greater than the <system login attempts allowed> system
parameter, an error page is displayed. If the Current Password
matches the password on the account and the New Password and
Re-entered password are the same (but different from the current
password), and the new password length is greater than the
<system min password length> and the new password contains at
least one letter and number, the system will set the user's
<change password on next login> to No and the user will
progress to Step 5.
[0113] The fifth step of the user login workflow is a successful
login, referenced generally as numeral 80. In this step, the system
will record the user ID, date and time in the successful login
table, record the new password in an encrypted format in the user
table, and redirect the user to their system home page.
[0114] FIG. 16 is a preferred workflow for role maintenance. This
workflow comprises two primary steps: Selection of a role to
maintain, referenced as numeral 82, and maintaining the selected
user role, referenced as numeral 84. FIG. 17 is an example user
interface 86 for selecting a role to maintain. FIG. 18 is an
example user interface 88 for maintaining user roles. Table 12
defines example attributes for aspects of the user interface
illustrated in FIGS. 17 and/or 18.
12TABLE 12 Label Table/Field Mandatory Type Details and validation
All fields are from the UserRoles table unless otherwise specified
Role Name UserRoleName Mandatory Text Role names must be unique
Role Available AvailableToExte Mandatory Dropdown Yes/No for
external rnalCounsel counsel Number of users None Mandatory Read
only The count of the number of having this users having this role
role Menu permissions Tab All fields are from the
RoleMenuPermissions table unless otherwise specified Main Menu
MenuName Mandatory Read only Option Sub Menu Option SubMenuName
Mandatory Read only Permissioned Permissiomed Mandatory Option
Yes/No Screen Section permissions Tab All fields are from the
RoleScreenSectionPermissio- ns table unless otherwise specified
Screen Number ScreenID Mandatory Read only Screen Name
RoleScreenPermi Mandatory Read only ssions.ScreenNa me Screen
Section SectionName Mandatory Read only Permissions PermissionID
Mandatory Dropdown A dropdown of the following .cndot. No
restrictions .cndot. No Update .cndot. No View/Execute Label
Table/Field Mandatory Type Details and validation New Role Name
UserRoles. Mandatory Text Role names must be unique
UserRoleName
[0115] The `Save` Button saves the changes to the role profile and
returns the user to step 1. The `Cancel` Button cancels all changes
and returns the user to step 1. The `Delete` Button only appears if
the number of users for this role' dialogue. If they confirm they
are sure, the role is deleted.
[0116] The `Copy` Button will check that a role name has been
entered and that it is unique. If both of these conditions are
satisfied, a new role is created copying all of the permissions of
the original role. There is no link between the new and original
roles, unless the user observes some kind of naming convention
e.g.
[0117] Customer User--Trademarks
[0118] Customer User--Trademarks--Paralegal
[0119] Customer User--Trademarks--Attorney
[0120] On completion of the create process, the user is returned to
the Step 2 Maintain Role screen with the new role being the
focus.
[0121] Tables 13 and 14 contain example menu level permissions and
roles.
13 TABLE 13 Accessible to External Role Details Counsel Role 1 -
System Technical Support No Role 2 - Super User No Role 3 -
Customer User - All No Role 4 - Customer User - Trademarks No Role
5 - Customer User - Patents No Role 6 - Customer User - Conflicts
No Role 7 - Customer User - Agreements No Role 8 - Not used No Role
9 - External Counsel - All Yes Role 10 - External Counsel -
Trademarks Yes Role 11 - External Counsel - Patents Yes Role 12 -
Not used No Role 13 - Not used No Role 14 - Customer Client No
[0122]
14TABLE 14 Main Menu Role Role Role Role Role Role Role Item Sub
Menu Item 1 2 Role 3 Role 4 Role 5 Role 6 Role 7 Role 8 Role 9 10
11 12 13 14 Find TM Application Patent (phase 3) Search Domain Name
Copyright Conflict Agreement Invoice Create TM Application Patent
(Phase 3) Search Domain Name Copyright Conflict Agreement Invoice
Maintain Brand Mark Invention (Phase 3) Agent Company Territory
Users User Roles Preferences User Preferences Edit Favouritas
Change Password Add New User Add New User Role
[0123] FIG. 19 is a block diagram 90 illustrating a preferred
entity relationship diagram setting forth user roles and access
rights. The distributed legal workflow security computer system
allows users, through one or more computers, to input system access
privileges for one or more legal workflow participants based on one
or more legal workflow role types. System users may associate
permission privileges for a plurality of legal workflow graphical
interface systems functions based on the legal workflow role types.
Each system user or participant is allowed access to legal workflow
graphical interface functionality according to the permission
privileges associated with the participants respective legal
workflow role types.
Third Party Interface Workflow
[0124] In one aspect of the present invention, a process is defined
in which third parties update information on the collaborative
legal workflow tool. Third parties are presented with the same
collaborative legal workflow product. One difference may be that
the permissioning on the screens will vary, as defined by business
requirements. There are different types of permissioning that may
be applied. For example, certain screens may not be available to
certain third parties and/or third party users, and certain fields
may be set to `Read Only` or `No Execute`.
[0125] Third party subject areas and functionality in accordance
with the present invention include, but is not limited to,
trademark applications, trademark searches, conflicts,
organizations, time recording, billing, invoicing, agreements,
copyrights, domain names, patents, maintenance screen (e.g., brands
and marks, territories, organizations, etc.), reporting and the
implementation of tasks for third party diaries.
[0126] Third party law firms may see records where they have been
instructed as an agent. This rule may apply where law firms are
browsing through related records; i.e., they may only see related
records where they are representing the Customer.
[0127] When a trademark is registered, the Registry Office may
insist that a trademark is associated with other registered
trademarks. This typically means that the same company may own the
associated trademarks. However, certain territories do not
necessarily associate registrations. Therefore, if a law firm
operates in a territory where associations do not apply, then the
"associations" drop window option should be set to `No Execute`.
Law firms may be able to use a diary to raise ad hoc tasks for
Customers. In addition to this, law firms may record event history.
Law Firms may also receive tasks through the diary.
[0128] When a third party wishes to click through an underlying
record, they should be able to click through to conflicts (read
only) and trademark records where they are representing the
customer, and all organizational records (read only). Third parties
may not be able to click through invoices, agreements, copyrights,
domain names and maintenance functions. Preferably, the screen
design clearly shows the user what areas are read only. For the
third party interfaces, "create" and "admin" functionality should
be disabled.
[0129] FIG. 20 is an example user interface 92 for maintenance of
legal workflow in the collaborative online workflow tool of the
present invention. For demonstrative purposes, a "Maintain TM
Details" page is illustrated. In one embodiment of the present
invention, the following permissible sections, "Main TM Details"
94, "Verification" 96 and "Budget Name" 98, are accessible by the
users to allow modification of the information stored in those
fields. The remainder of the fields are permissioned to "Read Only"
access.
[0130] It is understood that if the security privileges for these
fields are set to "Read Only," a user would be unable to modify any
information. Additionally, the "charges" child window option should
be set to `No Execute`. The save, delete, edit and law buttons for
the following child windows should be set to `No Execute`: based
on, basis for, conv.priority, renewal, use/tax, certificates,
image, verification and internationals. It is also understood that
the user interface can be modified to manage a variety of
intellectual property matters, including patents, financial
invoicing, trademarks, conflicts and agreements.
[0131] FIG. 21 illustrates an example user interface 100 for a
child window of the trademark workflow record. The child window
includes permissioned fields which allow modification of trademark
information based on security permissions. In one embodiment of the
present invention, the agent instructions 102 and application
details 104 sections are set to allow modification of information
by the user.
[0132] FIG. 22 illustrates an example user interface 106 for
defining and presenting main conflict details. Preferably the
conflict umbrella and charges child window menu options are set to
`No Execute`. On all of the windows, the save, delete, edit and law
buttons should be set to `No Execute`.
[0133] FIG. 23 illustrates a user interface 108 for defining
organizational details. Preferably, the contact comments section is
set to `No View`. The following child window menu option should
also be set to `No Execute`: Law firm specialty, supplier info.,
verification and umbrella.
[0134] FIG. 24 illustrates an example user interface 110 for
defining contact information. Preferably, the contact comments and
contact comments-add sections are set to `No View`.
[0135] While the best mode for carrying out the invention has been
described in detail, those familiar with the art to which this
invention relates will recognize various alternative designs and
embodiments for practicing the invention as defined by the
following claims.
* * * * *
References