WO1999026122A2

WO1999026122A2 - Processing requests for service of a physical facility

Info

Publication number: WO1999026122A2
Application number: PCT/US1998/024616
Authority: WO
Inventors: Rolando Dimaandal; Yan-Zhe Wang; Tomohiko Terada
Original assignee: Sun Microsystems, Inc.
Priority date: 1997-11-18
Filing date: 1998-11-18
Publication date: 1999-05-27
Also published as: WO1999026122B1; WO1999026122A3; JPH11232349A

Abstract

A method and apparatus for processing and managing requests for service of a physical facility is disclosed. In one embodiment, a system for managing requests for service of a facility comprises a monitor window displayed on a display device (112); a network connecting the display device to a processor (104); and a memory (106) coupled to the processor. A database of service requests, and processor instructions coupled to the database are stored in the memory (106). The processor instructions are configured to cause the processor (104) to enter the service requests in the database, and display the service requests in the monitor window (Fig. 6) over the network when the service requests are entered into the database.

Description

PROCESSING REQUESTS FOR SERVICE OF A PHYSICAL FACILITY

FIELD OF THE INVENTION

The present invention relates to using a computer system to receive, manage, and report data about requests for service of a physical facility.

BACKGROUND OF THE INVENTION

Many offices, factories, and other work environments employ a staff of full- time facilities technicians who maintain the buildings, furnishings, and systems of the work environment. Generally, those who work in the work environment make a request for service by telephoning a facilities office or individual facilities technicians or managers. A record of the request is made, the request is assigned to a technician and at some fixture point the request is fulfilled and the record is updated to indicate that the request is complete. For example, if a worker in an office discovers on a particular day that the temperature of her office is too cold, she would call the facilities office, report the problem, and expect it to be corrected in a reasonable period of time. A manager in the facilities office would make a written record of the request, and then pass the request to an assigned service technician. The service technician would go to the reporting employee's office at a time determined by the service technician, and then work on the problem. If and when the problem is solved, the service technician would move on to the next reported problem. In some cases, a written or verbal report on the solution would be provided to the facilities office.

In an increasingly large work environment or facility, without some sort of computer-assisted management of requests, the foregoing scenario becomes impractical. It is difficult for management to determine how busy the facilities technicians are, or to determine the status of any particular request. It is difficult for management to determine whether requests are fulfilled in an acceptable time period, or whether reporting employees are satisfied with the service being provided. Thus, efficient use of such facilities technicians is improved if those who manage the facilities technicians can access coherent, orderly, comprehensive and accurate data describing each request for service, its status, and other information.

In addition, efficiency and service are improved if the individuals making service requests are able to query an automated system to determine the status of their request and the time at which it is likely to be fulfilled.

One approach to automating the facility maintenance process provided a front end request management computer program that was directly coupled to a relational database management system. A user would log in to the front end program, enter a new service request including its type and any comments, and submit it to the database. The front end program would generate an electronic mail message to the requesting user with a copy to persons listed in an electronic mail alias of facilities technicians and technical administrators. The system would treat all users on an equal basis. For example, users could view and attempt to select functions and options that are actually available only to facilities technicians and technical administrators. This created frustration on the part of users, who would attempt to select a function that appears available, only to have the function do nothing. The two-tier architecture of the system required the front end program to be rewritten and recompiled before it could be used on a different computer platform; this creates the risk of introducing errors into the new version. The prior system would also interfere with a user's computer environment by writing parameter files and other files in the user's home file directory without disclosing such action to the user. The prior system would store database queries constructed by a facilities technical administrator in the home directory of the administrator's computer system, creating a risk that the administrator could inadvertently delete such queries, which may take considerable time to prepare. The prior system would display newly entered request records only when a user logged into the system. The prior system also had a poorly designed graphical user interface, requiring the use of multiple, confusing windows to enter a query or perform other functions. As a result, the prior system induced an over-dependence on email. Facilities technical administrators would wait for messages announcing new service requests to appear in their email boxes rather than watching screens displayed by the prior system. This created the risk that new service requests would be overlooked or missed if the email system failed or experienced transmission delays.

Based on the foregoing, it is clearly desirable to develop a mechanism for processing service requests that can receive, store in an orderly format, and report on service requests. It is further desirable to provide a system or method that can report on the time actually taken by a service technician to resolve or complete a service request. It is also desirable to provide a system or method that can receive and report on queries about pending or completed service requests on a real-time basis, so that a manager or technician responsible for fulfilling service requests is alerted to a new request immediately upon submission of the request.

It is also desirable to provide a system or method that provides an easy to understand and attractive way to display request information. It is also desirable to provide a system or method for processing service requests that does not complicate the user interface by displaying options that are not available to the current user. SUMMARY OF THE INVENTION

The invention encompasses a system, method, computer program product, and carrier wave signal for managing requests for service of a facility. In one embodiment, a system for managing requests for service of a facility comprises a monitor window displayed on a display device; a network connecting the display device to a processor; and a memory coupled to the processor. A database of service requests, and processor instructions coupled to the database are stored in the memory. The processor instructions are configured to cause the processor to enter the service requests in the database, and display the service requests in the monitor window over the network when the service requests are entered into the database.

In one aspect, this embodiment further includes a browser coupled to the display device; a browser registry coupled to the browser and having a table of the display devices that are activated; and processor instructions configured to cause the processor to store a description of the browser in the browser registry. A feature of this embodiment is processor instructions configured to cause the processor to generate an electronic mail message to the browser when a new service request is stored in the database. Another feature is a new service request that comprises an Assigned To value identifying a host of a service person assigned to carry out the new service request, and instructions configured to store the new request in the database, and generate a second electronic mail message to the host when the new service request is stored in the database.

Another feature is a database interface coupled between the database and the processor, wherein the database interface is configured to translate a database request of the processor into a database command compatible with the database. In another aspect, the invention includes a servlet coupled between the database and the processor, and instructions configured to cause the servlet to communicate the second electronic mail message to the display device.

In yet another aspect, the instructions are configured to close the new service request; generate an evaluation message; and deliver the evaluation message to the display device. Another feature of the invention is instructions configured to enter a new service request in the database, and display the new service request in the monitor window when the new service request is entered in the database and when a technician assigned to the new service request is using the display device that is registered in the browser registry. BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which: Figure 1 is a block diagram of a computer system on which the present invention may be implemented;

Figure 2 is a block diagram showing logical processing components of the invention;

Figure 3 is block diagram showing logical processing components of an embodiment of the invention used in customer satisfaction processing;

Figure 4A is a flow chart showing principal steps in operation of an embodiment of the invention;

Figure 4B is a flow chart showing principal steps in processing a new task using an embodiment of the invention; and Figure 5 is a diagram of an exemplary screen display produced by an embodiment of the invention in carrying out top-level function selection.

Figure 6 is a diagram of an exemplary screen display produced by an embodiment of the invention in carrying out new task entry.

Figure 7A is a diagram of an exemplary screen display produced by an embodiment of the invention in carrying out display and processing of existing tasks. Figure 7B is a diagram of an exemplary screen display produced by an embodiment of the invention in carrying out display and processing of task information.

