WO1991001022A1 - Systeme de reseau d'interactions avec modules d'action d'organisation electronique - Google Patents

Systeme de reseau d'interactions avec modules d'action d'organisation electronique Download PDF

Info

Publication number
WO1991001022A1
WO1991001022A1 PCT/US1990/003779 US9003779W WO9101022A1 WO 1991001022 A1 WO1991001022 A1 WO 1991001022A1 US 9003779 W US9003779 W US 9003779W WO 9101022 A1 WO9101022 A1 WO 9101022A1
Authority
WO
WIPO (PCT)
Prior art keywords
interaction
communication
users
communications
action
Prior art date
Application number
PCT/US1990/003779
Other languages
English (en)
Inventor
Jon E. Ramer
Stephen A. Edelstein
Original Assignee
Ramer And Associates, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ramer And Associates, Inc. filed Critical Ramer And Associates, Inc.
Publication of WO1991001022A1 publication Critical patent/WO1991001022A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 

Definitions

  • 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.
  • the information industry has developed various forms of network systems for providing an information flow among multiple users.
  • 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.
  • 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.
  • the Coordinator" System is operated at its base level through a Conversation ManagerTM 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 ManagerTM 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 ManagerTM program. However, it lacks the capability to coordinate the specific actions of people corresponding to their particular activities and functions in the organization.
  • 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.
  • 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.
  • 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.
  • 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.
  • data warehouse data storage
  • 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.
  • WAN wide area network
  • LAN local area network
  • 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.
  • EOA electronic organizational actor
  • 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.
  • 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
  • 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.
  • 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.
  • 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).
  • EOAs electronic organizational actors
  • 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 (ELFTM, a trademark of the applicant) for repetitive, tedious or automatable organizational functions which need not be done by human beings.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 ELFTM 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.
  • LAN local area network
  • WAN wide area network
  • 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.
  • 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.
  • 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.
  • 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 ManagerTM 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.
  • 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.
  • EOAs electronic organizational actors
  • Each EOA performs a program of structured interactions for coordination activities through an interface 41 called "The Action Generator” or "TAGTM” ( a trademark of the applicant) interface.
  • TAGTM The Action Generator
  • the EOA with TAGTM 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.
  • the EOA appears to the network user as a separate entity which is responsible for defined set of coordination activities.
  • any number of EOAs of the organization's ELFTM 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.
  • Fig. 3A is a diagram of the TAGTM interface for configuring the conversation interactions of an EOA in a communications network.
  • the TAGTM 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.
  • Fig. 3B the operational parts of the EOA are illustrated schematically.
  • 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.
  • KSCs key symbol combinations
  • 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. TAGTM 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 TAGTM 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 TAGTM 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 TAGTM interface checks for the existence of the condition and identifies the corresponding action ID.
  • the TAGTM 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 TAGTM 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 TAGTM 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 TAGTM interface. Examples of EOA Structured Conversations
  • 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.
  • 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).
  • 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.
  • 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 TAGTM interface can recognize and extract the data for storage in DW.
  • 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).
  • 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.
  • 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).
  • 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.
  • 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).
  • the main functions of the EOA central module 114 include: (a) managing conversations with users (121);
  • 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).
  • 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) .
  • 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.
  • ELF Electronic Labor Force
  • ELF Technology provides an overview of ELF Technology and some of its basic parts including The Action Generator (TAG), Electronic
  • EOAs Organizational Actors
  • DW Data Warehouse
  • 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.
  • TAG ⁇ 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.
  • the basic building blocks of an ELF network include the following:
  • 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.
  • WAN Wide Area Network
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • a template will normally be stored in a DOS subdirectory. To initiate a request to the DW, the user performs the following the actions:
  • 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.
  • Table 1 lists the individual symbols that are used to construct "hidden codes,” and the keys for producing them using TED.COM.
  • 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 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.
  • KSCs key symbol combinations
  • TAG 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...
  • 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.
  • 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.
  • TAG 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • 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:
  • Template parameters will be parsed to either the
  • the output files will be given a unique file name which is to be
  • 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.
  • 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.
  • Coordinator request will be appended to the comma-delimited string of parameters preceded by the ASCII symbol ö (ASCII 153).
  • Access Code 2 Staff A DW request file will be produced as follows:
  • 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 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.
  • the DW 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
  • 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:
  • the (TAG_SITE_ID + SEQUENCE_NUMBER) may be the same as the DW_REQUEST file.
  • TAG host with a TAG_SITE_ID ADMN, a request fiie would get produced with the name...
  • the DW_RESPONSE.TMP file could be named as follows:
  • DW_RESPONSE.TMP file would be named as follows...
  • 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:
  • 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 is defined as follows:
  • RPT_FILE_NAME DW_EESPONSE + ".” + EXTENSION
  • TAG operating in the Automatic Mode
  • 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.
  • TAG Notice (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:
  • xxxxx is any combination of up to five characters.
  • a 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 Action ID 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
  • 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.
  • the file name for DW_RESPONSE is constructed according to the following rule:
  • a valid DW_RESPONSE filespec would be DWXX7021.RFT, where 7021 is a sequence number provided by the DW.
  • a REPORT_STATUS file must be produced which has the same filename as the DWXX xxxx. RPT file if there is one.
  • REPORT_STATUS file content specification is as follows:
  • the MESSAGE_ID for a TN must be constructed as follows:
  • 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
  • TAG_ACTION_ID a valid TAG_ACTION_ID
  • the '%' character must be located at column 1.
  • 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.
  • 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.
  • ME for month end to indicate the last day of the calendar month.
  • the T symbol can be used as an "or" statement to indicate
  • 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).
  • Thtst should be left as the default values, Y and N, respectively.
  • Tht list will bt redrawn with the new tntry.
  • 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
  • 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.
  • the template 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:
  • a u thorized personnel ma y request a communication be sent
  • Exception communica tions with or without enclosed files can be au tomaticall y sent to authorized personnel immediately when an exception condition is detected.
  • 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.
  • the schedule should bt set for no more frequently than once a week for data that is refreshed on a weekly basis.
  • 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
  • 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.
  • 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.
  • 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 report can indicate cither a sum or an average f or the period of t ime of the report. Enter S or A respectively.
  • This field entry is optional. It need not be entered if a va lue is entered for the next field.
  • This field entry is optional. It need not be entered if a value is entered for the previous field.
  • 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.
  • move-outs for a 4 week period can be compared to the previous A week period by answering Yes.
  • 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.
  • a one lint f ree-form comment can be optionally entered. This will appear as a description on the exception report enclosure.
  • 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.
  • 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.
  • 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.
  • the Action Generator will first complete the current processing activity and when complete, return to the Main Menu.
  • 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 Action Gentrator should be normally set to process mail automatically. (Sec Run mail activities automatically.)
  • 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.
  • Date/time rec'd column will show the date and time of the receipt.
  • 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.
  • the communication will be displayed.
  • the communication will be marked for deletion.
  • the marked communications will be deleted.
  • 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.
  • FTF 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.
  • TAG currently supports the following options: YNYNP
  • 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
  • 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.
  • the Originating Hosts screen will be displayed.
  • the Originating Host screen will be displayed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Data Mining & Analysis (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Un système de réseau coordonne des interactions parmi des utilisateurs en employant un module d'action (40) à fonctionnement indépendant programmé pour recevoir, générer et envoyer des impressions selon un programme d'interaction structuré, et une interphase (41) pour configurer et modifier sélectivement le programme d'interaction. De tels modules d'action (40) sont utilisés en tant qu'acteurs d'organisation électronique (EOAS) d'une force de travail électronique pour le système de réseau. Les EAOS sont utilisés pour améliorer la productivité et l'efficacité de l'organisation en réduisant ou en éliminant les fonctions répétitives ou ennuyeuses qui n'ont pas besoin d'être effectuées par des êtres humains. Une application des EAOS et la gestion de conversation structurée parmi des utilisateurs et des groupes dans l'organisation. Les paramètres d'interaction des EOAS peuvent être modifiés sans avoir à reconfigurer tout le système de réseau.
PCT/US1990/003779 1989-07-05 1990-07-05 Systeme de reseau d'interactions avec modules d'action d'organisation electronique WO1991001022A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US37583289A 1989-07-05 1989-07-05
US375,832 1989-07-05

Publications (1)

Publication Number Publication Date
WO1991001022A1 true WO1991001022A1 (fr) 1991-01-24

Family

ID=23482553

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1990/003779 WO1991001022A1 (fr) 1989-07-05 1990-07-05 Systeme de reseau d'interactions avec modules d'action d'organisation electronique

Country Status (2)

Country Link
AU (1) AU6046390A (fr)
WO (1) WO1991001022A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0510908A2 (fr) * 1991-04-25 1992-10-28 International Business Machines Corporation Système et méthode de génération d'un système de traitement de données
WO1996019064A2 (fr) * 1994-12-16 1996-06-20 Xcellenet, Inc. Systemes et procedes de partage automatique d'informations entre des n×uds a distance/mobiles
EP0697671A3 (fr) * 1994-08-11 1997-07-30 Sharp Kk Secrétaire électronique
EP0793184A2 (fr) * 1995-06-07 1997-09-03 Dun & Bradstreet Software Services, Inc. Méthode et appareil pour la distribution des processus de travail entre plusieurs usagers
EP1071028A2 (fr) * 1999-07-20 2001-01-24 International Computers Ltd. Système informatique de suivi automatique de transactions

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4503499A (en) * 1982-09-14 1985-03-05 Eaton Corporation Controlled work flow system
US4951192A (en) * 1987-06-04 1990-08-21 Apollo Computer, Inc. Device for managing software configurations in parallel in a network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4503499A (en) * 1982-09-14 1985-03-05 Eaton Corporation Controlled work flow system
US4951192A (en) * 1987-06-04 1990-08-21 Apollo Computer, Inc. Device for managing software configurations in parallel in a network

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
Broderbond Software Introducing for Comment, 1980, pp. 2-3. *
COORDINATOR VERSION 11, Introduction and Overview, 1988, Action Technologies, Inc. *
COORDINATOR, Product Review, 1987. *
HOLF et al, "Coordination System Technology as the Basis for a Programming Environment", 1983. *
OPPER, "A Groupware Toolbox", Byte, Dec 1988, pp. 275-282. *

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0510908A3 (en) * 1991-04-25 1994-05-18 Ibm System and method for generating a data processing system
EP0510908A2 (fr) * 1991-04-25 1992-10-28 International Business Machines Corporation Système et méthode de génération d'un système de traitement de données
EP0697671A3 (fr) * 1994-08-11 1997-07-30 Sharp Kk Secrétaire électronique
US5761644A (en) * 1994-08-11 1998-06-02 Sharp Kabushiki Kaisha Electronic secretary system with animated secretary character
WO1996019064A3 (fr) * 1994-12-16 1996-09-06 Xcellenet Inc Systemes et procedes de partage automatique d'informations entre des n×uds a distance/mobiles
US5664207A (en) * 1994-12-16 1997-09-02 Xcellenet, Inc. Systems and methods for automatically sharing information among remote/mobile nodes
GB2310982A (en) * 1994-12-16 1997-09-10 Xcellenet Inc Systems and methods for automatically sharing information among remote/mobile nodes
WO1996019064A2 (fr) * 1994-12-16 1996-06-20 Xcellenet, Inc. Systemes et procedes de partage automatique d'informations entre des n×uds a distance/mobiles
US5819274A (en) * 1994-12-16 1998-10-06 Xcellenet, Inc. Methods, systems and computer program products for transferring files from a data processing server to a remote/mobile data processing node
GB2310982B (en) * 1994-12-16 1999-11-10 Xcellenet Inc Systems and methods for automatically sharing information among remote/mobile nodes
EP0793184A2 (fr) * 1995-06-07 1997-09-03 Dun & Bradstreet Software Services, Inc. Méthode et appareil pour la distribution des processus de travail entre plusieurs usagers
EP0793184A3 (fr) * 1995-06-07 1998-05-06 Dun & Bradstreet Software Services, Inc. Méthode et appareil pour la distribution des processus de travail entre plusieurs usagers
EP1071028A2 (fr) * 1999-07-20 2001-01-24 International Computers Ltd. Système informatique de suivi automatique de transactions
EP1071028A3 (fr) * 1999-07-20 2002-10-02 Fujitsu Services Limited Système informatique de suivi automatique de transactions

Also Published As

Publication number Publication date
AU6046390A (en) 1991-02-06

Similar Documents

Publication Publication Date Title
US6865268B1 (en) Dynamic, real-time call tracking for web-based customer relationship management
US7373388B2 (en) Notification message distribution
US7353465B2 (en) Method for managing personal and work-related matters
US10979487B2 (en) Desktop assistant for multiple information types in a timeline view
US6988128B1 (en) Calendar events and calendar-driven application technique
US6049776A (en) Human resource management system for staffing projects
US7302436B2 (en) Business workflow database and user system
US20020078007A1 (en) Task management program
JP2687230B2 (ja) 電子メールによる会議通知に対する返答作成支援方法
US7783715B2 (en) Scheduled electronic mail deletions
US5873095A (en) System and method for maintaining current status of employees in a work force
US6222535B1 (en) System and method for facilitating issue tracking
US8868660B2 (en) Electronic communication work flow manager system, method and computer program product
JPH0777380B2 (ja) 電子メール追従システム
EP1460538A1 (fr) Assistant pour une collaboration dynamique
US20050198085A1 (en) Tool for synchronization of business information
US7882433B2 (en) System and apparatus for managing personal and work-related matters
US20030069983A1 (en) Web based methods and systems for managing compliance assurance information
US20050057584A1 (en) Calendar bar interface for electronic mail interaction
EP1416411A2 (fr) Systèmes et techniques de facilitation de la communication entre les individus d'une entreprise utilisant des canaux de conversation collaboratifs qui sont associés à des communautés spécifiques dans l'entreprise
AU3393697A (en) Task-based classification and analysis system
WO2003073234A2 (fr) Systeme, procedes et produit de programme execute par logiciel pour gerer des ressources d'organisation
Handel et al. TeamPortal: Providing team awareness on the web
WO1991001022A1 (fr) Systeme de reseau d'interactions avec modules d'action d'organisation electronique
US7769039B2 (en) System configured for complex determination of a user's busy state and for assigning an organic “do not disturb” filter

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU BR CA DK JP KR

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB IT LU NL SE

NENP Non-entry into the national phase

Ref country code: CA