INTERACTION NETWORK SYSTEM WITH ELECTRONIC ORGANIZATIONAL ACTORS

FIELD OF THE INVENTION

This invention generally relates to networ 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 ¹¹ 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

TUTE SHEET

"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* 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 allo the parameters of communication-response interactions to be freely defined and modified.

It is also a fundamental purpose of the invention t provide a network system in which one or more structures for suc defined interactions can be freely programmed and modified a adjunct entities in the network system. It is intended that plurality of such interaction structures can serve as a electronic labor force to enhance the performance and efficienc of work functions in an organization. In accordance with the invention, one or mor electronic organizational actors (EOAs) of an electronic labo force are set up as separately operable, adjunct programme entities in a network system. The EOAs are used to automaticall perform defined interaction functions with users and groups whic are known and established in the organization, and a preferre application of an EOA is for managing structured conversation among users and groups in the organization. A central feature o

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 b making each action module an independently operable adjunct to a open network. Thus, users can freely communicate amon themselves on the network while directing or receiving specifi

SUBSTITUTE SHEET

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 an activities involved.

For example, a dispersed organization may have a established procedure of local office managers reporting thei weekly results to a central office manager on a specific day o the week, the central office manager sending the results t operations staff for tabulation into a summary report, th operations staff sending back the summary report to the centra office manager on a following day, and the central office manage

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, stand¬ alone 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 networ architecture is illustrated for coordinating define organizational activities in a wide area network connecting loca offices 10 (one is shown for simplicity) , an operations offic 20, district or executive offices 30, and an action administrato office 40 through a communications hub 50. The local offices 1 are shown ^" as connected to the network through a host compute which supports a plurality of terminals for users to conduct on site functions, such as sales, cost accounting, inventor control, etc. Alternatively, each local office may have plurality of stand-alone workstations connected by a LAN. Th operations office 20 is shown as having a LAN connecting a mai frame computer, which also supports local workstations. The mai frame computer is typically used to perform large-scal computational tasks for the organization, such as general ledge accounting. The district/executive office 30 is shown as havin 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 coordinatio BSTITUTE SHEET

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 ¹¹ 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.l. 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

SU

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'* system.

Fig. 2 illustrates an example of one possible networ 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, whic corresponds to the communications hub 50. The actio administrator manages a number of EOAs, EOA-1 to EOA-4, t perform their respective coordination functions. The EOAs ar shown in Fig. 2 as virtual entities (in phantom lines) each o which is addressable by a given .name on the network by a associated user. Since the network is intended to be largel transparent to a user, the EOA appears to the network user as separate entity which is responsible for defined set o coordination activities. For repetitive, tedious or automatabl coordination tasks, any number of EOAs of the organization's ELF network can be established by the action administrator simply b defining their respective address "names" and "job descriptions.

One primary coordination activity in organizationa settings is the coordination of structured conversations, i.e communication-response interactions, among users and groups. A example is shown in Fig. 2 in which a user in one LAN grou conducts a conversation with EOA-2 for coordination of activitie with a user in another LAN group. The conversation interaction are structured so that authorized users can address the EOA o the network using the same methods and conversational procedure as used to converse with a person. This provides the users wit a feeling of familiarity in carrying on the conversations, a

SUBSTITUTE

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™ interfac 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 fil along with a status file indicating the action ID of th appropriate response. If. the communication requests a repor upon the existence of a certain condition (e.g. reported sale below a defined level) , or conveys information indicating certain condition for which a response is to be given, and th TAG™ interface checks for the existence of the condition an identifies the corresponding action ID. The TAG™ interface ma also initiate a conversation with a user based upon an action I specified for a calendared reply-by or follow-up date, or i response to a trigger event or exception condition specified b administrator input. The TAG™ interface thus locates the actio ID corresponding to the type of incoming communication an assembles the response, message, and/or enclosed report require by the corresponding action ID description and/or provided by th DW for sending to the user. Further details of designing th EOA's structured conversations are given in the'Αction Modul Developer's Guide" appended hereto as Appendix A.

The TAG™ interface can function as a standar conversation interface not only to associated users but also t other programs with which it operates. For example, its request response format can be used as an interface to a standard DBM used as the DW. If the other programs do not recognize th response-request format, communications from the interface can b converted to the structured language recognized in such programs Thus, the open environment of other standard programs can b 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 XD 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 actio to open a scheduled conversation with a user. To start, a chec is made of the calendar for all Action IDs (step 90) which wer previously listed for future action in response to user request or required by the action administrator. The correspondin Action ID description is checked to see if a report is schedule (step 91) , and whether or not it is scheduled according to previously defined exception condition (step 92) . For example, a user may have requested that a report be sent in the event a organizational goal or result for a previous period exceeds a upper or lower level. If the report is due upon an exceptio condition, the program sends the report request to DW (step 93) which sends back a report enclosure file. The program checks th exception type (step 94) to determine whether it requires sendin a communication. If the exception condition does not exist, th procedure is terminated and the reply-by date is cleared from th calendar. If opening a further conversation is to be scheduled a reply-by date is set (step 96) , and the calendar is update (step 97) . The appropriate message, reply-by date, and/o

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 th setting up of electronic organizational actors of an electroni labor force as separately operable, adjunct entities in a networ system. The EOAs are used to automatically perform define interaction functions with users and groups which are known an established in the organization, so as to improve th productivity and efficiency of the organization by reducing o eliminating repetitive, tedious or readily automatable function that need not be performed by human beings. A particularl