Figure 7C is a diagram of an exemplary screen display produced by an embodiment of the invention in carrying out closing of a task. Figure 7D is a diagram of an exemplary screen display produced by an embodiment of the invention in carrying out task monitor display.

Figure 8A is a diagram of an exemplary screen display produced by an embodiment of the invention in carrying out entry of a query.

Figure 8B is a diagram of an exemplary screen display produced by an embodiment of the invention in carrying out site selection for a query.

Figure 8C is a diagram of an exemplary screen display produced by an embodiment of the invention in carrying out assignment of personnel to a query.

Figure 8D is a diagram of an exemplary screen display produced by an embodiment of the invention in carrying out display of query results. Figure 9 is a diagram of an exemplary screen display produced by an embodiment of the invention in carrying out display and modification of user information. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

A method and apparatus for processing service requests is described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

HARDWARE OVERVIEW

Referring to Figure 1 , it is a block diagram of a computer system 100 upon which an embodiment of the present invention can be implemented. Computer system 100 includes a bus 102 or other communication mechanism for communicating information, and a processor 104 coupled with bus 102 for processing information. Computer system 100 further comprises a random access memory (RAM) or other dynamic storage device 106 (referred to as main memory), coupled to bus 102 for storing information and instructions to be executed by processor 104. Main memory 106 also may be used for storing temporary variables or other intermediate information during execution of instructions by processor 104. Computer system 100 also comprises a read only memory (ROM) and/or other static storage device 108 coupled to bus 102 for storing static information and instructions for processor 104.

A data storage device 110 is coupled to bus 102 for storing information and instructions, such as a magnetic disk or optical disk and its corresponding disk drive and interface, can be coupled to computer system 100. Computer system 100 can also be coupled via bus 102 to a display device 112, such as a cathode ray tube (CRT), for displaying information to a computer user. Computer system 100 further includes an input device 114 such as a keyboard and a cursor control 116, such as a mouse.

Computer 100 also includes a communication interface 118 coupled to bus 102. Communication interface 118 provides a two-way data communication coupling through a network link 120 to a local network 122. For example, if communication interface 118 is an integrated services digital network (ISDN) card or a modem, communication interface 118 provides a data communication connection to the corresponding type of telephone line. If communication interface 118 is a local area network (LAN) card, communication interface 118 provides a data communication connection to a compatible LAN. Wireless links are also possible. In any such implementation, communication interface 118 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information. Network link 120 typically provides data communication through one or more networks to other data devices. For example, network link 120 may provide a connection through a local network 122 to a host computer 124 or to data equipment operated by an Internet Service Provider (ISP) 126. ISP 126 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet" 128. Local network 122 and Internet 128 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 120 and through communication interface 118, which carry the digital data to and from computer 100 are exemplary forms of carrier waves transporting the information.

Computer 100 can send messages and receive data, including program code, through the network(s), network link 120 and communication interface 118. In the Internet example, a server 130 might transmit a requested code for an application program through Internet 128, ISP 126, local network 122 and communication interface 118. In accord with the invention, one such downloaded application is the system for managing requests for service of a facility described herein.

The received code may be executed by processor 104 as it is received, and/or stored in storage device 110, or other non- volatile storage for later execution. In this manner, computer 100 may obtain application code in the form of a carrier wave. The present invention is related to the use of computer system 100 to process service requests. According to one embodiment, service request processing is performed by computer system 100 in response to processor 104 executing sequences of instructions contained in memory 106. Such instructions may be read into memory 106 from another computer-readable medium, such as data storage device 110. Execution of the sequences of instructions contained in memory 106 causes processor 104 to perform the process steps that will be described hereafter. In alternative embodiments, hard- wired circuitry may be used in place of or in combination with software instructions to implement the present invention. Thus, the present invention is not limited to any specific combination of hardware circuitry and software.

SYSTEM OVERVIEW FIG. 2 provides an overview of the organization of one embodiment of a computer system that can carry out service request processing. A presentation layer 200 communicates with an external end user browser program or browser 214. Data is communicated between the presentation layer 200 and the browser 214 over a communication link 216 such as a computer network or the Internet. The browser 214 is configured to request, receive and display documents or "pages" formatted using the Hypertext Markup Language (HTML). An exemplary browser is the Hot Java browser of Sun Microsystems, Inc. The communication link 216 uses the Hypertext Transfer Protocol (HTTP) to communicate with the presentation layer 200. Thus, the presentation layer 200 can be an application program running on an HTTP server or World Wide Web server.

The presentation layer is also coupled to a middle layer 202. In one embodiment, the middle layer 202 or "middleware" comprises a sequence of computer instructions, data, and associated software structures to establish and carry out service request processing. The presentation layer comprises a sequence of computer instructions, data, and associated software structures to carry out processes related to data display, providing a graphical user interface, and receiving input from an end user. The presentation layer can be prepared in a manner specifically suited to a particular operating system and processor (or "platform"). Alternatively, the presentation layer can be configured to generate HTML documents as output and to receive input in the form of HTML documents or filled-in HTML forms. The middle layer is said to be platform-independent because its processes can be prepared and operate in a generic manner without specific reference to any particular graphic display device or input device used by the end user.

The middle layer 202 communicates with a database 206 through a database interface (DBI) 204. Preferably, the middle layer 202 is coupled to the database 206 using a finite number of connections, such as ten (10) connections. In this embodiment, when a user uses the system in the manner described below, the system reads an identification number associated with the user. The user's database sessions is assigned to the database connection matching the least significant digit of the identification number. For example, if the user's identification number ends in six (6), the system will communicate with the database using the sixth database connection. In this way, a maximum often (10) database connections are opened, providing effective database load balancing and preventing the bottlenecks of the prior art associated with excessive database connections. In a preferred embodiment, the DBI 204 is a database driver compatible with the

Java Database Connectivity (JDBC) standard of Sun Microsystems, Inc. The structure, semantics, and operation of the JDBC are described in references cited at http .//splash.j avasoft.com/j dbc/. An exemplary reference is G. Hamilton et al., "JDBC Database Access with Java: A Tutorial and Annotated Reference Manual," ISBN 0- 201-92454-4 (JavaSoft Press, Addison- Wesley, 1997). Preferably, the DBI 204 is a Jconnect JDBC driver for the Sybase® relational database system, available from Sybase Corporation, or an Intersolv JDBC driver for the Oracle® relational database system. Generally, the DBI 204 receives, formats and forwards generic database function calls to a specific database. The application programmer includes methods or function calls in the application program that read, write, or manipulate data in a database in a generic way as defined by the JDBC standard. The DBI 204 converts such generic database function calls into commands understood by a particular database. Thus, an application programmer can write a specific application program (such as middle layer 202) without having to know the specific function call requirements or data storage format and methods of the particular database 206. This enables a different database 206 and a different DBI 204 to be substituted in the system with minimal modification of the middle layer 202.

