WO1991001022A1 - Interaction network system with electronic organizational actors - Google Patents

Abstract

A network system coordinates interactions among users by employing an independently operable action module (40) programmed to receive, generate, and send communications according to a structured interaction program, and an interface (41) for selectively configuring and modifying the interaction program. Such action modules (40) are used as electronic organizational actors (EOAs) of an electronic labor force for the network system. The EOAs are used to improve the productivity and efficiency of the organization by reducing or eliminating repetitive or tedious functions that need not be performed by human beings. One application for the EOAs is managing structured conversations among users and groups in the organization. The interaction parameters of the EOAs can be modified without having to reconfigure the entire network system.

Description

INTERACTION NETWORK SYSTEM WITH ELECTRONIC ORGANIZATIONAL ACTORS

FIELD OF THE INVENTION

This invention generally relates to network systems, and more particularly, to a network system in which the flow of communications is structured by a program of defined interactions among users of the network.

BACKGROUND ART

The information industry has developed various forms of network systems for providing an information flow among multiple users. In file server systems, users operating on stand-alone computers are connected through a local area network to a file server computer which controls the transmission of data among the users of the system. In host systems, multiple users on respective terminals are connected by a local area network with a host computer which runs applications programs for the network. A local area network (LAN) or stand-alone computers may be connected by data transmission facilities to other networks in a wide area network (WAN). Electronic mail systems are used to receive, store and distribute electronic messages for and among users of the system.

Recent developments in network systems have offered the capability of not only connecting but also coordinating the actions of the users of a network system on an organization-wide basis. Called "coordination systems," these are designed to help the users coordinate their work with one another by managing the flow of electronic messages among users in the organization. One such coordination system is implemented in the Coordinator^R System offered by Action Technologies, Inc., of Emeryville, California. Its design was based on the research work of Dr. Carlos Fernando Flores, as described in his doctoral dissertation entitled "Management and Communications in the Office of the Future," University of California at Berkely, 1976, and in "Understanding Computers and Cognition," by Terry Winograd and Dr. Flores, published bay Ablex Press, 1986.

The Coordinator" System is operated at its base level through a Conversation Manager™ program on a users* stand-alone computer or network file server to which the user has access. The user designates certain types of information (messages), i.e., Note, Inform, Question, Offer, Request, Promise, What If, etc., for conversations with other users connected to the network through their computers. The Conversation Manager™ program automatically processes the user's messages, as well as messages from other user, for storage, organization (linkage), distribution, and/or recall. The transmission and reception of messages to and from other users is handled by an integrated, resident communications program called Message Handling System (MHS) . MHS has also been used as a standard communications interface in other network systems.

A related development was the design of programmed environments to integrate the specific roles and activities of people working on a common organizational purpose. For example, a corporation may have personnel in different locations working on the same project which requires integration of their respective work products. Programmed integration of the activities of workers is discussed, for example, in an article entitled "Coordination System Technology," by A.W. Holt, H.R. Ramsey and J.D. Grimes, ITT Programming Technology and Development Center, published in Electrical Communication, Volume 57, No. 4 (1983). The article discusses coordination management of work products according to programmed interaction rules.

The above-described Coordinator^R System can increase the effectiveness of exchanges of communications between users and enhance their productivity by organizing, monitoring and managing the handling of messages through the Conversation Manager™ program. However, it lacks the capability to coordinate the specific actions of people corresponding to their particular activities and functions in the organization. On the other hand, the ITT coordination system concept provides for coordinating actions according to programmed rule structures based upon the defined roles or activities of personnel. However, such rule structures are programmed into the network and linearly define the interactions that are to take place between people in rigid sequence, and therefore provide little flexibility for modification of or for unstructured interactions between people. Inflexibility in the interactions between people can stifle the creativity and effectiveness with which an organization carries out its purpose. SUMMARY OF THE INVENTION

It is therefore a principal object of the invention to provide a network system which coordinates the actions of its users through a system architecture which has the flexibility to freely define and modify interactions among users without having to rigidly structure or reprogram the entire network. A fundamental type of interaction to be carried out in the network system is the providing of a communication from a user and the generation of an appropriate response to that user or other users in order to coordinate the actions of the users of the system. It is therefore also a specific object of the invention to allow the parameters of communication-response interactions to be freely defined and modified.

It is also a fundamental purpose of the invention to provide a network system in which one or more structures for such defined interactions can be freely programmed and modified as adjunct entities in the network system. It is intended that a plurality of such interaction structures can serve as an electronic labor force to enhance the performance and efficiency of work functions in an organization.

In accordance with the invention, one or more electronic organizational actors (EOAs) of an electronic labor force are set up as separately operable, adjunct programmed entities in a network system. The EOAs are used to automatically perform defined interaction functions with users and groups which are known and established in the organization, and a preferred application of an EOA is for managing structured conversations among users and groups in the organization. A central feature of the invention is the ability to configure and modify the structured interactions of the EOAs through an administrator interface without having to reconfigure or reprogram the entire network system.

One implementation of the network system of the invention, which coordinates interactions among a plurality of users of the system, comprises: a communications network for transmitting communications among users of the system; a plurality of user stations connected to said communications network for allowing respective users to send and receive communications via said communications network; an action module connected to said communications network and independently operable thereon which is programmed to receive, generate and send communications among said user stations in accordance with a structured interaction program containing a plurality of defined interaction descriptions, wherein said communications are categorized according to a plurality of defined communication types, and wherein each of said interaction descriptions controls receiving of a communication of a defined communication type and automatic generation and sending of a defined response based thereon; and action program configuring means, including an interface to said action module, for selectively configuring and modifying said interaction descriptions of said interaction program in order to selectively define the corresponding communication-response interactions.

In a preferred embodiment of the invention, the action module has an associated data storage ("data warehouse") for storing and retrieving information sent by or to be sent to various users of the system. Different interaction descriptions provide for automatically: (1) sending a user a report upon receipt of a report request; (2) sending a follow-up communication if a report or response from a user is missing; (3) sending a response to a user based upon the form of a received communication; and (4) initiating a conversation with a user based upon a calendared date, triggering event, or exception condition.

The administrator interface of the preferred embodiment allows an administrator (or an authorized user) to selectively specify and/or modify the parameters of the action module's structured interactions with users. The parameters for each defined interaction are stored in action ID descriptions which include identification of the action type, the identity of the person sending a communication, the subject, the identity of persons who are to be sent a communication, the date, time, event or condition at which a communication is expected or to be sent, the lead time from a scheduled send date when a communication can be sent, the number of times a communication is to be repeated or response status checked, and/or the identification of a report to be sent.

The invention is particularly suited for coordinating actions within an organization which has its administration, operations staff, district offices and/or local facilities dispersed in different locations. The network system can have the architecture of a wide area network (WAN) in which data links to stand-alone computers and/or local area network (LAN) facilities of the dispersed offices are interconnected through a central hub. A particular application of the network system of the invention to a dispersed organization is described below.

The administrator can establish an action module to manage communications and responses from and to selected users dispersed in the wide area network. A fully functional action module acts in the network as an electronic organizational actor (EOA) which is programmed to perform its given job functions. A plurality of EOAs, each responsible for coordinating the actions of its associated users, can be established in the network as an electronic labor force for the organization.

The invention has the capability of coordinating the actions of persons in an organization by programmed interactions specific to their activities, and also the flexibility to establish and modify the defined interactions that are to occur. It avoids rigid linear structuring of the network environment by making each action module an independently operable adjunct to an open network. Thus, users can freely communicate among themselves on the network while directing or receiving specific communications to or from a designated EOA for automatic handling or response. Modification of any of the EOAs, or any of its interactions, is readily obtained by modifying only the selected interaction parameters, rather than having to reprogram the entire system.

Other objects, features and advantages of the present invention will become apparent from the following detailed description of the invention considered in conjunction with the drawings, as follows:

DESCRIPTION OF THE DRAWINGS

Fig. 1 is a schematic diagram of an interaction network architecture in accordance with the principles of the invention;

Fig. 2 is a schematic diagram of an interaction network structure for an organization employing electronic organizational actors (EOAs) in an electronic labor force in accordance with the invention;

Fig. 3A is a flow diagram of an administrator interface for configuring an EOA in a network, and Fig. 3B shows the relationships of the user (templates), action module, administrator, and data storage for an EOA;

Fig. 4 is a flow diagram showing an example of an EOA procedure for processing a report request from a user;