SUBSTITUTE SHEET

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.

SUBSTITUTE SHEET

A ^C TION 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_RESPONSΞ.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

- 20 -

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 lang-uage 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 — rovides the specification for a DW delivering reports to a user via TAG.

Critical Event Notices— rovides the specification for a DW to alert administrative users (via The Coordinator) of critical events having occurred in the DW.

SUBSTITUTE SHEET

- -

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 organisational actors that communicate within the WAN 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 organmtional 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.

^SUBS T'TUTE SHEET

2. The Coordinator interface to TAG

O erview

Tools for Building Templates

Parameter Fields

Use of Jhe "Action ID" Key Symbol Combination

A Completed Template

Overview

In an ΞLF network, TAG acts ^~ s an interpreter, translating the parameters specified in report requests from Coordinator users, into a format that C3n be acted upon by a DW. The user provides these parameters by means of a " _t emplate" 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 coion (:) 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 . 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.

SUBSTITUTE SHEET

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. Thi<j is available as a free utility from the PC Magazine '?C MagNet" bulletin board..Instructions for gaining access can be found in any recent issue of ?C 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 TΞD.COM.

TABLE 1 ASCII SYMBOLS and CODES

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:

^" [ ~λ~ [ ^" B THIS LINE IS FULLY PROTECTED