In one embodiment, the processes of the invention, including the presentation layer 200 and the middle layer 202, are implemented in the form of computer programs written in the Java language as defined by Sun Microsystems, Inc. The structure, semantics, and operation of the Java language are described in J. Gosling, "The Java Language Specification," published by Addison- Wesley Publishing Co. and Sun

Microsystems, Inc. The presentation layer 200 can be implemented in the form of a Java applet that loads into the browser 214 and is executed by the browser 214 when the browser 214 accesses the system. Communications between the presentation layer 200 and the middle layer 202 are preferably carried out using the Remote Method Invocation (RMI) functions provided in the Java Development Kit (JDK), release 1.1, available from Sun Microsystems, Inc. The JDK is a function library that contains functions that are accessible to an application programmer through a public Application Program Interface (API). Documentation about the JDK API is available from Sun Microsystems, Inc. In this embodiment, the browser 214 also must implement RMI; the HotJava browser from Sun Microsystems, Inc. is an exemplary RMI-compatible browser. The processes of the invention also can be implemented in other suitable computer programming languages, such as C, C++, and others.

As further shown in FIG. 2, a servlet 208 is coupled between middle layer 202 and database 206 and can communicate bidirectionally with each of the middle layer 202 and the database 206. The servlet is a specialized software component that is activated to carry out a specific function only when needed. Its functions are described further below.

The middle layer 202 is also coupled to a human resources database (HR DB) 210 as shown in FIG. 2. The HR DB 210 stores tables of data describing the location (e.g., building and room number), host computer name and number, personnel number, and related information for each end user of the system who might make a service request. For example, when the system is used in an industrial work environment, the HR DB 210 can store a unique user identifier (such as a unique badge number associated with that user) and an electronic mail ("email") address for each employee resident in the work environment. The data in HR DB 210 can be represented as a subset of the company's master human resources database. In one embodiment, data for the HR DB 210 is downloaded periodically from a master HR database that is maintained in a separate, secure location.

The middle layer 202 also communicates with an authentication database 212. The authentication database can be geographically remote and can be used by other application programs or systems, i.e., it is a shared resource. As described below, when a user seeks to access the system for the first time, the middle layer 202 accesses the authentication database 212 to verify the identity of the user.

In one embodiment, the database 206 is replicated at multiple geographically separated locations, and the middle layer 202 and DBI 204 contain processes and instructions for maintaining concurrency between multiple copies of the database 206. The system also has a browser registry 215 coupled to the middle layer 202.

The browser registry is a process that maintains a local table in non-volatile memory identifying the user of each browser 214 that is known to the system. Use of the browser registry 215 is discussed below.

PROCESSING SERVICE REQUESTS

STARTUP AND AUTHENTICATION

The system can be operated to process service requests using the method steps shown in FIG. 4A and FIG. 4B. The START step 402 of FIG. 4 A indicates that a user has started the system. In the following discussion, the term "user" or "regular user" generally refers to an end user of the system, such as an employee of an industrial work site. The term "FTA" refers to a facilities technical administrator, or a facilities technician, assigned to process requests made by users. The user begins by executing a browser 214, such as the HotJava browser, at step 404. When the browser 214 is running, as shown in step 406, the user enters the Uniform Resource Locator (URL) of an HTML document representing the initial page of the system. For example, the user enters the URL http://www.company.com/factool/index.html. where www.company.com refers to the company's Web server, "factool" is the name of the request processing system, and "index.html" is the name of the initial page or "home page" of the request processing system. The web server retrieves the home page from a non- volatile storage device and communicates a copy of it to the browser 214, which displays it. The initial page contains a Java applet that is configured to display a login screen and receive an employee identification number and password. As indicated by the LOGIN step 410, at this point the end user enters his identification number and password.

In step 412, the system attempts to authenticate the password of the end user. To do this, the browser login applet sends the user identification number and password to the presentation layer 200. The presentation layer 200 passes the data to the middle layer 202 by calling an authentication function call. The middle layer 202 executes the authentication function call by requesting the authentication database 212 to confirm whether the password is valid and matches the user identifier. As shown in step 413, if an affirmative response is received, i.e., the password is authenticated, then processing continues at step 414; if a negative response is received then authentication fails and control returns to step 410.

ROLE-SPECIFIC MENUS

At step 414, the system displays a top-level menu of processing choices according to the role of the end user. A role-specific user interface is generated by looking up the user identification number in the HR DB 210 and retrieving the corresponding record. The record of HR DB 210 corresponding to the current user contains a job code or a flag indicating a category to which the user belongs. According to one embodiment, HR DB 210 maps users into two categories: facilities technical administrators (FT As), and non-FTAs. Once the category of a user is determined, the system generates a user interface to present to the user based on category. According to one aspect of the invention, the user interface generated for a member of a particular group of users is customized for that group of users, and will differ from the user interface generated for a member of a different group of users. For example, users are generally restricted to using the system to make requests, are not presented with user interface controls for performing actions that they are not authorized to perform. A typical user is less familiar with the system, and therefore will appreciate a simplified user interface.

In contrast, the FT As are presented with a more sophisticated user interface that includes controls for options only authorized to FT As. FT As can use the system to review open requests or orders, update the requests as work is done, assign requests to someone else, and close a request.

When a request is closed, the system generates an email from the system to the requesting party to report that the transaction is considered closed. In one embodiment, the email contains a customer satisfaction response form. By completing and returning the customer satisfaction response form, a user can inform the system and its management about whether the request was fulfilled in a satisfactory manner. As mentioned above, certain options available to FT As are not displayed to regular users who are not FT As. For example, regular users are not permitted to assign requests, close requests, or update requests. These options are not displayed when the user accesses the system. Thus, the system enforces security rules by preventing unauthorized users from changing request data. Regular users generally can enter, view and update requests.

When the role-specific menu 416 is displayed, the middle layer 202 makes an entry in the browser table of the browser registry 215. Each browser table entry contains the login name, machine address, and browser type for the browser 214. Thus, each entry in the browser table identifies an active user of a browser by name and location. Using the registry table, the system can broadcast messages, as discussed below, to all users actively using the system. After displaying a role-specific menu, in step 416 the system waits for a user to enter a menu command, and then branches to appropriate methods, functions or subroutines to process the selected command. FIG. 5 shows an exemplary role-specific menu page 530 for users who are

FTAs. FIG. 5 through FIG. 8C, inclusive, each represent a screen shot from the HotJava browser; that is, FIG. 5 through 8C each represent web pages or computer screen displays generated by the browser 214 or applets running in it when the system is in operation. In operation, the browser 214 displays a browser window 500 that contains an upper pane 520 and the menu page 530. If the HTML code that defines the page currently displayed by the browser 214 includes a title code, then the browser will display a page title 502 in the upper pane 520. In FIG. 5, the page title 502 is "FACTOOL." The upper pane 520 also includes a command pane 504 displaying File, Edit, View, Places, and Help command keywords. When any of the keywords is selected (e.g., by directing a cursor to the keyword using a pointing device such as a mouse and clicking a button on the pointing device), the browser 214 displays a pulldown menu of available commands. Page control buttons 506 enable the user to move between previously viewed HTML pages. The file name or URL of the currently displayed page is displayed in a Place field 508. General operation of the HotJava browser is extensively documented in publications available from Sun Microsystems, Inc.