Fig. 5 is a flow diagram showing an example of an EOA procedure for sending a follow-up communication to a user;

Fig. 6 is a flow diagram showing an example of an EOA procedure for sending a response based upon the form of a received communication;

Fig. 7 is a flow diagram showing an example of an EOA procedure for opening a scheduled conversation with a user; and

Figs. 8A-8H are schematic diagrams illustrating an example of application of the invention to a wide area network system for a dispersed organization, and showing the interaction routines performed by the programmed action module.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The invention in its broadest sense is directed to coordinating the actions of persons in an organization by carrying out programmed interactions through an electronic network which are specific to their activities and functions in the organization. The programmed interactions are established in and carried out by an action module which is configured as a separately operable adjunct to the network. The system users can direct communications to and receive communications from one or more action modules established in the network as electronic organizational actors (EOAs). The interaction functions of the EOAs can be readily modified as changing organizational circumstances require through an administration interface. Configuring the EOAs and specifying their job functions are thus analogous to the employment of persons to carry out defined job functions within the organization. The EOAs can be employed as an electronic labor force (ELF™, a trademark of the applicant) for repetitive, tedious or automatable organizational functions which need not be done by human beings.

In many organizational settings, the coordination of the work activities depends upon managing the flow of requests, commitments, information, responses and work products in a work group, and, similarly, the flow of communications for the interrelated activities of different work groups. Conventional coordination systems track and monitor such user and group communications through an electronic network. However, besides simply tracking and monitoring such communications, the productivity and efficiency of the organization can be greatly enhanced by automatically handling such communications in accordance with predefined interaction procedures whenever such procedures are known and established for the specific persons and activities involved.

For example, a dispersed organization may have an established procedure of local office managers reporting their weekly results to a central office manager on a specific day of the week, the central office manager sending the results to operations staff for tabulation into a summary report, the operations staff sending back the summary report to the central office manager on a following day, and the central office manager sending the summary report to a list of executives on a subsequent day. Even if the requests for information and commitments to provide the information were tracked and monitored by a conventional network coordination system, long time lags can occur in people forgetting and needing to be reminded by other people to carry out their commitments, needing prior information from other locations to carry out their commitments, and attending to reviewing, processing, routing and/or distributing information that passes across their desks.

On the other hand, in accordance with the invention, an action module can be set up as a programmed adjunct to the network addressable by a given name at an office location and provided with a program of structured interactions wherein the steps in the weekly reporting procedure are carried out automatically, thus, if one or more local office managers forget to send their weekly results on time, automatic reminders are generated by the action module and sent to their workstations. If any manager needs prior information which has been stored in an archive file, the action module automatically finds the information and sends it to the requester. When the weekly results have all been sent in, the action module automatically sends the results to the operations staff for tabulation, and sends a reminder if the summary report is not sent back when expected. When the summary report has been received, the action module automatically routs copies to the workstations of the district executives on the distribution list.

Thus, the action module, or electronic organizational actor, is used to reduce or eliminate time lags in the weekly reporting procedure by its program of structured interactions with the persons and groups involved. If the reporting procedure or distribution list is changed, the program parameters for the EOA are simply modified. The EOA can be used to carry out multiple procedures for a group or for related groups, and multiple EOAs can be employed as an electronic labor force for different divisions or projects throughout an organization. The ELF™ network can also be extended across different organizations, as well as to large infrastructures interconnected by an electronic network, e.g. telephone and telecommunications systems.

The principles of the invention can be implemented within a single local area network (LAN), between separate LANs, or over a wide area network (WAN) involving multiple LANs, standalone computers and/or host computers. A typical WAN system having users and groups in dispersed offices connected through a hub office is described below to illustrate one implementation of the invention. A description of a particular application of the WAN network system to a dispersed company having periodic reporting procedures follows. It is to be understood that the principles of the invention ar readily applicable to many other types and configurations of network systems and applications besides the one disclosed herein. Moreover, such principles are extendable to many other types of organizational activities besides the work function communications disclosed herein.

System Architecture

Referring to Fig. 1, an overall interaction network architecture is illustrated for coordinating defined organizational activities in a wide area network connecting local offices 10 (one is shown for simplicity), an operations office 20, district or executive offices 30, and an action administrator office 40 through a communications hub 50. The local offices 10 are shown as connected to the network through a host computer which supports a plurality of terminals for users to conduct onsite functions, such as sales, cost accounting, inventory control, etc. Alternatively, each local office may have a plurality of stand-alone workstations connected by a LAN. The operations office 20 is shown as having a LAN connecting a main frame computer, which also supports local workstations. The main frame computer is typically used to perform large-scale computational tasks for the organization, such as general ledger accounting. The district/executive office 30 is shown as having a host personal computer, or may have a plurality of computer connected by a LAN, for supporting the activities of executives. The action administrator office 40 is where coordination activities for the organization are carried out, and may be a separate office or a part of the district/executive, operations or even local offices, i.e., it can be located anywhere in the network. The communications hub 50 serves as a central facility for operating" the network and receives and routes communications from all of the connected users and groups. Such facilities are widely known, and are not discussed further herein.

The network employs a common communications interface, shown in this example as the Message Handling System (MHS) of Action Technologies, Inc., of Emeryville, California. MHS provides the common data formatting and communications protocol conventions for sending and receiving communications on the network. In the example illustrated, each host computer or LAN group connected to the network employs a message coordination program for tracing and monitoring the local user's messages and activities. A preferred message coordination program is the Coordinator" System and Conversation Manager™ program of Action Technologies, Inc., which is a commercially available product. The details of the Coordinator^R System are incorporated herein by reference and are not described further. The system of the invention can be operated with or without the message coordination program.

In accordance with the invention, certain defined coordination activities for the organization are carried out by an action module at the action administrator office 40 as indicated in Fig.1. The action administrator manages one or more action modules, called electronic organizational actors (EOAs), in an electronic labor force for the organization. Each EOA performs a program of structured interactions for coordination activities through an interface 41 called "The Action Generator" or "TAG™" ( a trademark of the applicant) interface. The EOA with TAG™ interface constitutes an adjunct module or entity to the network system which is separately operable from the users, groups or overall network it is intended to serve. It is controlled through the interface by a human administrator 42 who provides the synthesizing intelligence and decision-making to ensure that each EOA is well configured to perform its intended coordination functions for the users and groups it serves. Data storage 43 for the one or more EOAs is referred to herein as the "Data Warehouse" or "DW" which stores the reports, summary data and raw data provided by or generated for each associated set of users and groups. The action administrator office 40 is also connected to the network through the MHS communications program and operates the message tracking and monitoring Coordinator^R system.

Fig. 2 illustrates an example of one possible network structure for the organization which uses a plurality of electronic organizational actors to perform coordination activities for associated users and groups in the organization. Local LANs 10 (or hosts) supporting numerous users, operations LAN 20, executive computers 30, and the action administrator 40 are all connected together via the WAN data highway, which corresponds to the communications hub 50. The action administrator manages a number of EOAs, EOA-1 to EOA-4, to perform their respective coordination functions. The EOAs are shown in Fig. 2 as virtual entities (in phantom lines) each of which is addressable by a given .name on the network by an associated user. Since the network is intended to be largely transparent to a user, the EOA appears to the network user as a separate entity which is responsible for defined set of coordination activities. For repetitive, tedious or automatable coordination tasks, any number of EOAs of the organization's ELF™ network can be established by the action administrator simply by defining their respective address "names" and "job descriptions."

One primary coordination activity in organizational settings is the coordination of structured conversations, i.e. communication-response interactions, among users and groups. An example is shown in Fig. 2 in which a user in one LAN group conducts a conversation with EOA-2 for coordination of activities with a user in another LAN group. The conversation interactions are structured so that authorized users can address the EOA on the network using the same methods and conversational procedures as used to converse with a person. This provides the users with a feeling of familiarity in carrying on the conversations, as well as shortens the learning time for carrying on a conversation. Detailed examples of application of the invention to carry on conversation interactions are discussed further below.

EOA Interface

Fig. 3A is a diagram of the TAG™ interface for configuring the conversation interactions of an EOA in a communications network. The TAG™ interface acts as an interpreter translating the EOA parameters, as specified by the administrator through an I/O console (keyboard, display, etc.) action ID descriptions which are stored and used for performance of the conversation functions. Each action type is given an Action ID and an accompanying task description. Useful tasks include: (1) performing actions for users, e.g. processing incoming information, fulfilling user requests, performing actions required by a calendared date, trigger event, or exception condition, or calendaring future actions; (2) sending communications in the form of reminders, progress report requests, instructions (or scores) for user skill building, and advice and suggestions based upon the activities and performance of the user; and (3) enclosing information (files) to users.

