EP1497776A2 - Methods and computer systems for providing or setting access of a user to resources in a computer system - Google Patents

Abstract

A method for providing a user with access to resources in a computer system for a specified event. The method comprising performing at an user interface of the computer system: creating at least one event instance based on an event definition stored on the computer system, said event definition comprising a list of one or more tasks corresponding to the specified event and, for each task, one or more resources available in the computer system associated with the task; and processing the event instance at least in part by allowing selection of a task at the user interface in accordance with the task order, and providing at the user interface access to the one or more resources associated with the selected task.

Description

Title: Methods and computer systems for providing or setting access of a user to resources in a computer system.

This application claims priority to U.S. Provisional Application No. 60/375,371, filed on April 24, 2002, US application no 10/137/212 filed on April 30, 2002, US application no 10/161064 filed on May 31, 2002, US application 10/161071 filed on May 31, 2002, and US application no 10/161066 filed on May 31, 2002, the contents of which are hereby incorporated by reference into this application as if set forth herein in full.

BACKGROUND OF THE INVENTION The present application relates to a information management solutions, for example, for organizing access to applications, services, information, and other resources, and for handling cross-functional life and business processes.

Companies have long sought to unify disparate systems and information sources across the entire enterprise. A comprehensive unification process generally involves unifying computerized access to multiple resources, including applications (e.g., Enterprise Resource Planning ("ERP") applications, invoicing and supply management applications, and data warehouses), services (including Web-based, client-server, and other network services), and information (e.g., stored documents, Internet and intranet information, databases, and knowledge bases). The benefits of unifying such resources include increasing the value of the individual resources through integrated operation, allowing employees to collaborate on projects, and increasing the productivity and efficiency of the entire organization.

The process of unification, however, also creates new problems and challenges. One such problem is information overload: Presented with a barrage of applications and information, users frequently spend a significant amount of time navigating through the information and locating the appropriate applications with which to process the relevant information. Several solutions have emerged to help users locate the relevant applications, services, and information they need. For example, enterprise portals may help filter resources through the use of roles. In an enterprise portal that implements roles, each user within an organization is assigned a specific role within the organization, and the portal presents the user with choices based on his or her assigned role. For example, a user might be assigned the role of an accountant, and based on that assignment, the enterprise portal would present the user with a choice of bookkeeping applications and relevant information.

Although role-based portals help users locate resources, a user may be assigned to multiple roles, and within the course of executing one particular role, a user is provided access to a large variety of applications and information, several of which may not be relevant to the particular task the user is focused on at the time.

SUMMARY OF THE INVENTION It is a goal of the invention to provide a method which reduces the amount of information presented at a user-interface of a computer system to a user who is to perform a task.

According to a first aspect of the invention a method is provided according to claim 1. In such a method, the amount of information presented to the user is reduced, because access is provided at the user interface to the one or more resources associated with the selected task. The user will thereby be presented the one or more resources associated with the task and other resources may be disregarded by the user. According to a second aspect of the invention, a method is provided according to claim 2. Such a method allows a reduction of the amount of information presented to a user at an user interface, because a Hst of tasks corresponding to a specified event is specified and for each task, one or more resources available in the computer system are associated with the task and the hst of tasks is stored in a presentation format which can be presented at a user interface and allow access at the interface to the at least one resources associated with one or more of the tasks.

Also, a computer system according to claim 31 is provided. In such a computer system, the amount of information presented to the user is reduced, because access is provided at the user interface to the one or more resources associated with a selected task. The user will thereby be presented the resource associated with the task and other resources may be disregarded by the user.

The invention further provides a computer system according to claim 32. Such a computer system allows a reduction of the amount of information presented to a user at an user interface, because a hst of tasks corresponding to a specified event can be specified and for each task, one or more resources available in the computer system can be associated with the task and the Hst of tasks can be stored in a presentation format which can be presented at a user interface and allow access at the interface to the at least one resources associated with one or more of the tasks.

Also, a computer program product according to claim 69 is provided. Such a computer program product can be used in a programmable apparatus, e.g. computer, personal digital assistant or otherwise, to perform steps of a method according to the invention. Furthermore, a database according to claim 70 is provided. Such a database may be provided on a tangible data carrier, such as a CD-rom, a diskette or otherwise, and can be used to aHow access to resources available in a computer system at a user interface.

An article of manufacture according to claim 71 is also provided. Specific embodiments of the invention are set forth in the dependent claims.

Further details, aspects and embodiments of the invention will be described, by way of example only with reference to the figures in the attached drawings.

DESCRIPTION OF FIGURES The attached figures are incorporated into and form a part of this appHcation.

Figure 1 is a representation of the user interface of a conventional enterprise system.

Figure 2 illustrates an example of a user interface. Figure 3a illustrates a user interface with a pre-populated form. Figures 3b and 3c illustrate data flow.

Figure 4 is a diagram of a system for handHng Hfe and work events. Figure 5 is a flow chart iUustrating a process of creating an event definition. Figures 6a-6e are screenshots showing an example of creating an event definition.

Figures 7a-7d are representations of various navigation models. Figure 8 is a flow chart illustrating a process of handling an event.

DETAILED DESCRIPTION

The Life and Work Events system and techniques described herein (the "LWE system") provides users with access to resources associated with events. Providing a user with access to resources associated with a specified event involves enabling a user to perform certain operations, including specifying a Hst of one or more tasks that correspond to the specified event, specifying one or more resources associated with each task in the task Hst, indicating a task order (including an indication of whether two or more tasks from the task list are to be performed in an order- dependent manner or in an order-independent manner), and formatting the task list into a presentation format.