Within the menu page 530, a user information area 510 displays the identity, location, and related data of the current user. This is a portion of the information retrieved from the HR DB 210 in step 414 of FIG. 4. A menu pane 512 displays buttons labeled with functions available to the user. The menu pane 512 includes a

New Task button 513, an Update User Info button 522, a Change Password button 524, a Help button 514 and an Existing Tasks button 516. These buttons and their associated functions are available to all users. Operation of the system in connection with these functions is discussed below.

ENTERING AND PROCESSING SERVICE REQUESTS - NEW TASK BUTTON Referring now to FIG. 5 and FIG. 6, when a user selects the New Task button

513, the system initiates a process starting with step 420 of FIG. 4B. As shown in step 422, the system displays a task data window 600. The task data window 600 is used to inform the system about a new service request (also called a "task"). In step 424, the system waits for the user to fill in data in the task data window 600. The task data window 600 is a pop-up window generated by an applet running in the browser 214. The task data window 600 comprises a utility pane 602, a location pane 604, a request pane 606, and a comment pane 608.

The utility pane 602 comprises a plurality of function buttons 610, 612, 614, and 616. The Submit button 610 is used to save a new task to the database 206. When a user selects the Submit button 610, the applet that generated the task data window 600 collects all the data in the form and forwards it to the presentation layer 202. In one embodiment, the applet instantiates a data object representing a task, loads data fields of the object with the data values entered by the user, and calls a method of the object that sends a message to the presentation layer 200 indicating that the object is ready to be processed. In the preferred embodiment, the new task values in the object are copied to the database 206. The system moves to step 426 at which processing of the new task continues as discussed below.

When a user selects the Clear button 612, the system deletes any data that has been entered and displays a new blank task data window 600. When a user selects the Help button 614, the system describes a help window that contains information about how to complete and use the task data window 600. When a user selects the Dismiss button 616, the system closes the task data window and returns processing control to step 416.

The location pane 604 displays and receives information about where the service request is to be performed. Using the data retrieved from the HR DB 210, the system displays the location of the current user in the Location field 618. The system displays a Request For field 620 with two options, Self and Other. Self is the default option, and indicates that the user is requesting service for himself. The Other option, when selected, indicates that the user is requesting service for someone else. The location pane also includes a Location Of Service field 622, which has a limited set of values that are displayed in a pull-down menu. The default value is Primary Location, which represents the primary location where the requesting user works or is located as displayed in the Location field 618. Secondary locations can be defined in the HR DB 210 and selected by pulling down the pull-down menu and clicking on the Secondary Location value. For example, a user may be a scientist who works in an office (her primary location) as well as a laboratory (her secondary location). The user may also enter a priority code for the task in a Priority field 624. The

Priority field accepts one of a limited set of values displayed in a pull-down menu. For example, there can be three priority levels, Crisis, Urgent, and Standard. To indicate the importance of the new request, the user pulls down the Priority menu and selects the appropriate value. Each Priority value is associated with a separate numeric value representing the number of minutes, hours or days that are expected to be required to resolve or complete a service request at the associated priority level. For example, the Standard priority level may be associated with a resolution time of three to five days. The resolution time values are stored as constant values in the middle layer 202 in association with the Priority values. The resolution time values are used as reference values to enable the system to compute performance data and generate management reports, as discussed below.

The request pane 606 accepts and displays information relating to the service requested. A Request field 626 accepts and displays a description of the request organized in a set of successively more specific sub-categories. The sub-categories are selected using a pull-down menu 628. When a user is entering a new request, as shown in FIG. 6, the system displays the Request field 626 as blank and displays a top-level list of request categories as the pull-down menu 628. When a user selects one of the top-level categories, the system displays the selected item in the Request field 626, and then displays a list of secondary categories as the pull-down menu 628. For example, a user selects "Environmental, Health & Safety" from the top-level category list shown in pull-down menu 628 of FIG. 6. The system displayes that selection in the Request field 626 and displays secondary categories relating to that selection in the pull-down menu 628, namely Circulation; Odor; Temperature—Common Area, Temperature—Lab, Server, Phone; and Temperature—Office. The system will re-display the top-level categories if the user presses the Up One Level button 632. In a preferred embodiment, the pull-down menu of secondary categories also has an Other field in which the user can type any desired request description.

The request pane 606 also includes a Top Level button 630. If the user clicks the button 630, the system returns control to step 414 and displays the user's role- specific menu. The user may enter comments concerning the request in a Comment field 640 of the comment pane 608. The Comment field 640 is a free-form text field that accepts any alphanumeric typed data.

When the user has filled in these fields and completed making desired button selections, to save the new request to the database, the user clicks on the Submit button 610. In response, the values entered for the new record are assembled and saved as a new record in the database 206. The system then passes control to step 426 of FIG. 5.

In step 426, the system assembles the entered data in an instance of a request object. Step 426 involves several sub-steps. A sequential request number or Task ID is assigned to the request. The request number serves as an index or key to the request in the database. A Status code is assigned to the request. Valid status codes are PENDING, IN-PROGRESS, CANCELED and CLOSED. The PENDING code identifies a request that has been entered but not yet assigned to a technician. IN- PROGRESS identifies a request that has been assigned to a technician but is not yet complete. CANCELED identifies a request that has been discontinued by the user who originally entered the request. CLOSED identifies a request that has been fulfilled by a service technician.

The system assigns the request to a default technician. An FTA Table 207 is coupled to the middle layer 202. In one embodiment, the FTA Table 207 stores a mapping of technicians or FT As to buildings of the user's facility and to categories of requests. Thus, the system can consult the FTA Table 207 to determine which FTA has responsibility for requests of a particular category that originate from a particular building. For example, the FTA Table 207 has an entry comprising the tuple (John Smith, <jsmith@ebay>, "Heat, Vent & AC", MIL07). This entry indicates that the FTA named John Smith is responsible for servicing requests relating to heating, ventilation and air conditioning originating from users in building MIL07. When a new request is created, the system looks up the building of the user and the request category in the FTA Table 207 and reads the name and email address of the FTA associated in the FTA Table 207 with that building and request category. The FTA's name is written in the Assigned To field of the request record.

The system creates a log field and attaches it to the request data. The log field is a variable- length text field that contains comments about the progress of the request. For example, the log field indicates each action taken concerning a request, when the action occurred, and who took the action. By viewing the log field (as described below), a manager or technician can read the complete history of the request. In step 428, through the middle layer 202, the system requests the DBI 204 to write the assembled request object to the database 206. This causes the database to store a record of the new service request.

In the preferred embodiment, the system is configured to cooperate with an electronic mail (email) system 218. The user of the service request processing system is expected to have a personal mailbox in the email system 218 that is addressable through an email address stored in the HR DB 210. In step 430, the system generates an email message to confirm that the new request has been successfully received by the system and entered in the database 206. The text of an exemplary confirming email is shown in Table 1 :

Table 1 — Confirming Email