In Fig. 3B, the operational parts of the EOA are illustrated schematically. At the user station, communications templates are stored as "Action Tools" which the user employs to send a structured communication to the EOA. Each template is structured and labelled according to a particular communication type. The templates include a user ID and define a number of fields for entry of data by the user, e.g. user's name, subject, and/or information to be communicated. Prompts are generated on the user's workstation display for entry of the data for each of the fields. The user communication is sent as a file having key symbol combinations (KSCs) delimiting the data fields. The communication is addressed to the EOA user name at a given location. New or modified templates are loaded with the user's Action Tools, sent as a message file to the user, or automatically downloaded from the EOA through the network. The EOA, in an "Automatic Mode," receives the user's communication addressed to it through "The Action Generator," i.e. TAG™ interface, and extracts the data in the template fields for processing of an appropriate response. If the communication is a request for a report, the TAG™ interface sends the communication to the "Data Warehouse" or "DW" where the request is filled. DW is preferably a standard database management system which recognizes a report request from the TAG™ interface within its standard command set or its structured language, as well as search requests (e.g. numerical searches) and other DBMS functions. DW retrieves or assembles a report in an output file along with a status file indicating the action ID of the appropriate response. If the communication requests a report upon the existence of a certain condition (e.g. reported sales below a defined level), or conveys information indicating a certain condition for which a response is to be given, and the TAG™ interface checks for the existence of the condition and identifies the corresponding action ID. The TAG™ interface may also initiate a conversation with a user based upon an action ID specified for a calendared reply-by or follow-up date, or in response to a trigger event or exception condition specified by administrator input. The TAG™ interface thus locates the action ID corresponding to the type of incoming communication and assembles the response, message, and/or enclosed report required by the corresponding action ID description and/or provided by the DW for sending to the user. Further details of designing the EOA's structured conversations are given in the"Action Module Developer's Guide" appended hereto as Appendix A.

The TAG™ interface can function as a standard conversation interface not only to associated users but also to other programs with which it operates. For example, its request-response format can be used as an interface to a standard DBMS used as the DW. If the other programs do not recognize the response-request format, communications from the interface can be converted to the structured language recognized in such programs. Thus, the open environment of other standard programs can be maintained while using the TAG™ interface. Examples of EOA Structured Conversations

Once the user's Action Tools and conversation templates are established, and the TAG™ action ID descriptions are defined, structured conversations can be carried out automatically between the EOA and users. The processing of some examples of typical conversations are described below.

Fig. 4 shows the processing steps for an EOA's response to a request for a report from a user. To start, the EOA receives a user communication addressed to it through the TAG interface (step 60). TAG parses the user request and checks whether the user ID is an authorized name on the TAG directory (step 61). If the user is not authorized, a "Decline" message is sent to the requestor and processing is terminated. The KSC fields of the user request are then parsed (step 62), and if an Action ID number is recognized (step 63), the program parses the template fields according to the corresponding action ID description (step 64). If no Action ID is recognized, the program sends the string of template fields to DW as a request for report file to a response directory of the DW (step 65).

The DW program reads the response directory and deletes the request file when the report is to be performed (step 66). DW opens a temporary file in which the requested report is to be written or assembled and a status file to track the response action (steps 67, 68). When the report is completed, it is given a report file name (step 69), then TAG closes out the status file of the DW output action and sends the requestor a communication with the requested report enclosed (steps 70, 71).

Fig. 5 shows the processing steps for an EOA's sending of a progress report request (follow-up) to a user if an expected report or response has not been received by a calendared date. To start, TAG checks its calendar for any responses that are due (step 75). If a response is due, TAG checks its Action ID status file to determine if it was received (step 76). If not, a "Progress Report" message is retrieved (step 77), and a reply-by date (as specified by template) is selected (step 78), and the calendar is updated with the reply-by date (step 79). Another user can also send TAG a request to send a user a "Progress Report" message (step 80).

Fig. 6 shows the processing steps for an EOA's response based upon the "form" of a received communication. This procedure is used when information of a specified conversation type is sent by a user and must be in a prescribed form so that the TAG™ interface can recognize and extract the data for storage in DW. To start, the interface program reads the communication type label of the incoming communication and updates the Action ID status file for the communication received (step 81). It then checks the template description to determine whether the form of the communication is allowed (step 82). If so, the information is converted from the received communication and stored in DW, and an appropriate response (determined by Action ID description) is sent back to the sender (step 83) and, if required, a further reply-by date is set (step 84) and the TAG calendar is updated (step 85). If not, an "Incorrect Form" response appropriate to the communication type is retrieved (step 86), and a reply-by date is calendared.

Fig. 7 shows the processing steps for an EOA's action to open a scheduled conversation with a user. To start, a check is made of the calendar for all Action IDs (step 90) which were previously listed for future action in response to user requests or required by the action administrator. The corresponding Action ID description is checked to see if a report is scheduled (step 91), and whether or not it is scheduled according to a previously defined exception condition (step 92). For example, a user may have requested that a report be sent in the event an organizational goal or result for a previous period exceeds an upper or lower level. If the report is due upon an exception condition, the program sends the report request to DW (step 93) which sends back a report enclosure file. The program checks the exception type (step 94) to determine whether it requires sending a communication. If the exception condition does not exist, the procedure is terminated and the reply-by date is cleared from the calendar. If opening a further conversation is to be scheduled, a reply-by date is set (step 96), and the calendar is updated (step 97). The appropriate message, reply-by date, and/or enclosure file is then sent to the user (step 95).

Application of EOA to Dispersed Company

The structured conversations, templates, and action ID descriptions as described above are designed and tailored to the specific application for which the EOA is used. An example is given below of a representative application of an EOA to a company having dispersed offices connected by a WAN for periodic reporting functions. Referring to Fig. 8A, an EOA 101 is used to automatically perform interaction functions between local offices 102 sending weekly data (e.g., sales, expenses, inventory, etc.), an operations staff 103 maintaining general ledger accounting for the company, and managers and executives engaging in conversations-for-action (CRAs) with the EOA. The EOA may be configured or modified by input from the administrator 105.

In Fig. 8B, the known and established reporting interactions of the dispersed company include: (a) entering current data into an on-site data base at the local offices (111); (b) reporting weekly data to the EOA by retrieving it from the on-site data base (112) into a weekly file, and receiving the weekly file at the EOA (113); (c) performing the scheduled functions of the EOA's central module 114 based upon the weekly data from the local offices 102, budget data from the operations 103, conversations-for-actions from the managers and executives 104, and administrative input from the administrator 104; (d) maintaining the EOA data base in response to any received updates (115); and (e) entering any manually entered and other relevant activity data for the week (116).

In Fig. 8C, the main functions of the EOA central module 114 include: (a) managing conversations with users (121);

(b) preparing and sending reports in response to the scheduled or self-initiated requests of the managers and executives (122); and

(c) transferring the budget data from the operation staff to the EOA data base (124).

Fig. 8D, the Manage-Conversations function of the EOA central module is illustrated in more detail. Weekly-Data Conversations 131 are managed using the specified conversation parameters, A Conversations data base, and the EOA's data base. Report-Offer conversations 132 are managed according to specified conversation and report parameters. Report-Request Conversations 133 include responses to user-initiated requests upon checks for user clearances. Future Conversations 134 are set according to specified or requested calendar dates. All of the different conversations are maintained and monitored by the Maintain Conversations instructions 135 according to the templates stored in the EOA's data base and any administrative input.

Fig. 8E provides further details of the Weekly-Data

Conversations 131 shown in Fig. 8D. Conversation rules and schedules (141) are set by the specified conversation parameters. The Weekly-Data conversations are carried out (142) according to any promises-to-send, scheduled conversations, canceled requests, completed request, and offers. Further details of the Report-Offer Conversations 132 are illustrated in Fig. 8F based upon conducting offer conversations (151) according to conversation rules (152). Report-Request Conversations 133 are shown in Fig. 8G based upon receiving and responding (161) according to conversation rules and authorizations (162) to requests (163).

In Fig. 8H, the Maintain Conversation function 135 of

Fig. 8D is schematically illustrated in greater detail as including listing (171), reviewing (172), closing (173), and/or printing (174) conversations which are maintained. Reports on the conversations are also prepared (175, 177), and the Conversations data base is periodically archived and purged (176) .