The specifying, indicating, and formatting operations may be performed by an administrative-user using interface controls provided in a graphical user interface such as a browser-based apphcation. The interface controls may include graphical abstractions (e.g., text entry fields, buttons, menus, icons, and Hnks). The operation of formatting the Hst of tasks may include specifying a navigation model (e.g., a flat Hst, a nested Hst, a tree structure, a flat Hst with related tasks delineated by group names, or folders) for presentation of the Hst of tasks.

The operation of indicating the task order may include indicating that two or more of the tasks that are to be performed in an order-dependent manner are to be performed in a specified sequence, or under the control of a wizard utility. The operation of indicating the task order may include indicating that two or more of the tasks that are to be performed in an order-independent manner may be performed in any order, or substantiaUy in paraUel. The operation of indicating the task order may also include indicating that some tasks are to be performed in an order-dependent manner, while other tasks are to be performed in an order-independent manner. The operation of indicating the task order may also include specifying task priorities.

The operation of specifying the Hst of one or more tasks may include specifying whether a task is optional or mandatory. The specified event may be a life or work event, and each resource may incorporate content, functionaHty, or a combination of both content and functionahty.

Providing a user with access to resources associated with a specified event may additionaUy involve enabhng a user to specify a home page or a due date for the specified event, and or to specify a task page associated with each task. It may also involve associating the specified event with one or more roles in a role-based portal.

In addition, providing a user with access to resources associated with a specified event may involve enabhng the user to specify that the specified event requires coUaboration among two or more participants. A coUaboration specification may include an identification of one or more owners of the specified event and one or more participants in the specified event, or an identification of one or more approvers associated with the specified event.

Providing a user with access to resources associated with a specified event may further involve enabling a user to import a pre-existing event definition, to create a new version of a pre-existing event definition, or to Hnk a specified event to a preexisting event definition, so that subsequent modifications made to the pre-existing event definition are automatically reflected in the specified event.

Providing a user with access to resources associated with a specified event may also involve enabhng the user to export the specified Hst of one or more tasks, the indicated task order, and the presentation format associated with the specified event.

The LWE system may include interface controls that enable a user to perform certain operations, including designating an event, generating a Hst of tasks associated with the event, and specifying an order for performance of the tasks in the task Hst that may be followed in processing an instance of the event. The user interface controls may include graphical abstractions (e.g., text entry fields, buttons, menus, icons, and Hnks), and may be provided in a graphical user interface such as a browser-based application.

The designated event, which may be a life or work event, may correspond to an objective to be achieved. The Hst of tasks may include one or more tasks. The user interface controls may also enable the user to specify a navigation model for presentation of the Hst of tasks.

The operation of specifying a performance order for the tasks in the task list may include specifying whether the tasks are to be performed sequentiaUy, in paraUel, or a combination of both. The operation may also include specifying whether some of the tasks are order-dependent and/or whether some of the tasks are order- independent, as weU as specifying whether some of the tasks are to be processed under the control of a wizard utility. The user interface controls may also enable the user to associate one or more resources with each task. Each resource may include content, functionaHty, or both.

The operation of designating an event may include providing descriptive information about the event (e.g., an event name and a textual description of the event). Similarly, the operation of generating the Hst of tasks may include providing descriptive information about each task (e.g., a task name and a textual description of each task).

The operation of designating an event may include copying, importing, creating a new version of, or Hnking the event to a pre-existing event definition. The operation may also include specifying a home page or a due date for the event. The user interface controls may also enable the user to specify a task page for each task, and to specify that an event requires coUaboration among two or more participants. In addition, the user interface controls may enable the user to associate the event with one or more roles in a role-based portal, and to export the designated event, the generated task Hst, and the specified performance order. A method of the LWE system may enable an administrative-user to define events that are to be processed by end-users. The method involves providing a software environment that supports certain functions, including presenting the administrative-user with a graphical user interface-based application for generating definitions of events, receiving input from the administrative-user that defines an event (the input including a Hst of tasks, one or more resources associated with each task, and an indication that two or more tasks are to be performed in an order- dependent manner or in an order-independent manner), formatting the Hst of tasks to conform to a designated navigation model, and associating the defined event with one or more roles in a role-based portal environment. The input from the administrative-user that defines an event may include an indication that some of the tasks are to be performed in an order-dependent manner, while other tasks are to be performed in an order- dependent manner. The input may also include a pre-existing event definition, an indication to create a new version of a pre-existing event definition, or a Hnk to a pre-existing event definition. The administrative-user may also export the input.

The LWE system may include a machine-readable medium with instructions that, when executed, cause a machine to perform certain operations, including specifying a Hst of one or more tasks corresponding to a specified event, specifying one or more resources associated with each task, indicating a task order (including an indication of whether two or more tasks are to be performed in an order-dependent manner or in an order-independent manner), and formatting the task Hst into a presentation format. The systems and techniques described herein extend the concept of HR events to events that users may handle across the entire spectrum of their work, or for that matter, their life. Users do not typicaUy or intuitively think about the particular apphcations, services, or information they might need on a particular day - rather, they tend to focus on the events that they need to deal with on that day. For example, an office manager might be presented with an event such as arranging a customer visit. Events are generaUy cross-functional business processes, meaning that in order to handle an event, a user may need to perform several functions or tasks. An event may generally correspond to one or more objectives to be achieved. The LWE system helps users handle events by presenting each event as a Hst of tasks. A task may involve running one or more applications, accessing one or more services, acquiring or providing one or more pieces of information, or a combination thereof. For example, an event such as arranging a customer visit may involve running a transaction within an ERP application such as SAP R/3 to reserve a conference room, running a word processing appHcation to generate an agenda for the visit, obtaining some information from the customer (e.g., who wiH be attending the visit), and providing some information to the customer (e.g., directions to the company site). In general, a task may involve accessing various resources, including certain content, certain functionaHty, or a combination of both.