From FacilirvStafft ).factool Thu Apr 24 07:29:12 1997 Date: Thu, 24 Apr 1997 07:30:00 -0700

Subject: NEW factool Task 55281 Status: Submit, Priority: 2 From: FacilityStaff(g).factool

• If you need to communicate with the facility staff, • Please do not directly respond to this email using

• the email system. Please use the New Info/Update

• feature within factool.

Contact Information:

Name: ROLANDO DIMAANDAL

Address: rollv.dimaandal(α),companv.com

Location: MIL07-9999

Ext: 99745

Dept: 02922025

Mailstop: UMIL07-127

Request: Heat, Vent & AC/Temperature— Office Priority: 2 ACTION TAKEN BY: ROLANDO DIMAANDAL

ACTION TAKEN: New Task Submitted ORIGINAL TEXT:

Please lower the temperature in my room. It's too hot.

As shown in Table 1, the confirming email summarizes the request so that the initiating user can confirm that the new request has been entered accurately. The information listed after the headings "Action Taken By:", "Action Taken:", and "Original Text:" is included in the Log field. The email also indicates the sequential request number that has been assigned to the request. In the example above, the request number is 55281. The email also reminds the user to use the service request system to enter new or supplementary information about the request. This process is discussed below.

The system also checks whether the user who originated the service request is still entered in the browser registry 215. If so, the system forwards a copy of the confirming email to the browser 214 of that registered user. This step tends to increase the likelihood that the user actually will see the confirming email.

In addition, the system checks whether the FTA or manager named in the Assigned To field of the new request is currently known to the browser registry 215. If so, then a copy of the new request is sent to the browser 214 of that FTA. The applet running in the browser receives such incoming new service request. The applet tests whether a Task Monitor window 790, as shown in FIG. 7D, is currently being displayed. If not, a Task Monitor window 790 is opened in the display of the FTA's host computer. The Task Monitor window 790 has a Task List 798 that provides a scrolling, real-time listing of all tasks assigned to the current FTA upon which another person has recently acted. The applet displays a row representing the new request in the Task List pane 718 of the Existing Tasks window 700. Thus, by keeping the Task Monitor window 790 open, an FTA can receive and see new service requests on a realtime basis. If the assigned FTA is not using a browser 214 that is registered with the browser registry 215, new request records remain in the database 206.

In the preferred embodiment, the Priority value of each task 799 in the Task List 798 is displayed in a color coded to the importance of the priority value. For example, Priority 1 is red, Priority 2 is orange, 3 is yellow, and 4 is blue.

The FTA can remove a task from the Task List 798 by clicking on one of the tasks 799 listed in the Task List 798 and then clicking on the Remove From List button 792. In response, the system deletes the designated task 799 from the Task List 798, but the task is not deleted from the database 206. Thus, the Task List 798 serves as a temporary display of tasks for which some action was recently taken. It is updated whenever a task is modified by any user, provided that the FTA to whom the task is assigned is currently displaying the Task List window 700.

The Task List 798 can be printed by clicking on the Print button 794. The Task List window 700 can be closed by clicking on the Dismiss button 796. When a user double-clicks on a task 799 in the Task List 798, the system displays the Task Information window 750 of FIG. 7B. Then task information can be modified using that window in the manner discussed below in connection with FIG. 7B.

DISPLAYING AND WORKING WITH EXISTING TASKS; ADMINISTRATIVE FUNCTIONS

After a new request is entered into the database, as shown in step 432, a user may optionally carry out administrative functions using the system. For example, to display, update, or delete tasks previously entered, a user may click on the Existing Tasks button 516 shown in FIG. 5. In response, the system displays an Existing Tasks window 700 as shown in FIG. 7 A. In one embodiment, in response to a click on the Existing Tasks button 516, the middle layer 202 forwards an HTML page containing an Existing Tasks applet to the presentation layer 200. The presentation layer communicates that page to the browser 214. When the browser displays the applet, it executes in the browser and generates Existing Tasks window 700. The Existing Tasks window 700 has a function select pane 702 that contains buttons representing function that can be carried out by the system when the Existing Tasks window 700 is active. An Apply button 704, Delete button 706, and Change Query Name button 708, and their associated functions, are available only to management users. The exemplary window shown in FIG. 7A represents an Existing Tasks window displayed to an ordinary user who does not have management privileges. Therefore, FIG. 7A shows the buttons 704, 706, 708 as displayed in half-intensity to indicate to the user that their functions are unavailable. These functions are discussed below.

In the Existing Tasks window 700 the system also displays the Task ID for a service request or task in the Task ID field 714, and the employee identifier or badge number of the user in the ID field 716. A Task List pane 718 displays a list of previously entered service request or task records, organized as a scrolling table of rows. Each row has a value in a Task ID column 720, a Request column 722, a Status column 724, and other columns. The columns correspond to fields of in records of the database 206 for each service request.

To search for an existing task record by its request number or Task ID number, a user may type the Task ID in the Task ID field 714 and press the ENTER key. In response, the system searches the database 206 for a record with a key or request number matching the specified Task ID number. If a matching record is found, the system constructs a row for the Task List pane 718 and displays the row in the pane. A user may also locate a service request in the database by moving through the records displayed in the Task list pane 718 by clicking on a vertical scroll bar 726 adjacent to the pane.

The Print button 710 and Dismiss button 712 are available to every user, as shown in FIG. 7 A. To use the Print button 710, the user first selects a row in the Task List pane 718 by clicking on it within the pane. In response, the system highlights the row, to indicate that the associated service request record is selected. When the user presses or clicks on the Print button 710, in response, the system will format and print a copy of the data in the service request record on a printer attached to the user's host computer or associated with the user's account.

The Dismiss button 712 is used to discontinue working in any currently active window. If a user clicks the Dismiss button 712, in response the system will close the currently active window and continue processing at the previous function.

If a user points the user's mouse to a row of the Task List pane 718 and doubleclicks the user's mouse, the system interprets such action as a request to view the indicated service request record in detail. In response, using an applet communicated from the middle layer 202 to the presentation layer 200 and to the browser 214, the system displays a Task Information window 750 as shown in FIG. 7B. The Task Information window 750 has a control pane 730, an information pane 740, a Log pane 742, and a Comment pane 744.

In the information pane 740, the system displays information stored in the database 206 pertaining to the selected service request, including the Task ID, information about the user who requested it, and its status. The information pane 740 also indicates the name of the FTA to whom the task is assigned, the type of request, the priority code and the name of a person to whom a copy ("Cc") of the request should be sent. Adjacent to each of the Assigned, Request, Priority, and Cc fields is a Change button 746a, 746b, 746c, and 746d. When a Change button is displayed in full intensity, it is available to the user, and the user can press the Change button to change the information adjacent to it. In the example shown in FIG. 7B, the user is not an FTA or manager. Such regular users are not permitted to change the FTA Assigned information or the Request information. Therefore, the Change buttons 746a, 746b are shown in half intensity because they represent unavailable functions. Regular users may change the Priority and Cc of a previously entered service request. Therefore, the Change buttons 746c, 746d adjacent to the Priority and Cc fields are displayed in full intensity.