^* [ ^* A ^* C "B THIS LINE IS P RTIALLY PROTECTED ^" [ ^* D

For the line that is partially protected, the user will be able to enter text only after the ^* ΞSCEOT ^* 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 _t o 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 bε 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.

se 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" 2s 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\EMPLOYEΞ directory where [±\] is the letter of the drive letter in which TAG is installed.

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 iist of employees, fill in the entries below and send it to "Admin @ ABC.

^* [ ~λ~ [ ~3 • Report name : ~ [ ~ ΩStaff

~ [ ^" A~ [ ~ 3 • Salary level ; ^* [ " D

~ [ ^" A~ [ ~3 • Department : ~ [ "" D

SUBSTITUTE SHEET

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 Tvianager under "Set up this host."

SUBSTITUTE SHE

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\REQUΞSTS 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_1D + 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 _t parameters preceded by the ASCII symbol δ (ASCII 153).

Example of a DW_REQUEST File

Consider the case in which JDoe <S> 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 codes- Access Code 1: <=50000 Access Code 2: Staff

SUBSTITUT

A DW request file will be produced as follows:

Filename

[d:]\ACTOR\REQUESTS\DW_REQUEST_NAMl

Con ten ts

MHS MESSAGE ID,<35000,Sa!esδ<=50000,Sιaff

SUBSTITUTE SHEET

4. Delivering Reports From the Data Warehouse

Overview

Read and Delete DW_REQUEST File

Create DW_STATUS xnd DW_RESPONSE.T P File

Completing the Report

SUBSTITUTE SHEET

Overview

Once a DW_REQUEST file has been created by TAG as described in Section 3, _t he 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 DWJ EQUEST File

The DW must read each DW_RΞQUEST file in the [d:]\ACTOR\RΞQUESTS 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 ths 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 RΞSPONSΞ.TMP ^" file and a DW STATUS file.

The DW RESPONSE.TMP File

The DW_RΞSPONSΞ.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__RΞSPONSΞ.TMP file. The file is named according to the following convention:

DW_RΞSPONSΞ.TMP - TAG_SITE ID + SEQUENCE NUMBER + .TMP ^{■ "} ~ ~

It is the responsibility of the DW application software to construct the filename including supplying the uni ^q ue SEQUENCE _NUMBER. The (TAG_SITΞ_ID -■ SΞQUΞNCE_NUMBΞR) may be the same as the DW_REQUEST file.

For example, TAG host with a TAG_STTΞ_ID - ADMN, a request fiie would get produced with the name...

[d:)\ACTOR\RΞQUΞSTS\ADMN4772

SUBSTITUTE SHEET

- 32 -

(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 MΞSSAGΞ_ID[,RPT_FILΞ_NAME]

The definitions in the message block are as follows:

MESSAGE_ID

The MΞSSAGΞ_ID for a report response must be the same as the 16 character MES_ iζ∑SSAGΕ._TD contained in the DW__REQUEST file that originated the report request.

RPT_ FΓLE_NAME inis parameter is optionally provided by the DW. It is used to provide a different filename extension other than .RPT. Tne R?T_FILE_NAME is defined as follows:

RPT_?ILΞ_NAME - DW_ ESPONSE + ".' + 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 - W 1.

The following message block,

09SS767123e79326,ADMN7231.WK 1 will return a report enclosure in response to a user request with MKS_MESSAGE_ID - 098S767123e79326, with the enclosure bearing the filename ADMN723 LW 1.

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 RΞSPONSE.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 Jd):\ACTOR\REPORTS\DW_RΞSPONSE.RPT file with the communication.

Step 3

Send the report communication with

[d):\ A CTOR\REPORTS\DW_RESPONSΞ.RFT enclosed.

Step 4

Delete fd]:\ACTOR\REPORTS\DW_RΞSPONSE.RPT and the status file [d]:\ACTOR\RΞPORTS\DW__RESPONSΞ.

SUBSTITUTE SHEET

5. Critical Event Notices From the Data Warehouse

Overview

Example of - Critic*! Event TN Setting Up - TN Action ID in TAG Generating TN Trigger Files

SUBSTITUTE SHEET

Overview

A critical event is defined here to be any event, state change, or condition that rnav 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 _ctions.) 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_STAT S fiiεs to the [d:]\ACTOR\RΞPORTS 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 RΞPORT_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 beiow 10 MBytes. Please perform routine Housekeeping so thai 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.

SUBSTITUTE SHEET

- 36 -

Generating TN Trigger Files

TN Trigger files are the pair of DW_RESPONSE.RPT and RΞPORT_STATUS files wi _t h the same filename and processed as described in Section 3. When tnese files are in the fd:]\ACTOR\REPORTS directory, the TN named in the REPORT_STATUS file will be triggered. The DW_RESPONSE.RPT is ootional 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_JRESPONSΞ 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 7777 RPT file if there is one.

The REPORT_STATUS file content specification is as follows:

Line 1 MESSAGΞ_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_H>

The MESSAGE_ID for a TN must be constructed as follows:

MESSAGΞ_ID - App._ID: ÷ TAG_ACTION_ID

For example, a valid MΞSSAGΞ_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_ACT10N_ID = TN2 + nnnnn

For example, a valid TAG_ACT10N_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;

%i.TN

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

SUBSTITUTE SHEET

APPENDIX B

ADMINISTRATORS GUIDE Table of Contents

Introduction

S t up RECURRENT out ^g oing 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 I S

Monitor receipt of incoming actions 19

Read mail 21

Housekeeping ^~ -

SUBSTITUTE SHEET

Set up RECU RRENT outgoing actions

Set up recurrent communications

Set up a recurrent communication with an enclosed reports

SUBSTITUTE SHEET

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 _t ra cted from the On-Site system. Curren tly, these reports include the End-of- Wcck Activity Report, 20lh-of-the-Month Activity Report a nd End-of-ihc-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\RE IND01

The format of the distribution list is comma-delimited, KS addresses, onc-per-linc 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 i his sets The Action Generator to generate the communication repeatedly.

The instructions that can be entered art as follows:

SUBSTITUTE SHEET

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|MON1ME -- tht 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, Stltcted 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 FS=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 R.eport by 11:00~~- ionday.

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:

SUBSTITUTE SHEET

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

NOTE: The Enter key must be pressed a t the end ol ^" the line.

With the message text and template reference completed, press FS=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 t them automatically each week.

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

Stt 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 mtssagt 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\- ^~ zτ&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 of tht message beginning at the line where the %ά command occurs. Tht rtport will be sent as an enclosure.

A single ASCII text file or several may also be inserted in the body of t text using tht samt command line refercnct as in tht previous instructio For cxampic:

%άc:\ιag\news\awards whtrt "awards" is a list of tht lattst award winners.

NOTE: Tht 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.

SUBSTITUTE SHEET

Set up EXCEPTION outgoing actions

Set up exception communications Set up exception report conditions

SUBSTITUTE SHEET

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 w hin 2n 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 stt by dcttrmining how_f requcntl y the exception condition is be checked for.

When sttting up how frtqucntly an exception condition will bt checked, it is important to take into consideration how frequently the data warthouse rtcords will bt [refreshed) updattd. As an example, the schedule should bt set for no more frequently than onct a week for data that is rtfreshtd on a weekly basis.

At tht scheduled ti t, the Action ID is activattd, a communication is optntd, but btfore it is stnt, the data warehoust is checked to stt if the txctption condition exists. If it dots exist, tht communication is automatically sent, with or without an cnclostd file. If it docs not exist, tht communication is automatically abandoned.

Set up tht paramttcrs for the outgoing communication as dtscribtd in Set up & recurrent (scheduled) ou tgoing communication.

Stt the Send ^' da te and Send time as makes stnst for tht particular rtport data refresh ratt and managers concerns.

Within tht body of tht message composition window, insert tht DOS path and filename of the exception report template file which describes tht txctption 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: ^e A>a.\bubbc\library\inseris\par-xrpt

If the exception exists the communication will be sent with tht templa te inserted in the bod y of the messa ge begging at the line whtrt tht "%_£:" command occurs.

With tht message text and template reference completed, press FS-OK to add the communication to the list.

SUBSTITUTE SHEET

Set up exception report conditions

Had _. 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- arc inserted into the outgoing communication. A new template is set up for each new exception condition. One Action ID using _t he same exception condition template can be used for more than one rccipicn: 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 tnclosurt

If txctption 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 oτ A Itttcr 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 Monda .

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 Sundav.

Field name

Tht name of the field for which tnc exception will be monitored. This must be enttrtd EXACTLY as shown in tht PAR Data Dictionary.

Type of comparison

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

Upper level Iricser

This is tht valut 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 tricger

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

This field entry is optional. It nttd not be entered -if a value is enttrtd for tht prtviσus 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 indicattd 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 valut f or tht P AR field name for the time period indicated in the template with tht totals f or each of tht proptrtits in the group.

Add this commen t to the enclosure

A one lint f rtt-form comment can be optionally entered. This will appear as a description on the txctption rtport tnclosurt.

If ccάdi tion is not m et ... do nothing

If a n txctption dots not exist tne outgoing communication will bt abandoned by answering Y (for Yes). If N (for No) the outgoing communication with enclosure will bt sent whether or not an txccpticr. exists.

Set up RECURRENT incoming actions

Set up non-receipt notices for incoming actions

SUBSTITUTE SHEET

- 5C -

Set up non-receipt notices for incoming actions

BPM managers may elect to receive automatic notification if a Property Management Rtport has not been received by its due date. Or, they ma y choose _t o 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 noticts involves modifying an incoming communication Action that will have bctn already bttn set up in The Action Generator.

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

The "Incoming Communications Activities" list appears.

With tht cursor on tht rtlcvant line e.g. End-of-Wttk Rtpor;", press Enter

The Incoming Enclosure Setup Menu will appear.

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

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

Press Fδ-O .

To review the hosts from which Incoming Rtports art εxptcttd, press F3-"Frorn" host list.

SUBSTITUTE SHEET

Run Mail Activities

Run mail activities automatically

SUBSTITUTE SHEET

βun mail activities automatically

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

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 timt it would not be in the Automatic Mode is when new communica tions or network hαsis. art, 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.

SUBSTITUTE SHEET

List and review communications

Monitor receipt of incoming actions

Read mail

Perform housekecpiπc

SUBSTITUTE SHEET

-

Monitor receipt of incoming actions

Th _t Action Generator will be recei vin g and processing da ta files f or the Data Wa rehouse. For exampic, data ex tracted f rom On-Si ic for tne End-of -wcck report will be received once a week. On-Site extract data will also be received on _t h _t 20th-of-tht-month and End-of-month (last ca y of the month.)

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

The Action Gentrator should bt 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 bttn rtccivcd 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-weck 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 tnat 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.

SUBSTITUTE S

For reports that ere not received, telephone the person responsible at th: property. Obtain the data, and manually enter it in the R.cport Data Warehouse if there is going to be a delay in receiving the report cnclosur:

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

SUBSTITUTE SHEET

Read mai

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 Tht 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 ∑sc 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.

SUBSTITUTE SHEET

- 57 -

Housekeeping

Periodically, to keep conversation records "trim", routine housekeeping should b 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.

Vi'ith the cursor on the communication to be deleted , press Del.

The communication will be marked for deletion.

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

The marked communications will bt deleted.

SUBSTITUTE SHEET

Start TAG directory manager

Confiεure TAG for this MHS Host

SUBSTITUTE SHEET

ComV oure TAG for this MHS Host

The Action Generator is designed to work with MHS by Act ion Tech nologies. Before it _C3 n opera te wi th MHS, it is necessa ry to decla re the cha ra cteristics of _t he 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 bt prepared.

Currently only MHS- 1 is allowed.

MHS options

The delivery options supported by MHS. Tht options art indicattd with a singlt lttttr 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,

0=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 bt iotntifitd with this host including: ustrnamc, workgrou p and host name.

SUBSTITUTE SHEET

Names of originat .i.n. g ₀ hosts

Set up originxling hosts

SUBSTITUTE SHEET

- -

Set up originating hosts

A TAG host tha t wj|) be receiving files will ha ve a list of origina ting sites associated wi th i: to manage the receipt process. A "master" iist 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 Oricinatinε 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.

SUBSTITUTE SHEET