The LWE system thus helps users to interact with processes that are triggered by Hfe or work events. Rather than presenting users with menus of apphcations, services, or information that are arranged alphabeticaUy or by function, the LWE system presents users with process- or event-oriented menus, wherein an event comprises a Hst of tasks that the user may be required to complete, and each task comprises a combination of resources that the user may be required to execute or access. By organizing and providing access to apphcations, services, and information resources based on events or cross-functional processes, the LWE system helps to reduce the time users spend navigating through an enterprise system to locate such resources. Moreover, by integrating resources within a task, and tasks within an event, the LWE system helps ehminate uncertainty about whether resources need to be accessed or executed in a specific sequence. The LWE system thus helps increase users' efficiency and productivity, and aUows users to operate more naturaUy by letting them focus on the underlying business processes or events. The disclosed LWE system provides additional benefits, including reducing the cycle time of business processes, transferring business process tasks and decisions to dispersed owners, and increasing the throughput of transactions and decisions. The disclosed LWE system may also be apphed outside of the traditional business context. For example, a government organization could use the system and method of the LWE system to enable users to handle an event such as moving to a new state, which might involve tasks such as filHng out an application for a driver's Hcense, registering one or more vehicles, registering to vote, and applying for accounts with local utihties. As another example, a portal web site could use the LWE system to help users manage an event such as getting married, which might involve a whole host of tasks related to planning the wedding ceremony, the reception, and the honeymoon trip. The disclosed LWE system can thus be utilized to handle a vast array of Hfe and work events.

Figure 1 shows a typical user interface 100 of a conventional enterprise system, in which resources are organized by functions. The user in this example is presented with a choice of running a number of different applications 110, interacting with a number of different services 120, or accessing a number of different information sources 130. This setup works well if the user knows which particular resource he needs to access. If the user does not know that, however, or if the user does not know the appropriate sequence in which to access resources in order to deal with a specific business event, then he typicaUy needs to spend time identifying and locating those resources and determining an appropriate sequence.

Figure 2 illustrates an example of a user interface 200 that may be used with the LWE system. In the example in Figure 2, the user is handhng a specific event 205. The left side 220 of interface 200 Hsts the tasks 210 that the user is to accompHsh in order to handle this event 205 successfully. The tasks 210 in this example are separated into two groups. As another Ulustration, the tasks that a user needs to complete in order to deal with an event such as a customer visit might be separated into three groups: the tasks needed to prepare for the visit, the tasks needed to execute the visit, and the tasks needed to foUow-up on the visit. In this way, the user is intuitively guided through the set of tasks that he must perform in order to handle the event.

The right side of interface 200 shows a page — in this case, the event home page 230. Each page may include one or more "iNiews." In this implementation, an iNiew is the smaUest unit of display, and generaUy corresponds to one particular appHcation, service, or segment of information. In this particular example, the event home page 230 has two iNiews — a first iView 232 comprising a document that provides system information, and a second iView 234 comprising a link to an external web site that provides accounting news.

Each task also has a task page associated with it, and as with event home pages, each task page may contain multiple iViews that represent a fusion of the apphcations, services, and information used to execute that task. By presenting an event as a Hst of tasks, and each task as a combination of the resources that are required or that help in executing the task, the LWE system not only guides the user in the appropriate sequence of steps to take so as to process the event successfully, but also helps the user locate such resources efficiently.

Some enterprise portals are role-based, meaning that they present a different set of resources and/or functionaHty depending on a user's assigned role (e.g., administrator, developer, manager, etc.). When used in conjunction with a role-based enterprise portal, each event may be assigned to one or more roles, and each role may be assigned to one or more users. For example, events may be defined for and assigned to roles such as "manager" or "team assistant," or even a more generic role such as "employee." Each user would then be able to instantiate and process the events that are associated with his role(s). In such an implementation, the task of navigating through enterprise resources is even more efficient, as a user may be presented only with the events, tasks, and resources that are relevant to his particular role(s). The layout of the iViews within an event home page or a task page may be adjusted by an administrator in the process of buUding the event definition, as is described in greater detaU below. In one embodiment, users may also specify additional resources that may be displayed in additional iViews. The personahzation and display of iViews and resources within event and task pages may be buUt directly into the LWE system; alternatively, such features may be implemented through functionaHty provided in an underlying system, such as an enterprise portal.

An advantage of the LWE system is that it fuses together the resources needed to execute specific tasks and events. Such resources may include many different types of content from disparate sources. For example, content may be structured data such as business inteUigence content. Content may also be unstructured data, such as knowledge management documents. In general, content may include any data that is capable of being displayed in an enterprise portal system.

Figure 3a iUustrates the execution of a data provider, which is another aspect of the LWE system. A data provider aUows data to be extracted from various sources and pushed to various destinations. For example, data may be extracted from an ERP system or from an enterprise portal. ERP data may be any data stored in the ERP system, such as, for example, data from employee records. Enterprise portal data may include portal user management data such as user IDs and passwords. The underlying systems from which data is imported may include systems from disparate vendors, such as Oracle and PeopleSoft. In an implementation in which the LWE system is used in conjunction with an enterprise portal, a data provider may generaUy import information from any data source connected to the portal.