When one of the Change buttons is pressed, the system displays a pop-up window showing the information currently entered in the field corresponding to the Change button. The user may enter new information. When the user presses ENTER, the new information is placed in the database record for the selected service request, and the Task Information window is updated and re-displayed.

The control pane 730 contains buttons that a user can press or click on to select functions that manipulate the display and the selected service request record. The control pane has Print and Dismiss buttons that operate in the same manner as discussed above with reference to Figure 7A. All users have access to the Update button 732 and the Cancel Task button 738. Only FT As or managers have access to the Close Task button 734 and the Reopen Task button 736.

After an existing task has been modified using the Change buttons, the modified data is saved to the database using the Update button 732. When a user points to the Update button 732 and clicks on it, in response, the system displays a dialog box that prompts the user to confirm the update. In the dialog box, the user is given the option to approve the update by clicking on "OK" or cancel the update by pressing "CANCEL". If the user clicks on "OK", the updated record is saved in the database 206.

A user presses the Cancel Task button 738 to cancel a previously entered task. The Cancel Task button 738 can be used only by a user having the same identifier as the user who originally created the service request. When a user presses or clicks on the Cancel Task button 738, the system checks the database 206 to test whether the user's identifier matches the identifier of the user who created the service request. If the identifiers match, the system will change the Status field of the service request record to CANCELED and save the record in the database. If there is no match, no further action is taken and the record remains unchanged. CLOSING A TASK If a FTA or manager user selects the Close Task button 734, then in response, as shown in step 436 of FIG. 4B, the system takes actions to close the service request. The Status value of the current service request must be PENDING or IN-PROGRESS. If it is, then the system displays a Task Close Information window 760 as shown in FIG. 7C. The purpose of the Task Close Information window 760 is to require the FTA or manager to state how a task was completed, how long it took, and when it was closed. This information is valuable to management because it can be used in personnel performance reviews and cost estimation. The Task Close Information window 760 has a Resolution pane 762 that displays the request type and how it was resolved. The request type of the current service request record is displayed in a request type field 764. A list of resolution choices 766 is displayed adjacent to the request type field 764. The list of resolution choices is context-sensitive, i.e., the particular list that is displayed depends on the request type. In the example shown in FIG. 7C, only one choice is available. To select it, the user points to it with a mouse or other pointing device. The resolution choice is then appended to the request type field and displayed in it. The user may navigate among multiple resolution choice lists and request types by pressing the UP One Level button 768. The Task Close Information window 760 also has a Labor Hour pane 770 with

Minute, Hour, and Day fields. Each of the Minute, Hour, and Day fields is a pull-down menu. The FTA user or manager selects an appropriate choice to identify the amount of time actually required by a field technician to resolve the request. The system formats the values entered and stores them in the database as part of the request record. The Task Close Information window 760 also has a Finish Date pane 780 with Date and Time fields. The Finish Date pane 780 is used to indicate the date and time at which the service request was fulfilled. The system loads the Date and Time fields with the current system time stored in the user's host computer, as default values. The user may change these values if desired. When correct values are entered, the user presses the OK button 782. The Date, Time, Minute, Hour, and Day values are then formatted and stored in the database as part of the request record. The system then changes the Status value of the current service request record to CLOSED, and saves the record in the database 206.

As shown in step 438, the system then generates an email to the user who originally submitted the request to inform the user that the request has been closed, i.e., no further physical action or human action will be taken in response to the request. The confirming email 220 is shown in FIG. 3. The confirming email may be similar in form to that shown in Table 2:

Table 2 - Closing Email

From FacilitvStaff( ).factool Thu Apr 24 07:59:12 1997 Date: Thu, 24 Apr 1997 07:30:00 -0700 Subject: NEW factool Task 55281 Status: Closed, Priority: 2 From: FacϋitvStaff(g).factool

• the email system. Please use the New Info/Update

• feature within factool.

Contact Information:

Name: ROLANDO DIMAANDAL

Address: rollv.dimaandal( ).companv.com

Location: MIL07-9999

Ext: 99745

Dept: 02922025

Mailstop: UMIL07-127

Request: Heat, Vent & AC/Temperature-Office Priority: 2

ACTIONTAKENBY: ROLANDO DIMAANDAL

ACTION TAKEN: Task Closed

ORIGINAL TEXT:

Please lower the temperature in my room. It's too hot.

Response:

A facilities technician has adjusted your temperature. This request is considered closed.

NOTE Double click the attachment to fill up evaluation form.

Your comments are of great importance to us.

Thanks for using Factool.

In this example, <attachment> represents a Customer Satisfaction file attached to the email. In one embodiment, as shown in FIG. 3, the Customer Satisfaction file 224 is an HTML page that contains a form in which a user may report comments about how the service request was handled. Preferably, the Customer Satisfaction file is written by the system based upon an HTML template that contains form graphics and questions. The HTML template preferably contains:

1. A label, such as "Customer Response Form" 2. A question to the user, such as "How satisfied were you with your recent request for facilities services in terms of the quality of the service provided, timeliness of the response, and resolution of the problem?"

3. Options for responding to the question, such as Highly Satisfied, Satisfied, Dissatisfied, Highly Dissatisfied

4. A Comment field in which the user may type any desired comments

5. A Submit button 226 that causes the completed form to be submitted for processing

The system copies the HTML template to an HTML file or HTML page 224. The system appends the user's name and the Task ID of the closed task to the file and then attaches the file to the confirmation email 220. The HTML page 224 is represented in the confirmation email 220 by an HTML icon 222. In the preferred embodiment, to complete and submit a customer satisfaction report, the user double-clicks on the HTML icon 222 in the confirmation email. This causes an operating system running on the computer system 100 to deliver a copy of the HTML page 224 to the browser 214. The browser displays the HTML page 224. The user fills in the fields of the HTML page and clicks on the Submit button 226. The completed form is sent from the browser to the presentation layer 200 to the middle layer 202. The middle layer prepares an abstract of the data supplied by the user, places such data in an email, and sends an email to the system administrator or a designated manager. The data is also stored, in non- volatile storage, in a customer satisfaction database for use in management reports. Through these steps, management of the service request system is informed about the views of users who are requesting and receiving services.

If the user who originated the task is entered in the browser registry 215 when the confirming email of Table 2 is constructed, the system sends a copy of the email to the browser 214 of that user.

RE-OPENING A TASK

If an FTA or manager user selects the Reopen Task button 736, and the Status value of the current service request record is CLOSED, then the system will change the Status value of the current service request record to PENDING and save the record in the database. The system then redisplays the request in the information pane 740 so that the user can review the changed status.

Whenever a record is modified using the Update button 732, Cancel Task button 738, Close Task button 734, or Reopen Task button 736, the system creates a new text entry in the Log field of the record. The text entry indicates the action taken, who took it, and when it was taken, in the format shown in the Log pane 742 of the Task Information window 750 of FIG. 7B. QUERIES ABOUT TASKS

The invention provides a powerful and flexible way to retrieve records of service requests from the database 206 using queries based upon fields of the service request records. A "query" is a request that the system retrieve records based upon specified criteria or fields.