In summary, the central concept of the invention is the setting up of electronic organizational actors of an electronic labor force as separately operable, adjunct entities in a network system. The EOAs are used to automatically perform defined interaction functions with users and groups which are known and established in the organization, so as to improve the productivity and efficiency of the organization by reducing or eliminating repetitive, tedious or readily automatable functions that need not be performed by human beings. A particularly advantageous application of an EOA is for managing structured conversations among users and groups in the organization. A central feature of the invention is the ability to configure and modify the Structured interactions of the EOAs through an administrator interface without having to reconfigure or reprogram the entire network system.

Numerous modifications and variations are of course possible in light of the principles of the invention disclosed above. All such modifications and variations are intended to be included within the entire spirit and scope of the invention, as defined in the following claims.

APPENDIX A

ACTION MODULE'S DEVELOPERS GUIDE

Ta ble of Con t ent s

Introduction

1. About Elf Technology

2. The Coordinator Interface to TAG

Overview

Tools for Building Templates

Parameter Fields

Use of the "Action ID" Key Symbol Combination

A Completed Template

3. Sending Report Requests From TAG to the Data Warehouse

Overview

Sorting of Incoming Messages

Parsing of Template Parameters

Example of a DW_REQUEST File

4. Delivery of Report Response From the Data Warehouse to TAG

Overview

Read and Delete DW_RΞQU£ST File

Create DW_STATUS File and DW_RESPONSE.TMP File

Completing the Report

5. Critical Event Notices From the Data Warehouse

Overview

Example of a Critical Event TN

Setting Up a TN Action ID in TAG

Generating TN Trigger Files

SUBSTITUTE SHEET Introduction

This Guide is intended for application developers who will be designing and developing applications that use Electronic Labor Force (ELF) Technology. With ELF Technology, an application developer creates Electronic Organizational Actors (EOAs) that can, among other functions, fulfill requests made by users over The Coordinator system.

It is assumed that users of this Guide are experienced in the following:

Using The Coordinator system

Designing and writing application programs in a language such as a DBMS programming language

Setting up Action IDs in TAG

The Guide consists of five chapters:

About ELF Technology╌ provides an overview of ELF Technology and some of its basic parts including The Action Generator (TAG), Electronic

Organizational Actors (EOAs), and the Data Warehouse (DW) associated with each EOA. It also includes an overview of the report generation process using ELF Technology.

The Coordinator Interface lo TAG╌ provides the specification for developing templates for Coordinator users to make report requests of an EOA.

Sending Report Requests From TAG to the Data Warehouse╌ provides a description of how TAG processes communications which contain report request templates. This is provided as background.

Delivery of Report Response From the Data Warehouse lo TAG╌ provides the specification for a DW delivering reports to a user via TAG.

Critical Event Notices╌ provides the specification for a DW to alert administrative users (via The Coordinator) of critical events having occurred in the DW. About ELF Technology

An example of an ELF network is illustrated in Figure 1.

The basic building blocks of an ELF network include the following:

The Action Generator

The Action Generator is a powerful new kind of communications for application for facilitating and managing communications in a Wide Area Network (WAN). It allows the administrator to establish and maintain organizational actors that communicate within the WAA environment.

Electronic Organizational Actors

An "electronic organizational actor," is an MHS username that appears in the Address Books of The Coordinator users. These conversational-based organizational actors are programmed to automatically open and reply to communications.

Data Warehouse

Each organizational actor has an associated data Warehouse. It is in the Data Warehouse that the data files and report summaries are established and maintained. Through the interface to The Action Generator, the conventions and protocols are established by the administrator that permit communications among and between people and EOAs.

Basically, the process of generating reports using these parts of ELF Technology involves the following tasks:

• The user prepares and sends a request to an EOA for a report,

specifying the parameters of the report.

• TAG receives the request, translates the parameters into a format that DW can act upon, and then sends this "request file" to the DW.

• The DW generates the requested report and puts the information into a file it creates.

• TAG opens a response to the user, encloses the report file, and sends the communication to the user.

The details of this process are illustrated in Figure 3B. 2. The Coordinator interface to TAG

Overview

Tools for Building Templates

Parameter Fields

Use of the "Action ID" Key Symbol Combination

A Completed Template

Overview

In an ELF network, TAG acts as an interpreter, translating the parameters specified in report requests from Coordinator users, into a format that can be acted upon by a DW. The user provides these parameters by means of a

"template" which the developer designed specifically for that type of report.

This section contains a description of a template and how it is used by a user, specifications so you can develop a template, as well as specifications for directing template parameters to another directory.

Template Description and Use

The following is an example of a template:

Complete the template below to obtain a list of employees.

• Report name : Staff

• Salary level

• Department

The ASCII symbol "•" indicates that the text following the colon (:) is a

"parameter" that describes one characteristic of the report being requested. When the template is received by TAG, the parameters will be separated from the rest of the template and written to a "DW Request File" that contains only the parameters.

An example of a completed template is as follows:

• Report name : Staff

• Salary level: <35000

• Department : Sales

A template will normally be stored in a DOS subdirectory. To initiate a request to the DW, the user performs the following the actions:

1. Open a request to the EOA

2. Insert a template into the request

3. Fill in the template

A. Address The Coordinator envelope

5. Send the Request by using F4=Send

The Request containing the template will then be delivered to the appropriate TAG host via MHS, depending upon the actor address that appears in the request. Tools for Building Templates

Templates must be developed with a text editor other than The Coordinator, one which allows entry of the full IBM ASCII Character set. One such editor is TED.COM. This is available as a free utility from the PC Magazine "PC MagNet" bulletin board. Instructions for gaining access can be found in any recent issue of PC Magazine.

Using an editor such as TED.COM, specific combinations of symbols can be entered into the template file which will not be visible to the user when inserted into into a Coordinator communication.

Table 1 lists the individual symbols that are used to construct "hidden codes," and the keys for producing them using TED.COM.

TABLE 1

ASCII SYMBOLS and CODES

Decimal ASCII Appearance

Character Keys Value Code in TED.COM

^A Ctrl+a 1 SOH Smiley face

^B Ctrl+b 2 STX Smiley face

^ C Ctrl+c 3 ETX Heart

^D Ctrl+d 4 EOT Diamond