Extracted data may be used in event instances. For example, ERP data from employee records may be used in a "performance review" event. Extracted data may also be pushed into iViews. As an example, in Figure 3a, extracted data is used to pre- populate an iView corresponding to a form that needs to be fiUed out. In the example in Figure 3a, the user is processing a "divorce" event 305, which requires him to complete the tasks in task Hst 310. One of those tasks is task 312, which requires the user to update his address information. Task page 330, which corresponds to task 312, is shown on the right side of the interface 300. Task page 330 contains two iViews — iView 332, which is a form that the user needs to fill out with his address information, and iView 334, which provides some additional information. In this example, the user's address information is stored in employee database 352 of ERP system 350. The data provider extracts the user's address information from employee database 352, and uses it to pre-populate the form in iView 332.

Figure 3b illustrates an example of how a data provider may be implemented. In the example, a user chcks on a task 312 in task Hst 310 that requires data 354 from the underlying SAP R/3 ERP system 350, which generates a request 390 to an Internet Transaction Server ("ITS") 360. The ITS 360 module presents ERP functionaHty via a browser interface — in essence, it is a browser interface to the ERP system 350. The ITS 360 sends a data request 391 to ERP system 350, which returns the requested data 354 in return message 392. The ITS 360 then sends this data 354 to a web-based knowledge base 370 in message 393, which creates an HTLM document containing the data 354. The HTML document is returned to the ITS 360 in return message 394, and presented to the user in an iView 332, as shown in step 395. A data provider may also be able to export data into an ERP or other system. A task might thus involve running an appHcation in a third-party system, importing the data accessed or generated by that appHcation into an iView, executing an appHcation to process that data, and then exporting the processed data back into the third-party system.

Figure 3c illustrates an example of such 2-way data flow. In this example, the LWE system 400 is used in conjunction with an enterprise portal, and the user 399 needs to execute a task that requires data from an ERP system 350 and an external resource 355. The user 399 first selects the task (step 380). The LWE system 400 sends a data request to the ERP system 350 (step 381), which returns the requested data (step 382). The LWE system 400 then sends this data to an external resource 355 (step 383), which processes the data and returns the results (step 384). The user 399 then enters some new data, which may be exported to the external resource 355 by the LWE system 400 (steps 385 and 386). Alternatively, the data may be saved directly into the external resource 355 (step 387), and extracted by the LWE system 400 (step 388). The new data is then exported into the ERP system 350 (step 389). Figure 4 is a diagram of a system for handhng Hfe and work events. In the example in Figure 4, the LWE system 400, which is used in conjunction with an enterprise portal 450, is comprised of three primary components — a b ld component 402, a runtime component 404, and a workflow engine 406. The bi ld component 402 is used to bufld event definitions 410. As described above, an event essentiaUy comprises a Hst of tasks, and a task comprises one or more appHcation, service, or segment of information (or combination thereof). Pre- configured event definitions may be used to b ld customized events, and groups of pre-configured events can be defined for and assigned to specific roles within an enterprise portal.

The buUd component 402 may include tools to create, copy, and edit events. Events may also be Hnked into hierarchies, so that modifications to a higher-level event definition are automaticaUy reflected in the definitions of lower-level events. Event definitions may be imported from or exported to event processing systems from third parties. Event definitions may also be versioned.

The runtime component 404 of the LWE system 400 may be used to create event instances from event definitions 410. Events may be instantiated either by a user 399 (e.g., when a manager finds out that a customer is coming to visit, he may create an instance of a "customer visit" event), or by the system (e.g., an event instance may be triggered by the occurrence of a specific condition). In one embodiment, multiple instance of an event may be created from the same event definition. Multiple instances of an event may require multiple versions of event definitions, so that an instantiated event may continue to run even when the event definition that was used to instantiate the event is changed. Event instances may also be personahzed. For example, an event definition may specify that some tasks are optional, in which case the user is given the option of de-selecting such tasks when such an event is instantiated.

The runtime component 404 may also be used in conjunction with the workflow engine 406 to process event instances and to enable event management functionaHty. The workflow engine 406 depicted in Figure 4 controls task handhng, and updates and stores the status of instantiated events in an event store 412, which enables users to process events over an extended period of time. Workflow engines are commerciaUy avaflable from a number of vendors, including Staff are, Sawion, and IntaHo, but such workflow engines may be customized to provide additional functionaHty. For example, and event definition may specify that tasks within a particular event may be executed in sequence, in paraUel, or in a combination of the two (i.e., some tasks may be performed in paraUel, while others must be performed in sequence). The workflow engine 406 would then ensure that the user 399 performs the required tasks in a sequence that comphes with the constraints specified in the event definition. Alternatively, the workflow engine 406 may change the order of tasks based on timing or other requirements, or the workflow engine 406 may change the order of tasks dynamicaUy, based on the occurrence of internal or external events.

The runtime component 404 and the workflow engine 406 may also aUow users to keep track of their progress through an event's task Hst, for example, by checking tasks off as they are done. In an embodiment in which users may create multiple instances of the same event, the runtime component 404 and the workflow engine 406 may aUow users to progress through those multiple instances at different rates. To accompHsh this functionaHty, instances are stored in a user context rather than a global context.

The runtime component 404 and workflow engine 406 may also include a wizard to help guide users through a particular sequence of tasks. Wizards may be helpful in handling complicated task lists (e.g., when some of the tasks must be performed in sequence, while some of the tasks may be performed in paraUel).