In one embodiment, the query feature is accessed when a user who is an FTA clicks on the Existing Tasks button 516 of the main window 500. In response, the middle layer 202 forwards a query applet to the presentation layer 200 and causes the presentation layer 200 to send an HTML page containing the applet to the browser 214. The applet executes in the browser 214. The query applet tests whether the current user is an FTA. If so, the query applet displays the Query Task window 800 of FIG. 8 A. Since the query feature is available only to FT As and management users, if the current user is not an FTA, then the applet displays the Task Window of FIG. 7 A.

The following discussion that the current user is an FTA. The Query window 800 has a format similar to that of the Existing Tasks window 700 shown in FIG. 7A. Upper panes of the Query window 800 display an Apply button 704, Print button 710, and Dismiss button 712 that operate in the same manner as discussed herein in connection with FIG. 7A.

The function select pane 702 of the Query window 800 also has a Define New Query button 708a, an Existing Query button 708b, a Change Query Name button 708c, and a Delete Query button 708d. Each of the buttons 708a to 708d is associated with a processing function of the applet.

If the user clicks on the Define New Query button 708a, in response the applet displays a Query Name window that prompts the user to enter the name of the query to be constructed. After the user enters a name, the applet creates a new record in a table of queries in the database, indexed by the name. The user may then enter information to define the query as described below.

If the user presses the Existing Query button 708b, the applet searches a table of existing queries in the database to determine whether the query name matches an existing query. Preferably the database table is also indexed by the FTA's identification number, so that the applet can query the table based upon the identification number of the FTA who is currently logged in. The applet then displays a table in a pull-down menu showing each previously defined query associated with the current FTA user. The applet then waits for the user to select one of the previously defined queries by double- clicking on it. When a query is selected, the applet then displays the Query window 800 shown in FIG. 8A. When a user presses or clicks on the Change Query Name button 708c, the system displays a dialog box that prompts the user to enter a new name for the current query. The system then waits for the user to type a valid query name. When the user presses the Enter key, the system checks the name to determine that it is valid, i.e., that it is a string of alphanumeric characters. If the query name is valid, the system changes the name in the database table of the current query to the name entered by the user.

The Delete Query button 708d is used to delete a query from the system. When a user presses or clicks on the Delete Query button 708d, the system displays a dialog box that prompts the user to confirm that the current query is to be deleted. If the user enters an affirmative response, the system deletes the current query from memory.

The Apply button 704 is used to execute a completed query, and is discussed further in a section below.

The Query window 800 has a query function selection pane 802 that has a Task List button 804 and a Field button 806. If a user presses the Task List button 804, the system displays the Existing Tasks window 700 of FIG. 7 A and carries out the processing steps discussed above with respect to FIG. 7 A. This enables a user to rapidly jump from a list of existing tasks to the query screen shown in FIG. 8A.

If a user presses the Field button 806, the system displays a Field pane 810 as shown in FIG. 8 A. The Field pane 810 and its associated processes enable a user to select fields to be included in a query, and the sort order for the fields. The Field pane 810 has a pull-down menu 812 that provides a list of commonly used combinations of fields. When a user clicks on the pull-down menu 812, the system displays a list of predefined selection items in the Field pane 810. Each of the pre-defined selection items represents a combination of fields that can form a query. For example, in the screen shown in FIG. 8 A, one pre-defined selection item is shown, namely, "Commonly Used Selections." The fields that form the pre-defined selection item are listed in a Selection list 814. Thus, by choosing the Commonly Used Selections item, the user can rapidly build a query that comprises the TASK ID, REQUEST, STATUS, PRIORITY, BLDG, SUBMIT DATE, and ASSIGNED TO fields of a service request. The Field pane 810 also has a sort order panel 818. The sort order panel 818 is a table of rows. Each row corresponds to a field in a query of service request records. Each row comprises a selection lamp 817, a field name 816, an Ascending order selector 820, and a Descending order selector 822. To include a particular field in a query, that is, to set up a database query that will select records containing a particular field, the user clicks on the selection lamp 817 associated with the desired field. In response, the system adds the chosen field to the query, and illuminates the selection lamp 817 of that field. The user may click on either the Ascending order selector 820 or the Descending order selector 822 to instruct the system to sort the records found by the query such that the chosen field is shown in either ascending or descending order, respectively.

A user may limit the query to records having fields matching a particular value by clicking on the Site button 808a, the Status button 808b, the Date button 808c, the Priority button 808d, the Bldg button 808e, the Assigned To button 808f, or the Request button 808g. For example, to specify that a query should retrieve records of requests for service at a particular company site, a user may click on the Site button 808a. In response, the system displays a Site pane 830 as shown in FIG. 8B. The Site pane has a site list window 832 that lists sites at which requests for service may be fulfilled. For example, if the system is at use in a company or institution that has multiple campuses, buildings or geographic locations, each item in the site list window 832 can be a campus name, city name, or building. In the example of FIG. 8B, the site list window 832 contains a list of campus locations 834, namely "EBAY," "MPK," and "WBAY." To select one of the locations 834 as a limitation on the current query, the user double-clicks on a selected location 834. In response, the system adds the location 834 to the current query for later use when the query is executed.

Similarly, a user may limit the query to records of service requests assigned to a particular FTA by clicking on the Assigned To button 808f. As shown in FIG. 8C, in response to this command, the system displays an Assigned To pane 840 in the Query window 800. The Assigned To pane 840 has a list 842 of FT As or other personnel to whom a service request may be assigned. A user may double-click on a specified person's name, such as the highlighted name 844 shown in FIG. 8C. The system then adds the selected name to the current query for later use when the query is executed. In the same manner, the query may be limited according to request status, request date, priority, building, or request type, by selecting one of the buttons 808b, 808c, 808d, 808e, and 808g respectively. In response, the system displays a pane of valid selections. The user double-clicks on the desired selection, and it is added to the current query. Each successive selection limits the query in the manner of a boolean AND operation; for a record to be selected from the database against the query, all the specified values must be present in the record. Whenever a query is changed, the system automatically saves the completed query under the query name shown in the title bar 801 of the Query window 800.

When a query is complete, to execute the query against the database 206 and display the results, the user clicks on the Apply button 704. The middle layer 202 formats the current query into a format understood by the database 206, for example, as a statement in the Structured Query Language (SQL). The middle layer then passes the SQL statement to the DBI 204 with a request to query the database using the SQL statement. The DBI reformats the request as necessary for the particular database 206 then in use, and passes the request to the database 206. The database 206 conducts a search according to the designated query and responds with any data records that match. The matching records are passed back to the middle layer 202 through the DBI 204. The middle layer 202 formats each matching record and forwards the formatted, matching records to the presentation layer 200 along with an applet for use in presenting the records with the browser 214. The presentation layer passes the applet to the browser 214, which executes that applet. The applet displays a Task List pane 850 in the Query window 800 as shown in FIG. 8D. The Task List pane contains a table of the matching records. There is one row per record. Columns of the table correspond to fields of the matching records. For example, the table includes a Task ID column 852 and a Request column 854. Other columns can be displayed by operating the horizontal scroll bar 856 of the table. Records in the table are displayed in the order specified by the query. A user may view details of any record in the Task List pane 850 by double clicking on a row of the table. This causes the system to display the Task Information window 750 of FIG. 7B.