^ [ Esc 27 ESC Left-pointing

arrow

The same symbols can be produced with many other text processors. Follow the text processor instructions to produce the ASCII codes listed in Table 1 above.

Using the symbols from Table 1, text in the Coordinator can either be fully protected or partially protected. If a line of text is fully protected the user will not be able to enter text any where in the line. If a line is partially protected the user will only be able to enter text in designated areas of the template.

The combinations of ASCII symbols to achieve these two effects are as follows:

^ [ ^A^ [ ^B THIS LINE IS FULLY PROTECTED

^ [ ^ A ^ C ^B THIS LINE IS PARTIALLY PROTECTED ^ [ ^D

For the line that is partially protected, the user will be able to enter text only after the "ESCEOT" symbol combination. If the cursor is placed to the left of the symbol combination and a key is pressed, the character will appear immediately following the colon.

Parameter Fields

A template that will be used as a report request template will have the parameter fields designated by the following

"key symbol combinations" (KSCs)... • Optional text :

which will indicate to TAG that the data following the KSC is a parameter that is to be parsed to an request file for the DW. The CSC combination that will be detected by TAG is actually...

Characters that are entered following the colon (:) will be parsed to an output file in a comma-delimited format when The Coordinator communication is received by TAG.

Because the parameters describe the characteristics of a DW report, they must be arranged in the template in the exact order in which the DW is expecting to receive them. However, to achieve an effective template design, the order of fields in the template should be designed first. The DW can then be programmed to read the request parameters in the order in which they appear in the template.

A template may contain up to 35 KSC fields. Use of the "Action ID" Key Symbol Combination

Parameters that follow a KSC will be parsed by TAG to a DW request directory. However, by using the special key words "Action ID" as the text within the first KSC, the template parameters will be directed to a directory other than the DW request directory. For example, for the template...

• Action ID : EMPLOYEE

• Salary level : ' <35000

• Department : Sales

the parameters will be parsed to a file in the [d:]\TAG\EMPLOYEE

directory where [d:\] is the letter of the drive letter in which TAG is installed. A Completed Template

Data entry templates will in general make use of a combination of protected and partially protected fields as well as KSC fields. For example, a developer may choose to develop a template such that instruction and title lines are fully protected and data entry lines are partially protected.

The following is an example of a template as it might appear in the text editor

To request a list of employees, fill in the entries below and send it to "Admin @ ABC.

^ [ ^A^ [ ^B • Report name : ^ [ ^ DStaff

^ [ ^A^ [ ^ B • Salary level : ^ [ ^ D

^ [ ^A^ [ ^B • Department : ^ [ ^D 3. Sending Report Requests from TAG to the Data Wareh ouse

Overview

Sorting of Incoming Messages

Example of a DW_REQUEST File

Read and Delete DW_REQUEST File

Create DW_STATUS File and DW_RESPONSE.TMP File

Completing the Report

Overview

When a report request containing KSC fields is received by TAG it is processed as illustrated in Figure 2. The actions taken by TAG are entirely automatic and occur when TAG is set to operate in the "Automatic Mode". The specific contents of the request file that is delivered to the DW is determined by the template parameters.

This chapter describes the processing by TAG of a communication with an inserted template including:

• Sorting the incoming messages

Parsing the template parameters

• Example of a DW_REQUEST File

Sorting of incoming Messages

When TAG receives an incoming communication, the following actions are taken (refer Figure 2):

Step 1

TAG compares the MKS address in the communication to the addresses of users who .have been authorized in the "Set up Access and Security Rights" area of the Directory Manager.

If the MHS address has not been declared, the Coordinator user is sent a Decline communication and no further processing occurs. The Decline message itself is associated with the TAG Action ID TN100001, the message of which can be customized by the TAG Administrator.

Step 2

TAG scans the Coordinator communication for KSC fields. If there are none, the communication is just added to TAG's mail records without any further processing.

Step 3

TAG checks to see if the first KSC field in the template contains the key words "Action ID". If it does, the parameters are directed to an output file in the directory:

(d:]\TAG\ACTION_ID

If it does not, the output is directed to the directory.

[d:]\ACTOR\REQUESTS

where "ACTOR" is a name or abbreviation (of up to S characters) for the particular EOA. The ACTOR name is taken by TAG as the name that is entered in the Directory Manager under "Set up this host." Parsing of Template Parameters

The template file will be processed by TAG as follows:

1. Template parameters will be parsed to either the

[d:]\TAG\ACTION_ID or [d:]\ACTOR\REQUESTS directory. The output directory will depend on the use of the key words "Action ID" as described in Section 3.

2. The output files will be given a unique file name which is to be

received by the DW.(We will call this a DW_REQUEST)

3. The DW_REQUEST is constructed as follows:

DW_REQUEST = TAG_SITE_ID + SEQUENCE_NUMBER where the TAG_SITE_ID is taken from the "Site ID" field in the TAG Setup screen and the SEQUENCE_NUMBER is the next number automatically assigned by TAG.

A. The parameters in the DW_REQUEST file will be in comma delimited format in the same order in which they appeared in the template. The first parameter in the request file will be the MHS_MESSAGE_ID of The Coordinator request communication. The second parameter in the template will be the first parameter from the template.

5. The Access Codes that are declared for the user making the

Coordinator request will be appended to the comma-delimited string of parameters preceded by the ASCII symbol ö (ASCII 153).

Example of a DW_REQUEST File

Consider the case in which JDoe @ ABC has sent a request to the EOA with MHS address Admin @ ABC. The Coordinator communication contained the following template...

• Report name : STAFF

• Salary level; <35000

• Department : Sales

and JDoe @ ABC is declared in TAG with the following access codesAccess Code 1: <=50000

Access Code 2: Staff A DW request file will be produced as follows:

Filename

[d:]\ACTOR\REQUESTS\DW_REQUEST_NAME

Con ten ts

MHS_MESSAGE_ID,<35000,Sa!esÖ<=50000,Staff

4. Delivering Reports From the Data Warehouse

Overview

Read and Delete DW_REQUEST File

Create DW_STATUS and DW_RESPONSE.TMP File

Completing the Report

Overview

Once a DW_REQUEST file has been created by TAG as described in Section 3, the DW application must read the file and respond according to the file handling protocols in this section.

The DW application programmer must provide these file-handling capabilities in the DW communication interface as described in this section. As far as TAG is concerned there are no constraints placed on the physical location of the DW software. It can operate either in the same host environment (PC or PC LAN) or on a remote host interfaced through a communications gateway provided with the DW.

The processing steps specified in the remainder of this section follow the flow diagram in Figure 2 in the same order in which the DW processes occur in that figure.

Read and Delete DW_REQUEST File

The DW must read each DW_REQUEST file in the [d:]\ACTOR\REQUESTS directory into the DW application environment. Once the file has been read, it must be deleted from the [d:)\ACTOR\REQUESTS to avoid reprocessing of the request file.

Create DW_STATUS File and DW_RESPONSE.TMP File

In response to the read action on the DW_REQUEST file, the DW must create two files in the [d:]\ACTOR\REPORTS directory. These are a

DW_RESPONSE.TMP file and a DW STATUS file.

The DW RESPONSE.TMP File

The DW_RESPONSE.TMP file must initially be written as a temporary file whose content is arbitrary. Once the report is delivered from the DW, it must be written to the DW_RESPONSE.TMP file. The file is named according to the following convention:

DW_RESPONSE.TMP - TAG_SITE ID + SEQUENCE NUMBER + .TMP

It is the responsibility of the DW application software to construct the filename including supplying the unique SEQUENCE_NUMBER. The (TAG_SITE_ID + SEQUENCE_NUMBER) may be the same as the DW_REQUEST file.

For example, TAG host with a TAG_SITE_ID = ADMN, a request fiie would get produced with the name...

[d:)\ACTOR\REQUESTS\ADMN4772 (where 4772 happens to be the next TAG sequence number and is automatically assigned by TAG).

The DW_RESPONSE.TMP file could be named as follows:

[d:]\ACTOR\REPORTS\ADMN4573

(where 4573 is supplied by the DW). Alternatively, the TAG supplied

SEQUENCE_NUMBER can be reused for this report. In this case, the

DW_RESPONSE.TMP file would be named as follows...

[d:]\ACTOR\REPORTS\ADMN4772

The REPORT STATUS File

A REPORT_STATUS file must be produced which has the same filename as the .TMP file for the report that is being processed. The REPORT_STATUS message block specification is as follows:

Line 1 MESSAGE_ID{,RPT_FILE_NAME]

The definitions in the message block are as follows:

MESSAGE_ID

The MESSAGE_ID for a report response must be the same as the 16 character MES_MESSAGΕ_ID contained in the DW_REQUEST file that originated the report request.

RPT_ FILE_NAME

This parameter is optionally provided by the DW. It is used to provide a different filename extension other than .RPT. The RPT_FILE_NAME is defined as follows:

RPT_FILE_NAME = DW_EESPONSE + "." + EXTENSION

For example, if the enclosed report that will be sent to a user is a Lotus Spreadsheet, the file can be renamed with a .WK1 extension be setting EXTENSION = WK1.

The following message block,

09SS767123e79326,ADMN7231.WK1

will return a report enclosure in response to a user request with

MKS_MESSAGE_ID - 098S767123e79326, with the enclosure bearing the filename ADMN723 LWK1.

Completing the Report

When the DW has completed the requested report it must be written to the following file... [d]:\ACTOR\REPORTS\DW_RESPONSE.TMP where DW_RESPONSE.TMP is the file previously opened as described above.

After the report has been written to DW_RESPONSE.TMP the file must be renamed to the following:

[d):\ACTOR\REPORTS\DW_RESPONSE.RPT

retaining the same DW_RESPONSE filename as the previous .TMP file and the associated REPORT_STATUS file.

After the report file has been renamed, TAG (operating in the Automatic Mode) will complete the report delivery process by executing the following actions:

Step 1

Read the MSG_ID in the REPORT_STATUS file and open a report response communication that is linked conversationally to the original user Coordinator request.

Step 2

Enclose the [d]:\ACTOR\REPORTS\DW_RESPONSE.RPT file with the communication.

Step 3

Send the report communication with

[d]:\ A CTOR\REPORTS\DW_RESPONSE.RFT enclosed.

Step 4

Delete [d]:\ACTOR\REPORTS\DW_RESPONSE.RPT and the status file [d]:\ACTOR\REPORTS\DW_RESPONSE.

5. Critical Event Notices From the Data Warehouse

Overview

Example of - Critical Event TN

Setting Up - TN Action ID in TAG

Generating TN Trigger Files

Overview

A critical event is defined here to be any event, state change, or condition that may occur in the DW or its environment, which the DW has the capacity to observe through the DW application software. Administrators can be notified over The Coordinator system of critical events that have occurred.

A critical event that occurs in the DW can be observed by setting up a TAG Notice (TN) in TAG. (A TN is a TAG Action ID that has been set up under Outgoing actions.) The communication that had been declared for the TN will then be sent to the To addressee declared in the TN Action ID in TAG. Each TN associated with the DW is assigned an Action ID of:

TN2xxxxx

where xxxxx is any combination of up to five characters.

Once a TN has been set up as an Outgoing action, it can be triggered when the DW writes the DW_RESONSE.RPT and REPORT_STATUS files to the

[d:]\ACTOR\REPORTS directory according to the specifications that follow.

Example of a Critical Event TN

An example of how a TN might be used is illustrated by considering a case where the DW has been programmed to check for the amount of free space available on a local hard disk. If the free space is below, for example, 10 MBytes, DW_RESPONSE.RPT and REPORT_STATUS files are written to the [d:]\ACTOR\REPORTS directory to trigger the related TN. The message is sent to the ACTOR Administrator over The Coordinator with the following text.

The disk free space available lo the Data Warehouse has fallen below 10 MBytes. Please perform routine Housekeeping so that there is at least 50 MBytes of free space.

Setting Up a TN Action ID in TAG

In order for a TN to be triggered, the Action ID must be assigned and set up in TAG. It is recommended that the developer and ACTOR Administrator agree on a TN naming convention. Again, the first 3 characters of the Action ID must be "TN2."

The Action ID can be addressed to a distribution list to allow simultaneous observation of critical conditions by a number of people. It is also recommended that the TN Message be written in a style that allows easy interpretation by a relative novice: it should include instructions on what actions to take in response to the error. Generating TN Trigger Files

TN Trigger files are the pair of DW_RESPONSE.RPT and REPORT_STATUS files with the same filename and processed as described in Section 3. When these files are in the fd:]\ACTOR\REPORTS directory, the TN named in the

REPORT_STATUS file will be triggered. The DW_RESPONSE.RPT is o ptional and should only be used if the TN that is triggered is to include a DW report.

This section contains the specifications for these files.

DW RESPONSE Filcsnec

The file name for DW_RESPONSE is constructed according to the following rule:

DW_RESPONSE - DWXX + SEQUENCE_NUMBER + .RPT

with the SEQUENCE_NUMBER being assigned by the DW.

For example, a valid DW_RESPONSE filespec would be DWXX7021.RFT, where 7021 is a sequence number provided by the DW.

REPORT STATUS File Contents

A REPORT_STATUS file must be produced which has the same filename as the DWXX xxxx. RPT file if there is one.

The REPORT_STATUS file content specification is as follows:

Line 1 MESSAGE_ID

Line 2 Blank╌ reserved for future use

Line 3 TAG_ACTION_ID

Line 4 Optional text

Line 5 Optional text

Line 6 Optional text

The definitions in the message block are as follows:

MESSAGE_ID

The MESSAGE_ID for a TN must be constructed as follows:

MESSAGE_ID = Appl_ID: + TAG_ACTION_ID

For example, a valid MESSAGE_ID is...

Appl_ID.TN200001

TAG_ACTION_ID This is the TAG Action ID that has been declared in TAG. The Action ID is constructed as follows:

TAG_ACTION_ID = TN2 + nnnnn

For example, a valid TAG_ACTION_ID is:

TN200001

Optional text

Up to three lines of optional text can appear in the REPORT_STATUS file. These lines normally contain a warning message. These three lines will be inserted into the message of a triggered TN if the following command is inserted into the TN message composition window;

%&.TN

The should be located in the file where the optional text will appear. The '%' character must be located at column 1.

APPENDIX B

ADMINISTRATORS GUIDE Table of Contents

Introduction

Sat up RECURRENT outgoing actions A

Set up recurrent communications 5 Set up a recurrent communication with enclosed reports 6

Set up EXCEPTION outgoing actions 9

Set up exception communications 10 Set up exception report conditions 12

Set up RECURRENT incoming actions

Set up non-receipt notices for incoming actions 15

R un mail activities 16

Run mail activities automatically 17

List and review communications 18

Monitor receipt of incoming actions 19

Read mail 21

Housekeeping 22

Set up RECU RRENT outgoing actions

Set up recurrent communications

Set up a recurrent communication with an enclosed reports

S et up recurrent communications

Sending a communication in ad vance of a critica l action is a n exa mple of a recurrent outgoing communica tion. Propert y Mana gers ma y ask to be sent a communication via Coordinator to remind them to prepa re a nd send the reports ex tra cted from the On-Site system. Curren tly, these reports include the End-of- Week Activity Report, 20th-of-the-Month Activity Report a nd End-of-the-Mon th Activity Report.

From the main menu, select [Outgoin g communications].

A list of scheduled outgoing communications will appear.

Press F2 to add a new scheduled outgoing communica tion.

The "Outgoing Communication Setup" menu appears.

Action ID

select a unique name that is descriptive, for example P.EMIND01 (8 characters maximum).

Subject

This will appear as the Subject name of the communication that the recipients set.

For example: Send End-of-week Report

To

Enter the Coordinator address of the person who will be receiving the communication. Or you may set up a distribution list. Use the format for standard Coordinator PRIVATE distribution lists e.g.

&C:\TAG\DISTLIST\REMIND01

The format of the distribution list is comma-delimited, MKS addresses, one-per-line as described in The Coordinator User Guide, Define and Changs-2 Distribution List.

From

This field will already be filled in with "Bubba.ATC @ Balcor".

Send da te

Enter the date in mm/dd/yy format 'that the first communications is to be sent.

Send time

Enter the time of da y that the communication is to be sent.

Repea t every

This sets The Action Generator to generate the communication repeatedly.

The instructions that can be entered art as follows: 1. Tht "wild card" X╌ indicates "any occurrence". For example:

XX/ 19/XX --> on the 19th of every month 03/03/XX --> every March 3rd.

2. The first three letters of a da y of the week. For example:

SUN --> every Sunday

3. ME for month end, to indicate the last day of the calendar month. A. + or - any number of days. For example:

ME + 2 --> The second day of the new month

+ 1 --> every day

+ 2 --> every 2 days

NOTE: The word "day" can be placed af ter the number, e.g. + 2 days

5. The T symbol can be used as an "or" statement to indicate

"whichever comes first". For example:

XX/20/XX|MON|ME -- the 20th, Monday, or Month-end, whichever comes first.

Lead time

Lead time is the number of days before the scheduled send date and time that the communications may be "forced" using [Process outgoing mail, Selected actions only).

Compress enclosure? and MHS receipt confirmation?

Thtst should be left as the default values, Y and N, respectively.

With the entry fields completed, press F8=OK.

Tht list will bt redrawn with the new tntry.

With your cursor on the listed Action, Press F3=Messagc to compost the body of the mcssagt that the addressees will receive.

With the message composition window displayed, writt tht mcssagt.

For example:

Please submit your Weekly Property Management Report by 11:00am Monday.

A single ASCII text file or several, may also be inserted in the body of the text using the same command lint reference as in tht previous instruction. For example: %&c:\library\news\awards

where "awards" is a list of the latest award winners.

NOTE: The Enter key must be pressed a t the end of the line.

With the message text and template reference completed, press F8=OK to add the communication to the list.

Set up recurrent communications with enclosed reports

The administrator can set up a recurring outgoing communication that encloses a report from the Data Warehouse. An example of this is the weekly Property Activity Report and Occupancy Trend Reports. Ra ther tha n requesti ng these reports from Bubba, a uthorized personnel ma y prefer to ha ve the reports sen t to them automatically each week.

This section outlines how to set up a recurrent outgoing communication with a enclosed Data Warehouse report.

• Set up the parameters for the outgoing communica tion as described in Se t up a recurrent (scheduled) ou tgoing communication.

• Within the body of the message composition window, insert the DOS pa th and filename of the template file which describes the report that the person wishes to receive.

The symbols %& must precede the path name. For example:

%&c:\bubba\library\inserts\par&ot

NOTE: The Enter key must be pressed at the end of the line.

When the communication is sent, the template will be inserted in the bod y of the message beginning at the line where the %& command occurs. The report will be sent as an enclosure.

• A single ASCII text file or several may also be inserted in the body of the text using the same command line reference as in the previous instruction. For example:

%&c:\tag\news\awards

where "awards" is a list of the latest award winners.

NOTE: The Enter key must be pressed at the end of the line.

With the message text and template reference completed, press F8=OK to add the communication to the list. Set up EXCEPTION outgoing actions

Set up exception communications

Set up exception report conditions

S et up exception communications

A u thorized personnel ma y request a communication be sent

when an exception condition is detected within any predefined report ca tegory that exists within an actor's associated data warehouse. For example, she/he ma y want to know if there's a downwa rd trend in the a vera ge occupa ncy of a property for the last four weeks compared to the previous fou r weeks.

Exception communica tions with or without enclosed files can be au tomaticall y sent to authorized personnel immediately when an exception condition is detected.

To set up an outgoing exception communication, the followin g sequence of events must be followed:

A recurrent outgoing communication is set up, however the communication will only be sent if the exception condition exists. The schedule for sending the communication is set by determining how_f requentl y the exception condition is be checked for.

When setting up how frequently an exception condition will be checked, it is important to take into consideration how frequently the data warthouse records will be [refreshed] updated. As an example, the schedule should bt set for no more frequently than once a week for data that is refreshed on a weekly basis.

At the scheduled time, the Action ID is activattd, a communication is opened, but before it is sent, the data warehoust is checked to see if the exception condition exists. If it dots exist, the communication is

automatically sent, with or without an cnclostd file. If it docs not exist, the communication is automatically abandoned.

Set up the paramtters for the outgoing communication as dtscribtd in Set up a recurrent (scheduled) ou tgoing communication.

Set the Send da te and Send time as makes sense for the particular report data refresh rate and managers concerns.

Within the body of the message composition window, insert the DOS path and filename of the exception report template file which describes tht exception condition. Set Set up a PAR exception report t empla te for instructions on how to setup th e templa te.

The symbols % & must precede the path name. For example:

%&\bubba\library\inseris\par-xrpt

If the exception exists the communication will be sent with the templa te inserted in the bod y of the messa ge begging at the line where the "% & " command occurs. With tht message text and template reference completed, press F8 =OK to add the communication to the list.

Set up exception report conditions

Each report category has templates that arc used to define a nd set up the exception condition a nd the format for the outgoing commu nica tion. These exception condition templa tes are inserted into the outgoing communication. A new template is set up for each new exception condition. One Action ID using the same exception condition template can be used for more than one recipient provided they have all requested to be notified when tht sa me exception conditions are detected.

These instructions apply specifically to the following template for the

PAR_XRPT (for PAR Exception Report):

Report-category description ...

• Report ID : PAR_XRPT • Property or group :

• From (week-end date) :

• Thru (week-end date) :

ixc ption-condition description...

• Field name :

• Upper level trigger :

• Lower level trigger :

• Compare to previous period (Y/N) :

• Type of comparison (AVG or TOT) :

• Add this comment to tht enclosure :

If exception does not exists

• cancel Bubba's response (Y/N) :

• Report ID

This identifies the category of exception reports to the Data Warehouse. It should not be modified.

• Property or group

The appropriate 3 or A Ietter codt which identifies the particular property, district, region or portfolio for which an exception will be reported.

• From

Exception conditions can be monitored based on a single weeks result or the summation over multiple weeks. Enter the the starting date.

IMPORTANT: The From da te must be a Monday.

• Thru

Used; in conjunction with From da te above, this value determines the duration in weeks of the interval of time being observed.

IMPORTANT: The Thru date must be a Sunday. Field name

The name of the field for which t he exception will be monitored. This must be entered EXACTLY as shown in the PAR Data Dictionary.

Type of comparison

The report can indicate cither a sum or an average f or the period of t ime of the report. Enter S or A respectively.

Upper level trigger

This is the value of the upper limit, such that when exceeded, an exception exists.

This field entry is optional. It need not be entered if a va lue is entered for the next field.

Lower level trigger

This is the value of the lower limit, such that when exceeded, an exception exists.

This field entry is optional. It need not be entered if a value is entered for the previous field.

Compare to previous period

An exception can be monitored based on a comparison of the period defined by the From and Thru dates, compared to the immediately preceding period of the same duration.

This field entry is optional.

For example, move-outs for a 4 week period can be compared to the previous A week period by answering Yes.

Enclose detail or summary report

A report describing the exception condition will be enclosed with the outgoing communication when an exception exists. The summary report will show the calculated value for the PAR Field name for the time period indicated in the template.

The detail report applies only if a group of properties is indicated in the PAR field name template field. The report will show the calculated value f or the P AR field name for the time period indicated in the template with the totals f or each of tht properties in the group.

Add this commen t to the enclosure

A one lint f ree-form comment can be optionally entered. This will appear as a description on the exception report enclosure.

If co n di tion is not m et ... do nothing

If a n exception dots not exist the outgoing communication will be abandoned by answering Y (for Yes). If N (for No) the outgoing communication with enclosure will bt sent whether or not an exception exists. Set up RECURRENT incoming actions

Set up non-receipt notices for incoming actions

Set up non-receipt notices for incoming actions

BPM managers may elect to receive automatic notification if a Property

Management Report has not been received by its due date. Or, they ma y choose to have it sent to their delegate. For example, non-receipt notification ma y be set to go to a district mana ger's assistant at noon on the report due da te (e.g. in case of a connectivity problem, for example) so that follow-up can then be done by phone with the property.

Setting up non-receipt notices involves modifying ann incoming communication Action that will have been already been set up in The Action Generator.

From the Main Menu, select [Set up recurrent communica tions. Incoming communications).

The "Incoming Communications Activities" list appears.

With the cursor on the relevant line e.g. End-of-Week Report", press Enter

The Incoming Enclosure Setup Menu will appear.

Under "If some missing, send notices? (Y/N), enter [Y).

Enter a communication Subject in the Subject title of notice field.

Press F8-OK.

To review the hosts from which Incoming Reports art expected, press F3-"Frorn" host list.

Run Mail Activities

Run mail activities automatically

Run mail activities automatically

I n the Automatic Mode, incoming communications art automatica lly processed and outgoing communications are a utomatically sent according to their schedule.

Normally, The Action Generator is operated in the "Au toma tic Mode" by selecting [Run ma il activities. Automatic mode] from the ma in menu. The only time it would not be in the Automatic Mode is when new communica tions or network hosts are being declared, or during some other administrative or maintenance activity.

Select [Automatic mode] from the Main Menu to place The Action

Generator in the automatic mode.

Press Esc to remove The Action Generator form the automa tic mode.

The Action Generator will first complete the current processing activity and when complete, return to the Main Menu.

List and review communications

Monitor receipt of incoming actions

Read mail

Perform housekeeping

Monitor receipt of incoming actions

The Action Generator will be recei vin g and processing da ta files f or the Data Wa rehouse. For example, data ex tracted f rom On-Si te for the End-of -week report will be received once a week. On-Site extract data will also be received on the 20th-of-the-month and End-of-month (last da y of the month.)

The following are procedures for receiving the enclosures and verif yi ng norma l operation.

The Action Gentrator should be normally set to process mail automatically. (Sec Run mail activities automatically.)

For example, The Action Generator should be lef t in the automa tic mode over a weekend or holida y so that processing can occur f or an y enclosures that arc received.

On the morning (9 am) of a day when reports are expected to be received check to sec if reports have been received overnight or over the weekend.

Select [Incoming communications,"From" host list].

If some reports have been received, the Date/time rec'd column will show the date and time of the receipt.

If no reports have been received, and this is unusual based on previous weeks performance, then investigate why the files arc not received. First check the connection to the hub. If the files are not at the hub then check with the Local Administrator to determine if the files were sent. If it is determined that files were sent and not received, call RA f or support.

Restore The Action Generator to the automatic mode.

At the time when all the reports are scheduled to be received (e.g 1 1:30 am for the End-of-week report), select [Incoming communications] from the Main Menu.

Scroll the Incoming Communications Activities list to the right to review the All there? field.

If all the files ha ve been received, the All there? field will say Yes.

If all the file have not been received, review the "From" h ost list to see which properties/hosts have not sent their reports. If af ter first checkin g the hub it is found that the the files are not at the hub, then check with the Local Administrator to determine if the files were sent. I f it is determined that files were sen t and not received, call RA f or support.

If all the enclosures were not received, immedia tely call the local administrator to resolve the problem. For reports that were not received, telephone the person responsible at the property. Obtain the data, and manually enter it in the Report Data Warehouse if there is going to be a delay in receiving the report enclosure.

On the Due date and time (as listed on the Incoming Enclosure Setup screen) the enclosures will undergo final processing. Once this occurs the Due Date will be set to the next weeks scheduled date and the All there? field will be reset to No.

Read mai l

The Action Generator ma inta ins a data base of a ll commun ica tions i t's genera tes and certain incoming communica tions. These can be read using t he The A ction Generator mail tools.

To read communications for the first time, select [List and review communications, Read new mail] from the Main Menu.

A list of communications will be displayed.

To read a communication, place the cursor to that communication i n the list and press En ter.

The communication will be displayed.

Pres Esc to return to the communication list.

To read old communications select [List and review commun ications, List all communications) from the Main Menu.

Follow the instruction in the item above.

Housekeeping

Periodically, to keep conversation records "trim", routine housekeeping should be performed to delete old communica tions from the The Action Generator communication data base.

To delete commu nications select [List and review communica tions, List all communications] from the Main Menu.

With the cursor on the communication to be deleted , press Del.

The communication will be marked for deletion.

Select [List and review communications, Remove marked communications from the main menu).

The marked communications will be deleted.

Start TAG directory manager

Configure TAG for this MHS Host

Conf ure TAG for this MHS Host

The Action Generator is designed to work with MHS by Act ion Tech nologies. Before it can opera te wi th MHS, it is necessa ry to decla re the cha ra cteristies of the MHS setup at this MHS host as well as the user and host cha racteristics of the Organiza tional Actor.

In MHS, FTF must have been installed as an MHS applica tion a nd the TAG Organizational Actor must have been installed as an MHS user wi th FTF as the preferred (and only) application.

From the main menu select [Start TAG directory manager].

The Configure TAG f or this MHS Host screen will be displayed.

Fill in the entries as follows...

TAG ID

A unique A alpha numeric ID for this TAG installation and which is different from all others in the wide area network of TAG and FTF hosts.

MHS Version

The version number of the MHS for which TAG messages will be prepared.

Currently only MHS- 1 is allowed.

MHS options

The delivery options supported by MHS. The options art indicated with a single letter response for each of the following:

Return of Contents Y=Yes, N=No

Delivery Notification Y-Yes, N=No

Non-Delivery Notification Y=Yes, N=No

Grade of Delivery N=Normal,U-Urgent,

O=Off hours

Prohibit or allow alternate P=Prohibit, A=Allow application delivery

TAG currently supports the following options: YNYNP

Actor address

The most commonly used "From" addressee. When setting up outgoing TAG communications, this address will appear as the defa ult "From" addressee but it can be changed.

Administra tor

The MHS characteristics of the Organizational Actor tha t will be identified with this host including: username, workgrou p and host name. Names of originating hosts

Set up originxling hosts

Set up originating hosts

A TAG host tha t will be receiving files will ha ve a list of origina ting sites associated wi th it to manage the receipt process. A "master" list of sta nda rd origina ting sites can be declared and that list can later be inserted in to each individual receipt Action ID.

With the TAG main menu displayed select [Origina ting Sites].

The Originating Hosts screen will be displayed.

Press F2 Add to add a new host. To revise an already existing host, move the cursor to the Originating host name and press En t er.

The Originating Host screen will be displayed.

Fill in the Originating Host screen as follows:

Originating host name

Enter the MHS host name of the transmitting host.

Description

Optionally enter brief descriptive text.

Send non-receipt notice to

Enter the MHS address of the person who is to receive non-receipt notices when enclosures associated with incoming Action ID's arc not received..

With the Originating Host screen completed, press F8=OK to save the entry.

Claims

1. A network system for coordinating interactions among a plurality of users of the system comprising:

a communications network for transmitting communications among users of the system;

a plurality of user stations connected to said communications network for allowing respective users to send and receive communications via said communications network;

an action module connected to said communications network and independently operable thereon which is programmed to receive, generate and send communications among said user stations in accordance with a structured interaction program containing a plurality of defined interaction descriptions, wherein said communications are categorized according to a plurality of defined communication types, and wherein each of said defined interaction descriptions controls receiving of a communication of a defined communication type and automatic generation and sending of a defined response based thereon; and action program configuring means, including an interface to said action module, for selectively configuring and modifying said defined interaction descriptions of said interaction program in order to selectively define the corresponding communication-response interactions.

2. A network system according to Claim 1, wherein said communications network is a wide area network connected to a plurality of dispersed offices of an organization.

3. A network system according to Claim 1, wherein said action module has an associated data storage for storing and retrieving information sent by or to be sent to users of the system.

4. A network system according to Claim 1, wherein said user stations are each connected through a common communications interface program to said communications network.

5. A network system according to Claim 1, wherein each of said user stations includes a plurality of templates each corresponding to a respective one of said communication types, and tools for sending a communication type in accordance with a respective template.

6. A network system according to Claim 1, further comprising a plurality of action modules connected to said communications network and programmed similarly to said firstmentioned action module, said plurality of action modules each controlling respective communication-response interactions among associated users of the system, and constituting electronic organizational actors of an electronic labor force for said network system.

7. A network system according to Claim 6, wherein said plurality of action modules are selectively configured an modified in common through said interface of said action module configuring means.

8. In combination with a network system of the type including a communications network for transmitting communications among users of the system, and a plurality of user stations connected to said communications network for allowing respective users to send and receive communications via said communications network,

an interaction coordination system, comprising:

an action module connected to said communications network and independently operable thereon which is programmed to receive, generate, and send communications among said use stations in accordance with a structured interaction program containing a plurality of defined interaction descriptions wherein said communications are categorized according to plurality of defined communication types, and wherein each of said interaction descriptions controls receiving of a communication of a defined communication type and automatic generation and sending of a defined response based thereon; and action program configuring means, including an interface to said action module, for selectively configuring and modifying said interaction descriptions of said interaction program in order to selectively define the corresponding communication-response interactions.

9. An interaction coordination system according to Claim 8, wherein said action module includes an associated data storage for storing and retrieving information sent to users of the system.

10. An interaction coordination system according to Claim 9, wherein said action module includes interaction descriptions having defined parameters for controlling respective interactions for each corresponding communication type.

11. An interaction coordination system according to Claim 10, wherein said action module includes a defined interaction description for sending a user a report previously stored in said data storage upon receipt of a report request from a user.

12. An interaction coordination system according to Claim 10, wherein said action module includes a defined interaction description for sending a follow-up communication if a report or response from a user has not been received.

13. An interaction coordination system according to Claim 10, wherein said action module includes a defined interaction description for sending a response to a user based upon the form of a received communication.

14. An interaction coordination system according to Claim 10, wherein said action module includes a defined interaction description for initiating a conversation with a user based upon a previously defined calendar date, triggering event or exception condition.

15. An interaction coordination system according to Claim 10, wherein said parameters of said defined interaction descriptions include identification of the action type, an identity of a user sending a communication, a subject, an identity of users who are to be sent a communication, a date, time, event or condition at which a communication is expected from or to be sent to a user, a lead time from a scheduled send date when a communication can be sent to a user, a number of times a communication is to be repeated or response status checked, and an identification of a report to be sent to a user.

16. An interaction coordination system according to Claim 10, wherein said interface includes means for selectively specifying the parameters of said defined interaction descriptions.

17. A method of coordinating conversations among users of an electronic communications network connected to respective user stations, comprising the steps of:

providing an action module which is connected to said communications network and independently operable thereon, and which is programmed to receive, generate and send communications among said user stations in accordance with a structured interaction program containing a plurality of defined interaction descriptions, wherein said programming includes categorizing communications according to a plurality of defined communication types, and providing a respective interaction description for controlling receiving of a communication of a defined communication type and automatic generation and sending of a defined response based thereon; and

selectively configuring and modifying said interaction descriptions of said interaction program through an interface in order to selectively define the corresponding communication response interactions.

18. A method of coordinating conversations among users of an electronic communications network according to Claim 17, wherein providing step includes providing said action module with an associated data storage for storing and retrieving information sent by or to be sent to users of the system.

19. A method of coordinating conversations among users of an electronic communications network according to Claim 17, wherein said defined interaction descriptions of said action module are used for engaging users in a plurality of structured conversations.

20. A method of coordinating conversations among users of an electronic communications network according to Claim 19, wherein said action module engages said plurality of structured conversatons with users as an electronic organizational actor in said communications network.