The LWE system's workflow features may enable coUaboration among multiple participants in an event. For example, an event may be assigned to one or more owners. A task may also be assigned to one or more owners, or delegated to an agent, who would then be responsible for executing that task. An event or a task may also be assigned to an approver, who needs to sign off on the satisfactory completion of the event or the task. An approver may be a manager, a department head, or another specific person. An administrator may also specify the source of information or the destination to which information needs to be sent. In such an implementation, the workflow engine is programmed to ensure that such requirements are satisfied before tasks can be checked off as completed.

Figure 5 depicts steps that may be used in the process of creating an event definition. In Step 500, an administrator uses the buUd component 402 to create a new event definition. Step 500 is iUustrated in Figure 6a. When creating an event, the administrator may give the event a name 602, as weU as a short description 604. The LWE system can then assign a technical name 606 or handle to the event definition. The administrator may also copy an existing event definition from the Hst of existing event definitions 610, and then edit the copied event definition by chcking on an edit button 608. When the administrator is ready to proceed to the next step, he can chck on the "create event" button 612.

In Step 502, the administrator may edit the event name 602 and the short description of the event definition 604, as shown in Figure 6b. The administrator then cHcks on the "create/edit event home page" button 614 in order to build an event home page (or to edit an existing event home page). As explained above, an event home page may display the initial set of resources the user sees after he has instantiated an event corresponding to the event definition. When the administrator is finished, he may chck on the "save" button 616 in order to save the portion of the event definition that has been created thus far, and proceed to the next step in the event creation process.

In Step 504, the administrator creates a task Hst for the event, as Ulustrated in Figures 6c- 1 and 6c-2. As part of this step, the administrator may provide detaUs for each task, including a name 622 and a short description 624 of the task. When the administrator cHcks on the "create task" button 626, the LWE system may assign a technical name 628 or handle to the current task being created, and add the current task to the event task list 630.

The administrator then builds a task page for each task in the event task Hst 630 by selecting a task from the task list 630 and clicking on the "create/edit task page" button 632. The task page of a task can display the resources associated with the task (i.e., the resources the user may need to access or execute in order to complete the task).

The administrator may edit a task's name 622 or short description 624, as weU as add a user description 634 that may be displayed to the user to help the user understand what he is supposed to do in order to execute the task properly.

When the administrator is ready to proceed to the next step, he may chck on the "save" button 616, which saves the portion of the event definition that has been created thus far. Alternatively, the administrator may navigate to a different step in the event creation process by selecting one of the Hnks in the creation process Hst 638. The Hnks shown in the creation process Hst 638 generaUy correspond to the steps iUustrated in Figure 5.

In Step 506, the administrator formats the Hst of tasks into a presentation format in a way that helps the user navigate through the tasks, as iUustrated in Figure 6d. Any of several different navigation models may be used. The simplest model is a flat Hst of tasks. Figure 7a depicts another arrangement, in which tasks are organized into groups. In Figure 7a, tasks 711, 712, and 713 are grouped into a first group 710, and tasks 721, 722, and 723 are grouped into a second group 720. A simple grouping arrangement is also shown in Figure 6d. The administrator may begin a new group by typing in a group name 640 and chcking on the "begin a group" button 642. The example in Figure 6d shows one group 644. The administrator may rearrange the tasks within groups by chcking on a task radio button 646, and then chcking on either the "move up" button 648 or the "move down" button 650. Figure 7b depicts an alternative arrangement of tasks in which groups may be nested within each other. In Figure 7b, tasks 722 and 723 have been put into a new group 725, and the entire new group 725 has been nested within group 720.

Figure 7c depicts another alternative arrangement in which tasks can be nested into trees. In Figure 7c, tasks 712 and 713 are shown as sub-tasks of task 711. Tasks 721 has two sub-tasks (tasks 722 and 726), and sub-task 722 itself has two sub- tasks (tasks 723 and 724).

Figure 7d depicts yet another alternative arrangement, in which tasks are organized into nested Hsts. Task Hst 210 in interface 200 shows a first task 711 and a second task 721. Task page 230 corresponding to task 711 shows that task 711 comprises three sub-tasks (tasks 730, 731, and 732). The user can chck on tasks 730, 731, or 732 to be shown the task pages that correspond to those tasks.

In addition to different navigation models, colors and other enhancements may be used to show different task priorities. For example, high priority tasks can be colored red, while normal priority tasks can be colored black. Different navigation models and enhancements may be used to make it easier for users to identify an appropriate sequence in which to process tasks associated with an event.

After the task list is formatted, the administrator may have to go through a finishing step to make the event definition avaUable to users, as shown in Figure 6e. For example, when the LWE system is used in conjunction with an enterprise portal, the event administrator can associate an event home page with the roles of the users who may need to process such an event. In Figure 6e, the administrator can chck on the "portal content directory" button 660 to be shown the Hst of roles that have been defined for the portal; the administrator may then choose the appropriate roles to which to add the event definition that is being created.

Creating an event definition may involve additional steps or sub-steps. For example, an administrator may specify an ordering sequence in which the tasks associated with an event must be executed. The administrator may specify, for instance, that some of the tasks in an event may be performed in an order- independent manner (e.g., in any order, or substantiaUy in paraUel). The administrator may also specify that some of the tasks in an event are to be performed in an order-dependent manner (e.g., a specified sequence). Alternatively, the administrator may specify that some of the tasks in an event may be performed in an order-independent manner, while others are to be performed in an order-dependent manner. The administrator may also indicate a wizard utility to guide the user through an appropriate sequence of order-dependent tasks.