UPDATE USER INFO FUNCTION

When a user clicks on the Update User Info button 522, in response the system displays the Update User Info window 900 shown in FIG. 9. The Update User Info window 900 displays a list 902 of information relating to the user that is stored in the HR DB 210. To maintain database consistency between the HR DB 210 and the master human resources database, users are not permitted to modify data displayed in the list 902 except for room location. The user's room location is displayed in a Room line 904 of the list 902. To modify the user's room location value, the user may enter a new value in the location text field 906.

To update the database 206 with the new value, the Apply button 908 is pressed. In response, the system copies the new value to the database. When the Cancel button 910 is pressed, the Update User Info window 900 closes. CHANGE PASSWORD FUNCTION

When the Change Password button 524 shown in FIG. 5 is pressed, the system displays a pop-up menu that shows the user's current password. The pop-up menu includes a text entry field that accepts a new password, and Apply, Reset, and Dismiss function buttons. When the Apply button is pressed, the new password is copied to the HR DB 210 and to the database 206 in association with the user's identification information. When the Reset button is pressed, the text entry field is cleared. When the Dismiss button is pressed, the pop-up menu closes. MANAGEMENT REPORTS

The middle layer 202 includes processes that generate reports of the data in the database 206 for use by management in evaluating the performance of the FT As and the system generally. For each report type, the system stores a pre-defined database query and a pre-defined report printing template. The system generates a report by applying the pre-determined query to the database 206 through DBI 204, formatting the records provided by the database 206 in response to the query according to the printing template, and printing the records at a printer connected to the user's terminal or computer. The following reports are available in one embodiment:

1. Customer satisfaction detail report — this report displays each response provided by a user in reply to the customer satisfaction form provided by the system in the confirming email when a task is closed.

2. Customer satisfaction summary report — this report displays a summary of a set of responses provided by users in reply to the customer satisfaction form provided by the system in the confirming email when a task is closed.

3. Delinquency report — this report displays a list of service request records that have not been closed within the time prescribed by their Priority.

4. Time to Close Summary report — this report displays a summary of the actual time taken to close all past requests of a given priority.

5. Work Order Completions report — this report displays a summary of the total number of requests for which processing has been completed.

6. Work Order Volume report ~ this report displays a summary of the total work time used to complete a set of requests. 7. Backlogs report — this report displays a list of currently pending requests.

The system described herein offers numerous important advantages. It uses a convenient windowed computer environment that is readily understandable to users. In one embodiment, it is platform-independent in the sense that the same middleware and database can be used to communicate to a front end implemented in a variety of different graphical user interfaces. It does not interfere with the user's host machine, e.g., it does not attempt to write files on the host. FT As or management may make an unlimited number of database queries. The system establishes a limited number of connections to the database 206 using a tiered architecture, reducing the consumption of memory and other resources that are required to maintain multiple database connections. A database query can be set up rapidly using a single window. The system can detect newly entered request records and automatically update the display so that the new records are visible to a FTA whenever the FTA's browser is operating. This encourages FT As to rely on the system's display, rather than email, as a primary means of alerting FT As to new requests. It enables FT As or management to monitor incoming service requests in real time.

In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims

What is claimed is: 1. A system for managing requests for service of a facility, comprising: a monitor window displayed on a display device; a network connecting said display device to a processor; and a memory coupled to said processor and having stored therein: a database of service requests; processor instructions coupled to said database and configured to cause said processor to: enter said service requests in said database; and display said service requests in said monitor window over said network when said service requests are entered into said database.

2. The system recited in claim 1, further comprising: a browser coupled to said display device; a browser registry coupled to said browser and comprising a table of said display devices that are activated; and wherein said processor instructions are configured to cause said processor to store a description of said browser in said browser registry.

3. The system recited in claim 2, wherein said processor instructions are configured to cause said processor to generate an electronic mail message to said browser when a new service request is stored in said database.

4. The system recited in claim 3, wherein said new service request comprises an Assigned To value identifying a host of a service person assigned to carry out said new service request, and wherein said instructions are configured to: store said new request in said database; and generate a second electronic mail message to said host when said new service request is stored in said database.

5. The system of claim 1, wherein said memory further comprises a database interface coupled between said database and said processor, wherein said database interface is configured to translate a database request of said processor into a database command compatible with said database.

6. The system recited in claim 4, further comprising: a servlet coupled between said database and said processor; wherein said instructions are configured to cause said servlet to communicate said second electronic mail message to said display device.

7. The system recited in claim 5, wherein said instructions are configured to: close said new service request; generate an evaluation message; and deliver said evaluation message to said display device.

8. The system recited in claim 2, wherein said instructions are configured to: enter a new service request in said database; display said new service request in said monitor window when said new service request is entered in said database and when a technician assigned to said new service request is using said display device that is registered in said browser registry.

9. A method of managing requests for service of a facility, comprising the steps of: entering said service requests in a database; and displaying said service requests in a monitor window over a network when said service requests are entered into said database.

10. The method recited in claim 9, further comprising the steps of: registering, in a browser registry coupled to a browser that is coupled to a display device and to said network, a description of said browser.

11. The method recited in claim 10, further comprising the steps of: generating an electronic mail message to said browser when a new service request is stored in said database.

12. The method recited in claim 10, further comprising the steps of: storing an Assigned To value identifying a host of a service person assigned to carry out said new service request; storing said new service request in said database; and generating a second electronic mail message to said host when said new service request is stored in said database.

13. The method recited in claim 9, further comprising the steps of: providing an element to establish a database interface coupled between said database and a processor; and translating, using said database interface, a database request of said processor into a database command compatible with said database.

14. The method recited in claim 11 , further comprising the step of: providing an element to establish a servlet coupled between said database and a processor; and communicating, using said servlet, said second electronic mail message to said display device.

15. The method recited in claim 12, further comprising the steps of: closing said new service request; generating an evaluation message; and delivering said evaluation message to said display device.

16. The method recited in claim 10, further comprising the step of: entering a new service request in said database; displaying said new service request in said monitor window when said new service request is entered in said database and when a technician assigned to said new service request is using said display device that is registered in said browser registry.

17. A computer readable medium having stored thereon sequences of instructions for managing requests for service of a facility, the sequences of instructions comprising instructions for performing the steps of: entering said service requests in a database; and displaying said service requests in a monitor window over a network when said service requests are entered into said database.

18. The computer readable medium recited in claim 17, further comprising instructions that establish a browser registry coupled to a browser coupled to a display device and comprising a table of display devices that are activated, and that store a description of said browser in said browser registry.

19. The computer readable medium recited in claim 18, further comprising instructions that enter a new service request in said database, and display said new service request in said monitor window when said new service request is entered in said database and when a technician assigned to said new service request is using said display device that is registered in said browser registry.