In addition, the administrator may aUow the user to personahze an event instance. For example, the administrator may designate certain tasks as optional and certain tasks as mandatory. When the user instantiates an event based upon such an event definition, he may then de-select some or aU of the tasks that the administrator designated as optional.

The process of creating event definitions may also involve the step of Unking event definitions. If two event definitions are Hnked, changes in one event definition may be automaticaUy reflected in the Hnked event definition. For example, an administrator may create an event definition representing customer visits from Japan. The administrator may create such an event definition by copying the event definition of a generic customer visit, and then modifying that definition, for example, by adding a task such as locating a translator. The administrator may then Hnk the Japanese customer visit event definition to the generic customer visit event definition. If the administrator subsequently makes a change to the event definition of a generic customer visit, the change may be reflected in the event definition of a Japanese customer visit. Additional enhancements may be made to the process of creating event definitions. For example, the LWE system may aUow the administrator to create multiple versions of an event definition. This would be useful, for example, when an administrator updates an event definition whUe an event instance based on that event definition is running. In such a scenario, the instantiated event may continue to run based on the old version of the event definition, whUe any new event instantiation would be based on the new version of the event definition.

The LWE system may also aUow the administrator to import event definitions that are created by third parties. For example, an administrator may import an event definition from an event processing system produced by a competing manufacturer, or from a repository where users of the system may store event definitions that they have created themselves. The LWE system may also aUow the administrator to export event definitions. For example, the administrator may export event definitions into a repository where users can access those event definitions and use them to create new event definitions.

The process of creating an event definition may be carried out by an administrator using interface controls provided in a graphical user interface. As shown in Figures 6a — 6e, such a graphical user interface may comprise graphical abstractions, including one or more text entry fields, buttons, menus, icons, or links. The user interface controls may also be provided in a browser-based appHcation.

Figure 8 depicts steps that may be used in instantiating and processing an event. In Step 800, an event is instantiated based on the definition that was created for that event. In step 802, the user is aUowed to select a task to work on based on predetermined task ordering criteria, as defined above. For example, if an event definition specifies that the tasks for a particular event may aU be performed in paraUel, then the user can select any of the event's tasks to work on. However, if the event definition specifies that the tasks must be performed sequentiaUy, than the user cannot select a task to work on until aU its predecessor tasks have been completed.

In Step 804, the task page of the selected task is displayed, from which the user can access the various resources that may be needed to complete the task. In Step 806, if the task is not completed, the user may return to Step 802 and select another task to work on, provided that such an action is permissible by the task sequencing specified in the event definition. Returning to Step 806, if the task was completed, the user then proceeds to Step 808, where the task is marked off as completed. The user may mark off the completed task manuaUy; alternatively, the system may automaticaUy mark off a completed task upon the occurrence of a specific event, such as the closing of an appHcation associated with the task.

A check is then performed in Step 810 to see if aU of the tasks for a particular event have been completed; if so, the event itself is completed, otherwise, the user returns to Step 802, where he may select another task to work on.

Processing an event may involve additional steps. For example, after an event is instantiated, a user may de-select tasks that are specified as optional in an event definition. Error-handling features and routines may also be built into the LWE system. For example, the LWE system may prevent the user from selecting or processing a task that has already been marked as completed. The LWE system may also include features such as specifying due dates for events, and the ability to interface with the user and to handle resources and event definitions in multiple languages. Event due dates may be specified by an administrator when creating an event definition, or by a user or the LWE system when an event is instantiated. Another concept that has emerged to help users navigate through an enterprise system is Employee Self-Services ("ESS"). TypicaUy buUt into Human Capital Management ("HCM") applications, ESS takes the approach that employees are faced with particular human resource ("HR") events that they need to deal with, and presents employees with specific tasks that they need to accompHsh in order to deal with pre-defined HR events. For example, a pre-defined HR event might be a company's annual benefits open enroUment period. In order to process such an event, each employee would be presented with a list of tasks to accompHsh (e.g., choose a new medical insurance provider, update the level of life insurance coverage, verify beneficiary information, and so forth). Each task is generaUy related to a particular appHcation and/or to a specific set of information, and the employee is presented with only those resources that are necessary to perform that task

The computational aspects described here can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Where appropriate, aspects of these systems and techniques can be implemented in a computer program product tangibly embodied in a machine- readable storage device for execution by a programmable processor, and method steps can be performed by a programmable processor executing a program of instructions to perform functions by operating on input data and generating output. To provide for interaction with a user, a computer system can be used having a display device such as a monitor or LCD screen for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackbaU by which the user can provide input to the computer system. The computer system can be programmed to provide a graphical user interface through which computer programs interact with users.

It should be noted that the above-mentioned embodiments illustrate rather than Hmit the invention, and that those skiUed in the art will be able to design alternatives without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shaU not be construed as Hmiting the claim. The word 'comprising' does not exclude the presence of other elements or steps than those Hsted in a claim. The mere fact that certain measures are recited in mutuaUy different claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

1. A method for providing a user with access to resources avaύable in a computer system for a specified event, comprising performing at an user interface of the computer system: creating at least one event instance based on an event definition stored on the computer system, said event definition comprising a Hst of one or more tasks corresponding to the specified event and, for each task, one or more resources avaUable in the computer system associated with the task; and processing the event instance at least in part by aUowing selection of a task at the user interface in accordance with the task order, and providing at the user interface access to the one or more resources associated with the selected task.

2. A method for setting access of a user to resources avaUable in a computer system for a specified event, which optionaUy comprises a method as claimed in claim

1, and comprising: defining an event definition of said specified event by means of operations at an interface in the computer system, said operations comprising: specifying a Hst of one or more tasks corresponding to the specified event and, for each task, associating one or more resources avaUable in the computer system with the task; indicating a task order, including indicating whether two or more tasks in the task

Hst are to be performed in an order-dependent manner or in an order-independent manner; and storing the Hst of tasks into a presentation format which can be presented in a user interface and which by said presenting provides at the user interface access to one or more of the resources associated with a task.

3. A method as claimed in claim 1 and/or claim 2, wherein the event definition further comprises: a specification of data from at least one external source outside the computer system associated with at least one of the tasks; and wherein the method may further comprise: processing the event instance at least in part by importing into the computer system said associated data from the external source.

4. A method as claimed in any one of the preceding claims, wherein the specifying, indicating, and formatting operations are performed by an administrative- user using interface controls provided in a graphical user interface.

5. A method as claimed in any one of the preceding claims, wherein the user interface controls comprise graphical abstractions.

6. A method as claimed in any one of the preceding claims, wherein the graphical abstractions comprise one or more of text entry fields, buttons, menus, icons, and Hnks.

7. A method as claimed in any one of the preceding claims ,wherein the user interface controls are provided in a browser-based appHcation.

8. A method as claimed in any one of the preceding claims, wherein the specified event comprises a Hfe or work event.

9. A method as claimed in any one of the preceding claims, wherein the operation to format the Hst of tasks comprises specifying a navigation model for presentation of the Hst of tasks.

10. A method as claimed in claim 9, wherein the navigation model comprises a flat Hst, a nested Hst, or a tree structure.

11. A method as claimed in claim 9 or 10, wherein the navigation model comprises a flat Hst with related tasks deHneated by a group name.

12. A method as claimed in any one of claims 9-11, wherein the navigation model comprises folders.

13. A method as claimed in any one of the preceding claims, wherein the operation to indicate the task order comprises indicating that two or more tasks that are to be performed in an order-dependent manner are to be performed in a specified sequence.

14. A method as claimed in any one of the preceding claims wherein the operation to indicate the task order comprises indicating that two or more tasks that are to be performed in an order-dependent manner are to be performed under control of a wizard utihty.

15. A method as claimed in any one of the preceding claims wherein the operation to indicate the task order comprises indicating that two or more tasks that are to be performed in an order-independent manner may be performed in any order or substantiaUy in parallel.

16. A method as claimed in any one of the preceding claims wherein the operation to indicate the task order comprises indicating a pluraHty of tasks are to be performed in an order-dependent manner and that another plurality of tasks are to be performed in an order-independent manner.

17. A method as claimed in any one of the preceding claims wherein the operation to specify the Hst of one or more tasks further comprises specifying whether a task is optional or mandatory.

18. A method as claimed in any one of the preceding claims wherein the operation to indicate the task order further comprises specifying task priorities.

19. A method as claimed in any one of the preceding claims wherein at least two of said resources comprise appHcation which can be run on the computer system.

20. A method as claimed in any one of the preceding claims further comprising enabhng the user to specify a home page associated with the specified event.

21. A method as claimed in any one of the preceding claims further comprising enabhng the user to specify a due date associated with the specified event.

22. A method as claimed in any one of the preceding claims further comprising enabhng the user to specify a task page associated with each task.

23. A method as claimed in any one of the preceding claims further comprising enabhng the user to specify that the specified event requires coUaboration among two or more participants.

24. A method as claimed in claim 23, wherein specifying that the specified event requires coUaboration comprises identifying one or more owners of the specified event and one or more participants in the specified event.

25. A method as claimed in claim 23 or 24, wherein specifying that the specified event requires coUaboration comprises identifying one or more approvers associated with the specified event. ■

26. A method as claimed in any one of the preceding claims further comprising enabhng the user to associate the specified event with one or more roles in a role- based portal.

27. The method as claimed in any one of the preceding claims further comprising enabhng the user to import a pre-existing event definition.

28. The method as claimed in any one of the preceding claims further comprising enabhng the user to create a new version of a pre-existing event definition.

29. The method as claimed in any one of the preceding claims further comprising enabhng the user to Hnk the specified event to a pre-existing event definition such that subsequent modifications made to the pre-existing event definition are automaticaUy reflected in the specified event.

30. The method as claimed in any one of the preceding claims further comprising enabhng the user to export the specified Hst of tasks, the indicated task order, and the presentation format.

31. A computer system, comprising a user interface for providing a user with access to resources avaUable in a computer system, said user interface comprising controls for performing: creating at least one event instance based on an event definition stored on the computer system, said event definition comprising a Hst of one or more tasks corresponding to the specified event and, for each task, one or more resources avaUable in the computer system associated with the task; and processing the event instance at least in part by aUowing selection of a task at the user interface in accordance with the task order, and providing at the user interface access to the one or more resources associated with the selected task.

32. A computer system, which optionaUy comprises a computer system as claimed in claim 31, comprising: an interface with controls for setting access of a user to resources associated with a specified event avaUable in the computer system, said controls enabhng performing operations comprising: specify a list of one or more tasks corresponding to the specified event and, for each task, associating one or more resources present in the computer system with the task; indicate a task order, including indicating whether two or more tasks in the task Hst are to be performed in an order-dependent manner or in an order-independent manner; and format the Hst of tasks into a presentation format which can be presented in a user interface and by said presenting provided at the user interface access to one or more of the resources associated with a task.

33. A computer system as claimed in claim 31 and/or 32, wherein the event definition further comprises: a specification of data from at least one external source outside the computer system associated with at least one of the tasks; and wherein the computer system may further comprise: a control for processing the event instance at least in part by importing into the computer system said associated data from the external source

34. A system as claimed in any one of claims 31-33, wherein the user interface controls are provided in a graphical user interface environment.

35. A system as claimed in any one of claims 31-34, wherein the user interface controls comprise graphical abstractions for interacting with a user.

36. A system as claimed in claim 35, wherein the graphical abstractions comprise one or more of text entry fields, buttons, menus, icons, and Hnks.

37. A system as claimed in any one of claims 31-36, wherein the user interface controls are provided in a browser-based appHcation.

38. A system as claimed in any one of claims 31-37, wherein the event corresponds to an objective to be achieved.

39. A system as claimed in any one of claims 31-38, wherein the Hst of tasks comprises one or more tasks.

40. A system as claimed in any one of claims 31-39, wherein the user interface controls further enable the user to specify a navigation model for presentation of the list of tasks.

41. A system as claimed in claim 40, wherein the navigation model comprises a flat Hst, a nested Hst, or a tree structure.

42. A system as claimed in claim 40 or 41wherein the navigation model comprises a flat Hst with related tasks deHneated by a group name.

43. A system as claimed in any one of claim 40-42, wherein the navigation model comprises folders.

44. A system as claimed in any one of claims 31-43, wherein the operation to specify the order comprises specifying whether tasks are to be performed sequentiaUy, in paraUel, or a combination of both.

45. A system as claimed in any one of claims 31-44, wherein the operation to specify the order comprises specifying that a pluraHty of tasks are order-dependent.

46. A system as claimed in any one of claims 31-45, wherein the operation to specify the order comprises specifying that a pluraHty of tasks are order-independent.

47. A system as claimed in any one of claims 31-46, wherein the operation to specify the order comprises specifying that a pluraHty of tasks are order-dependent and another plurality of tasks are order-independent.

48. A system as claimed in any one of claims 31-47, wherein the operation to specify the order comprises specifying that one or more tasks are to be processed under the control of a wizard utility.

49. A system as claimed in any one of claims 31-48, wherein the operation to generate the Hst of tasks comprises specifying whether a task is optional or mandatory.

50. A system as claimed in any one of claims 31-49, wherein the operation to specify the order comprises specifying task priorities.

51. A system as claimed in any one of claims 31-50, wherein the user interface controls further enable the user to associate one or more resources with each task.

52. A system as claimed in claim 51, wherein each resource comprises content or functionaHty or a combination of both.

53. A system as claimed in any one of claims 31-52, wherein the operation to designate the event comprises providing information descriptive of the event.

54. A system as claimed in claim 53, wherein the information descriptive of the event comprises one or more of an event name and a textual description of the event.

55. A system as claimed in any one of claims 31-53, wherein the operation to generate the Hst of tasks comprises providing information descriptive of each task.

56. A system as claimed in claim 55, wherein the information descriptive of each task comprises one or more of a task name and a textual description of the task.

57. A system as claimed in any one of claims 31-56, wherein the operation to designate the event comprises copying a pre-existing event definition.

58. A system as claimed in any one of claims 31-57, wherein the operation to designate the event comprises importing a pre-existing event definition.

59. A system as claimed in any one of claims 31-58, wherein the operation to designate the event comprises creating a new version of a pre-existing event definition.

60. A system as claimed in any one of claims 31-59, wherein the operation to designate the event comprises Unking the event to a pre-existing event definition such that subsequent modifications made to the pre-existing event definition are automaticaUy reflected in the designated event.

61. A system as claimed in any one of claims 31-60, wherein the operation to designate the event comprises specifying a home page associated with the event.

62. A system as claimed in any one of claims 31-61,wherein the user interface controls further enable the user to specify a due date associated with the event.

63. A system as claimed in any one of claims 31-61, wherein the user interface controls further enable the user to specify a task page associated with each task.

64. A system as claimed in any one of claims 31-63, wherein the user interface controls further enable a user to specify that the event requires coUaboration among two or more participants.

65. A system as claimed in claim 64, wherein specifying that the event requires coUaboration comprises identifying one or more owners of the event and one or more participants in the event.

66. A system as claimed in claim 64 or 65, wherein specifying that the event requires collaboration comprises identifying one or more approvers associated with the event.

67. A system as claimed in any one of claims 31-66 wherein the user interface controls further enable the user to associate the event with one or more roles in a role- based portal.

68. The system as claimed in any one of claims 31-67, wherein the user interface controls further enable the user to export the designated event, the generated task list, and the specified performance order.

69. A computer program product, comprising program code portions for performing steps of a method as claimed in any one of claims 1-30 when run on a programmable apparatus.

70. A database arranged for use in a method as claimed in any one of claims 1-30 comprising: at least one event definition and a list of one or more tasks corresponding to the specified event and, for each task, one or more resources avaUable in the computer system associated with the task; a task order, including an indication whether two or more tasks in the task Hst are to be performed in an order-dependent manner or in an order-independent manner.

71. An article of manufacture with a computer usable medium having computer readable instructions embodied therein for providing access to resources avaUable on that computer, the computer readable instructions comprising instructions to cause the computer to perform the steps of a method as claimed in any one of claims 1-30